Name verification service

Abstract

A method for verifying a cardholder name associated with a payment device used in connection with a card not present transaction is provided. The method includes the steps of: maintaining a database comprising a plurality of records related to historically processed transactions; receiving, at a name verification server, a cardholder name verification request comprising a submitted primary account number of a payment device and a submitted cardholder name; querying the database to identify one or more records comprising an indication of a primary account number matching the submitted primary account number included in the cardholder name verification request; comparing at least one cardholder name in the identified one or more records to the submitted cardholder name included in the cardholder name verification request; determining whether a sufficient match results from the comparison; generating a name verification response; and transmitting the name verification response to the merchant server.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Application No. 16 / 896,598, filed June 9, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This specification covers the general area of ​​identity verification. Background Technology

[0004] Typically, this refers to communication via telecommunications networks (e.g., including but not limited to wired and / or wireless networks, the Internet, etc.). Credit card, debit card, and / or other similar payment instrument transactions (via cellular networks, different systems, dedicated networks, etc.) may encounter issues in verifying the identity of the claimed cardholder, such as verifying that the user is indeed the person they claim to be, i.e., the actual cardholder. In practice, this difficulty often arises because the transaction occurs over a network (e.g., the transaction is not conducted face-to-face between the customer and the merchant involved). Therefore, physical cards are typically unavailable to merchants. This type of transaction is commonly referred to as a cardless (CNP) transaction in the payments industry.

[0005] Due to the associated costs and liabilities, there is often a desire to eliminate and / or limit fraud in CNP transactions. CNP transactions can be a significant channel for fraud because merchants may find it difficult to verify whether the actual cardholder is indeed making the purchase.

[0006] If a customer makes a purchase without a physical card, the merchant must rely on the customer (e.g., someone claiming to be the cardholder) to provide accurate card information indirectly, for example, via the internet. Typically, for CNP transactions (e.g., via the internet), the customer needs to provide their name, address, card number, card expiry date, and sometimes a Card Security Code (CSC) to process and / or complete the CNP transaction. For example, depending on the card type, the CSC can be, but is not limited to: Card Identifier or Code (CID), Card Verification Code (CVC2), Card Verification Data (CVD), or Card Verification Value (CVV2). Typically, internet merchants (e.g., travel agencies, airlines, online retailers, dating websites, digital download websites, etc.) optionally send the aforementioned data to the issuing bank (i.e., the institution that issued the card to the cardholder) via the merchant's card processor during the authentication and / or authorization process. The issuing bank can then verify the data against its records and report the result back to the merchant.

[0007] Typically, secure code is not strictly required. For example, and / or The use of security codes is not required, but its adoption is strongly encouraged and widespread. Furthermore, Address Verification Service (AVS), as it is known in the payments industry, is not mandatory; only U.S. issuers are required to support AVS, while issuers in other countries are not.

[0008] Despite the foregoing provisions, one of the aforementioned elements not sent to the issuing bank regarding CNP transactions is the cardholder's name, even though customers may be prompted to provide their name "as shown on the card." In fact, to date, there is no suitable process, in an automated and / or real-time manner, for verifying and / or confirming whether the name provided by the customer adequately matches the actual name associated with the relevant card in CNP transactions. This lack of name verification for CNP transactions can be particularly troubling for merchants offering digital and / or non-physical goods and / or services that can be purchased in the name of the person making the purchase (e.g., airline tickets, sporting event or concert tickets, etc.).

[0009] For physical goods that typically require a physical address to which the goods are shipped, verifying that the provided "shipping address" matches the "billing address" associated with the card can reliably ensure, to some extent, that the customer is indeed the cardholder he claims to be. However, for digital and / or non-physical goods and / or services, there is usually no physical shipping address to which the goods and / or services are actually sent.

[0010] AVS can sometimes be used to verify the validity of a billing address associated with a payment device to some extent. However, most AVS currently in use is limited to matching values ​​in street addresses and postal codes, and further limited to selected countries. Therefore, in many cases, address verification may not be sufficient to detect and / or prevent fraudulent CNP transactions.

[0011] For example, consider a scenario where an airline sells travel tickets online. When conducting a CNP transaction, the airline might ask customer John Doe for the aforementioned information. Suppose John Doe provides Bill Jones' credit card number and address, but during the purchase, John Doe's name is provided in the "Name on Card" and "Traveler / Passenger" fields. When making an authentication and / or authorization request to the issuing bank, if there are sufficient address and / or security code matches and sufficient funds are available, the issuing bank might respond to the airline with appropriate verification. Therefore, the airline might issue a travel ticket in John Doe's name. In this case, the merchant does not have an automatic way to verify or confirm whether "John Doe" is actually or is not the cardholder registered with the issuing bank. For example, if the airline could verify / confirm that John Doe is not the name of the cardholder on the issuing bank's records, the airline could attempt to prevent potential fraud by requesting an alternative payment method, demanding clarification of the discrepancy, or simply refusing the transaction. Summary of the Invention

[0012] This summary is provided to introduce concepts relevant to this specification. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended to define or limit the scope of the claimed subject matter. The exemplary and non-limiting embodiments or aspects described below are not intended to be exhaustive or to limit the claims to the precise forms disclosed in the following detailed description. In fact, the non-limiting embodiments or aspects were chosen and described so that others skilled in the art can understand and comprehend the principles and practice of the subject matter presented herein.

[0013] According to a non-limiting embodiment or aspect, a method is provided for verifying a cardholder's name associated with a payment device used in conjunction with cardless transactions. The method includes: maintaining a database comprising multiple records related to historically processed transactions, each record including an indication of the payment device's primary account and a cardholder's name for conducting the transaction associated with the record; receiving, at a name verification server, a cardholder's name verification request sent via a data communication network from a merchant server, the cardholder's name verification request including a submitted primary account of the payment device and a submitted cardholder's name; querying the database to identify one or more records, the records including an indication of a primary account matching the submitted primary account included in the cardholder's name verification request; comparing at least one cardholder's name from the identified one or more records with the submitted cardholder's name included in the cardholder's name verification request; determining whether a sufficient match exists as determined by the comparison; generating a name verification response, wherein the content of the name verification response is established at least in part based on the determination; and sending the name verification response to the merchant server via the data communication network.

[0014] According to a non-limiting embodiment or aspect, a computer system is provided for verifying the name of a cardholder associated with a payment device used in conjunction with cardless transactions. The system includes: a database comprising multiple records related to historically processed transactions, each record including an indication of the payment device's master account and the cardholder's name for conducting the transaction associated with the record; and a name verification server implemented on a computer. The name verification server is configured to: receive a cardholder name verification request sent from a merchant server via a data communication network, the cardholder name verification request including a submitted master account of the payment device and a submitted cardholder name; query the database to identify one or more records, the records including an indication of a master account matching the submitted master account included in the cardholder name verification request; compare at least one cardholder name from the identified one or more records with the submitted cardholder name included in the cardholder name verification request; determine whether a sufficient match exists as determined by the comparison; generate a name verification response, wherein the content of the name verification response is established at least in part based on the determination; and send the name verification response to the merchant server via the data communication network.

[0015] Other non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0016] Clause 1: A method for verifying a cardholder's name associated with a payment device used in conjunction with cardless transactions, the method comprising: maintaining a database using at least one processor, the database including multiple records related to historically processed transactions, each record including an indication of a primary account of the payment device and a cardholder's name for conducting a transaction related to the record; receiving a cardholder's name verification request sent from a merchant server via a data communication network at a name verification server, the cardholder's name verification request including a submitted primary account of the payment device and a submitted cardholder's name; querying the database using at least one processor to identify one or more records, the records including an indication of a primary account matching the submitted primary account included in the cardholder's name verification request; comparing at least one cardholder's name in the identified one or more records with the submitted cardholder's name included in the cardholder's name verification request using at least one processor; determining, using at least one processor, whether a sufficient match exists as determined by the comparison; generating a name verification response using at least one processor, wherein the content of the name verification response is established at least in part based on the determination of whether a sufficient match exists; and sending the name verification response to the merchant server via the data communication network.

[0017] Clause 2: The method described in Clause 1 further includes updating the database with additional records relating to the cardless transaction for which the cardholder name verification request was received.

[0018] Clause 3: The method according to Clause 1 or 2, wherein the additional record includes: an indication from the payment device of the submitted primary account number included in the cardholder name verification request; the submitted cardholder name included in the cardholder name verification request; and the name verification response generated in response to the name verification request.

[0019] Clause 4: The method according to any one of Clauses 1 to 3, wherein when it is determined that a sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is valid; otherwise, when it is determined that no sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is invalid.

[0020] Clause 5: The method according to any one of Clauses 1 to 4 further includes calculating a confidence score, the confidence score indicating the degree of confidence in the accuracy of the name verification response.

[0021] Clause 6: The method according to any one of Clauses 1 to 5 further includes counting the number of identified records, the identified records including at least one cardholder name that sufficiently matches the submitted cardholder name included in the cardholder name verification request, wherein the confidence score is calculated based at least in part on the number of identified records.

[0022] Clause 7: The method according to any one of Clauses 1 to 6, wherein receiving the cardholder name verification request, querying the database to identify the one or more records, comparing the cardholder names, determining whether a sufficient match exists, and generating the name verification response are performed by at least one processor of the name verification server.

[0023] Clause 8: A system for verifying a cardholder's name associated with a payment device used in conjunction with cardless transactions, the system comprising: a database including a plurality of records relating to historically processed transactions, each record including an indication of a primary account of the payment device and a cardholder's name for conducting a transaction relating to the record; and a name verification server including at least one processor, the name verification server being programmed or configured to: receive a cardholder name verification request sent from a merchant server via a data communication network, the cardholder name verification request including a submitted primary account of the payment device and a submitted cardholder's name; query the database to identify one or more records, the records including an indication of a primary account matching the submitted primary account included in the cardholder name verification request; compare at least one cardholder's name from the identified one or more records with the submitted cardholder's name included in the cardholder name verification request; determine whether a sufficient match is found by the comparison; generate a name verification response, wherein the content of the name verification response is established at least in part based on the determination; and send the name verification response to the merchant server via the data communication network.

[0024] Clause 9: In the system described in Clause 8, the name verification server is further programmed or configured to update the database with additional records relating to the cardless transaction for which the cardholder's name verification request was received.

[0025] Clause 10: The system according to Clause 8 or 9, wherein the additional record includes: an indication from the payment device of the submitted primary account number included in the cardholder name verification request; the submitted cardholder name included in the cardholder name verification request; and the name verification response generated in response to the name verification request.

[0026] Clause 11: The system according to any one of Clauses 8 to 10, wherein when it is determined that a sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is valid; otherwise, when it is determined that no sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is invalid.

[0027] Clause 12: The system according to any one of Clauses 8 to 11, wherein the name verification server is further programmed or configured to calculate a confidence score that indicates the accurate confidence level of the name verification response.

[0028] Clause 13: The system according to any one of Clauses 8 to 12, wherein the name verification server is further programmed or configured to count the number of identified records, the identified records including at least one cardholder name that sufficiently matches the submitted cardholder name included in the cardholder name verification request, wherein the confidence score is calculated based at least in part on the number of identified records.

[0029] Clause 14: A computer program product for verifying a cardholder's name associated with a payment device used in conjunction with cardless transactions, comprising at least one non-transient computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: maintain a database including a plurality of records relating to historically processed transactions, each record including an indication of a primary account of the payment device and a cardholder's name for conducting a transaction relating to the record; receive a cardholder's name verification request sent from a merchant server via a data communication network, the cardholder's name verification request including a submitted primary account of the payment device and a submitted cardholder's name; query the database to identify one or more records including an indication of a primary account matching the submitted primary account included in the cardholder's name verification request; compare at least one cardholder's name from the identified one or more records with the submitted cardholder's name included in the cardholder's name verification request; determine whether a sufficient match exists as determined by the comparison; generate a name verification response, wherein the content of the name verification response is established at least in part based on the determination; and send the name verification response to the merchant server via the data communication network.

[0030] Clause 15: The computer program product according to Clause 14, wherein the program instructions further cause the at least one processor to update the database with an additional record relating to the cardless transaction in connection with receiving the cardholder name verification request.

[0031] Upon reading and understanding this specification, numerous advantages and benefits of the subject matter disclosed herein will become apparent to those skilled in the art. However, it should be understood that the detailed descriptions of various embodiments, aspects, and specific examples are provided illustratively and not restrictively, while indicating preferred and / or other embodiments or aspects.

[0032] These and other features and characteristics of the subject matter, as well as the operational methods and functions of the associated structural elements and combinations of parts, and the economics of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein like reference numerals denote corresponding parts in the figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be a definition of limitation on the disclosed subject matter. Unless the context clearly specifies otherwise, the singular forms “a” and “described” as used in this specification and claims include plural indicators. Attached Figure Description

[0033] The following detailed description refers to the accompanying drawings. However, the disclosure herein may take the form of various components and component arrangements, as well as various steps and step arrangements. The drawings are for illustrative purposes only and should not be construed as limiting. Furthermore, it should be understood that the drawings are not drawn to scale.

[0034] Figure 1A This is a diagrammatic illustration of a non-limiting embodiment or aspect of a system for performing a name verification service according to various aspects of this disclosure.

[0035] Figure 1B This is a diagrammatic illustration of a non-limiting embodiment or aspect of a system for performing a name verification service according to various aspects of this disclosure.

[0036] Figure 2 This is a flowchart illustrating a non-limiting embodiment or aspect of a name verification service according to various aspects of this disclosure.

[0037] Figure 3 This is a flowchart illustrating the generation of hash_ID from PAN according to a non-limiting embodiment or aspect of this disclosure.

[0038] Figure 4 This is a flowchart illustrating an exemplary process for generating a response reliability score according to a non-limiting embodiment or aspect of this disclosure. Detailed Implementation

[0039] For clarity and simplicity, this specification should refer to structural and / or functional elements, relevant standards, algorithms and / or protocols, and other components, methods, and / or processes commonly known in the art, without requiring further detailed explanation of their configuration or operation, except for modifications or changes made according to and / or applicable to the preferred and / or other embodiments presented herein. Furthermore, the devices and methods disclosed in this specification are described in detail by way of example and with reference to the drawings. Unless otherwise specified, similar numbers in the drawings indicate references to the same, similar, or corresponding elements throughout the drawings. It should be understood that modifications may be made to the disclosed and described examples, arrangements, configurations, components, elements, devices, methods, materials, etc., and specific applications may require such modifications. In this disclosure, any identification of specific materials, techniques, arrangements, etc., is related to the specific example presented or is merely a general description of such material, technique, arrangement, etc. Unless specifically specified, the identification of specific details or examples is not intended to be or should not be construed as mandatory or limiting. Selected examples of devices and methods are disclosed below and described in detail with reference to the drawings.

[0040] The terms "aspects," "components," "elements," "elements," "structures," "actions," "steps," "functions," and "instructions" used herein should not be construed as critical or essential unless explicitly stated otherwise. Furthermore, as used herein, the articles "a" and "an" are intended to include one or more items and are interchangeable with "one or more" and "at least one." Additionally, as used herein, the term "group" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and is interchangeable with "one or more" or "at least one." The term "a" or similar language is used where only one item is desired. Also, as used herein, the terms "having" and similar expressions are intended to be open-ended terms. Furthermore, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on."

[0041] As used herein, the terms "communication" and "transmission" can refer to the receiving, accepting, sending, transmitting, and providing of information (e.g., data, signals, messages, instructions, commands, etc.). For one unit (e.g., a device, system, component of a device or system, or a combination thereof) to communicate with another unit means that the first unit is able to receive information directly or indirectly from and / or send information to the other unit. This can refer to a direct or indirect connection that is inherently wired and / or wireless. Furthermore, although the transmitted information may be modified, processed, relayed, and / or routed between the first and second units, the two units can also communicate with each other. For example, the first unit can communicate with the second unit even if it passively receives information and does not actively send information to the second unit. As another example, the first unit can communicate with the second unit if at least one intermediate unit (e.g., a third unit located between the first and second units) processes information received from the first unit and transmits the processed information to the second unit. It should be understood that many other arrangements are possible.

[0042] As used herein, the term "computing device" can refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components for receiving, processing, and outputting data, such as a processor, display, memory, input device, network interface, etc. A computing device can be a mobile device. As examples, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device can also be a desktop computer or other forms of non-mobile computer.

[0043] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communication and processing among multiple parties in a network environment such as the Internet, but it should be understood that communication may be facilitated through one or more public or private network environments, and various other arrangements may be possible. Furthermore, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) communicating directly or indirectly in a network environment may constitute a "system." As used herein, references to "server" or "processor" may refer to a previously stated server and / or processor, different servers and / or processors, and / or combinations of servers and / or processors that implement a prior step or function. For example, as used in the specification and claims, a first server and / or first processor that implements a first step or function may refer to the same or different servers and / or processors that implement a second step or function.

[0044] As used herein, the term “graphical user interface” (GUI) refers to a generated display, such as one or more displays that a user can interact with directly or indirectly (e.g., via a keyboard, mouse, touchscreen, etc.).

[0045] As used herein, the term "transaction service provider" can refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment guarantees through an agreement between the transaction service provider and the issuing entity. For example, a transaction service provider may include, for instance... Payment networks, or any other entity that processes transactions. The term "transaction processing system" can refer to one or more computing devices operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing system may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0046] As used herein, the terms “issuing institution” and / or “issuing bank” may refer to one or more entities, such as a bank, that provide customers with accounts for transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuing institution may provide a customer with an account identifier, such as a primary account number (PAN), that uniquely identifies one or more accounts associated with said customer. The account identifier may be implemented on a payment device, such as a physical financial instrument, and / or may be electronic and used for electronic payments. The term “issuing system” refers to one or more computing devices operated by or on behalf of an issuing institution, such as a server computer executing one or more software applications. For example, an issuing system may include one or more authorization servers for authorizing transactions.

[0047] As used herein, the term "account identifier" can include one or more PANs, tokens, or other identifiers associated with a customer account. An account identifier can be any combination of alphanumeric or character and / or symbol. A token can be associated with a PAN or other original account identifier in one or more data structures (such as one or more databases), enabling the token to be used for transactions without directly using the original account identifier. In some examples, an original account identifier such as a PAN can be associated with multiple tokens used for different individuals or purposes.

[0048] As used herein, the term "payment device" can refer to electronic payment devices, portable financial devices, payment cards (e.g., credit or debit cards), gift cards, smart cards, smart media, payroll cards, healthcare cards, wristbands, machine-readable media containing account information, keychain devices or pendants, RFID transponders, retailer discount or membership cards, cellular phones, e-wallet mobile applications, PDAs, pagers, security cards, computing devices, access cards, wireless terminals, transponders, etc. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory for storing information (e.g., account identifiers, account holder names, etc.).

[0049] The non-limiting embodiments or aspects disclosed herein provide new and improved systems, methods, and computer program products for verifying the claimed identity of a cardholder in relation to CNP transactions. The non-limiting embodiments or aspects disclosed herein address specific problems arising from CNP transactions related to digital goods and services in electronic payment processing networks. Reliable name verification is provided in the context of an electronic payment processing network through the disclosed novel arrangements of systems, devices, and communications between them. Reliable name verification during CNP transaction processing reduces fraud fees and thus significantly reduces the amount of computational and network resources required to resolve fraud through other fraud detection systems and / or by processing disputes and refunds.

[0050] The non-limiting, exemplary, or aspects disclosed herein, in combination with identity authentication and / or verification, have found specific applications in processing credit card, debit card, or other payment instrument transactions via data communication networks, and will be described herein with particular reference to them. More specifically, some non-limiting embodiments or aspects rely on the use of reputation to facilitate authentication (e.g., utilizing historical transaction data to some extent for (e.g., real-time) comparison with current transaction data). However, it should be understood that various non-limiting embodiments or aspects disclosed herein are also applicable to other similar applications.

[0051] refer to Figure 1A and 1B The diagram generally illustrates a system for providing name verification services based on non-limiting embodiments or aspects of the processing of CNP transactions.

[0052] In practice, a customer or consumer 10 uses an internet-enabled or similar network-enabled device 12 (e.g., a computing device, such as a tablet or smartphone) to access and / or operatively connect to the merchant server 20 via the internet 30 or other suitable data telecommunications network. For example, the device 12 may be equipped with and / or run a suitable web browser, which accesses an online shopping website and / or one or more web pages provided by the server 20 via the internet 30. In a non-limiting embodiment or aspect, the merchant server 20 providing the website to the device 12 may be equipped with a virtual or digital shopping cart, allowing the customer 10 to select one or more items to purchase from the online shopping website. When the customer 10 has completed their shopping, they can use their device 12 to navigate to a "checkout" page provided by the merchant server 20. At checkout, the "checkout" page provided by the server to the device 12 may prompt the customer 10 to select payment options from one or more different types, such as one or more different credit card, debit card, and / or other payment device options. In some non-limiting embodiments or aspects, device 12 may be equipped with and / or run dedicated software applications, such as merchant-specific mobile applications, which are served by structured data from server 20.

[0053] After selecting a payment option, customer 10 is prompted to enter certain payment information 40 for the selected payment option and optionally certain order fulfillment information. In practice, payment information 40 appropriately includes the PAN or other account identifier associated with the payment device corresponding to the selected payment option, the cardholder's name (e.g., the cardholder's name "as shown on the payment device"), the billing address associated with the payment device, the payment device's due date, and the payment device's CSC. Order fulfillment information optionally includes a delivery address (e.g., a location identifying where the physical goods can be shipped) and an order name (e.g., the name of the person to whom digital goods and / or non-physical goods and / or services are to be shipped). For example, the order name could be the name of the individual for whom airline, concert, sporting event, and / or other similar tickets are to be shipped.

[0054] As shown in the figure, the input payment information 40 is transmitted from device 12 to merchant server 20 via Internet 30. After receiving the payment information 40, merchant server 20 appropriately invokes the Name Verification Service (NVS) to verify and / or confirm that the cardholder name provided in the payment information is indeed the real cardholder name associated with the PAN provided in the payment information.

[0055] Appropriately, after invoking the name verification service, request 42 (e.g., an application programming interface (API) call) is sent from merchant server 20 to NVS server 50, which performs the name verification process and returns a corresponding response 44 (e.g., a result) to merchant server 20. As shown, request 42 and response 44 are exchanged between merchant server 20 and NVS 50 via Internet 30. In practice, request 42 may include, but is not limited to: the identity of the merchant involved in the transaction, payment information provided for the transaction, and / or the corresponding time and / or date stamp of the transaction.

[0056] For clarity and simplicity, as Figure 1A and 1B As shown, only a single customer 10 and a single merchant server 20 are illustrated. However, it should be understood that in practice, multiple different but similarly positioned customers may transact with merchant server 20 and / or multiple different but similarly positioned merchant servers. Optionally, merchant gateways, marketplaces, and / or other third parties acting on behalf of merchants may, where appropriate, operate or host server 20 on behalf of the merchant. In any case, as may be understood, over time, name verification server 50 performs multiple name verification processes for transactions between various combinations of customers and merchants. In practice, relevant details are recorded, and a record corresponding to each transaction that requests name verification by NVS server 50 is maintained. As shown, these transaction records are stored and maintained in a transaction database (DB) 52 (or data warehouse) that NVS server 50 has access to.

[0057] Appropriately, when the name verification service is provided by the DB, the NVS server 50 continuously updates the DB 52. Each record appropriately includes, but is not limited to, the data provided in request 42 and optionally the corresponding response 44. In a non-limiting embodiment or aspect, before being stored in the DB 52, a hash is applied to the PAN to generate a corresponding hash_ID for the PAN. Although the specification specifically mentions hash_ID, it should be understood that another similar irreversible PAN representation can be generated and / or employed similarly.

[0058] According to a non-limiting embodiment or aspect, in the corresponding record, the hash_ID is replaced by the PAN that generated the hash_ID. In this way, the actual PAN is not maintained in DB 52; instead, the corresponding hash_ID is maintained in DB 52 in place of the PAN. Therefore, if DB 52 is corrupted or otherwise improperly accessed, the PAN is not easily identifiable and / or obtained from it. In this way, for example, the PAN is protected in the event of damage to DB 52.

[0059] Now refer to another source Figure 2Typically, NVS server 50 accesses the history maintained in DB 52 to perform name verification.

[0060] As shown in the figure, the name verification process begins in step 100, where NVS server 50 receives data from request 42 sent from merchant server 20. Appropriately, in step 200, the PAN received in request 42 is converted into a corresponding hash_ID, and in step 300, a transaction record is created and stored in DB 52 for future use.

[0061] Now refer to another source Figure 3 This illustrates an exemplary process (e.g., NVS server 50) of generating a hash_ID from a received PAN, such as the process of performing step 200. More specifically, in sub-step 202, the PAN received in request 42 is input into a suitable hash algorithm. In sub-step 204, the PAN from the secure encryption device 60 (see...) Figure 1A Retrieve hash key 62 (see Figure 1A In substep 206, the hash algorithm is repeatedly applied multiple times using the retrieved hash key 62, where the input PAN is this initial value for applying the hash, and subsequent inputs are the previous outputs of the algorithm. In substep 208, after the hash algorithm has run for a given number of cycles, the final output is returned as the corresponding hash_ID of the initial input PAN.

[0062] Note that while this specification relates to hash_ID and a specific exemplary process for generating said hash_ID, it should be understood that in practice, other methods and / or techniques may be used to obfuscate the PAN and / or generate a PAN “alias”, for example, in accordance with PCI security standards and / or other such guidelines issued by the Payment Card Industry (PCI) Security Standards Committee. Alternatively, the PAN itself may be used without hindrance in appropriate circumstances (e.g., where data security is not a sufficient consideration and / or other appropriate and adequate data security measures are in place).

[0063] Back Figure 2 In step 400, NVS server 50 searches for a hash_ID in DB 52 that matches the generated hash_ID corresponding to the PAN received in the request 42 being processed. If no suitable match is found, NVS server 50 will instruct an appropriate response 44 to be returned to merchant server 20, for example, that the PAN is unrecognized or unknown. That is, in this case, response 44 indicates that NVS server 50 has not previously encountered the PAN in question.

[0064] If a suitable match is found in step 400, processing continues to step 500. In step 500, the cardholder name in the record with the matching hash_ID in DB 52 is compared with the cardholder name received in the processing request 42. If an identical match and / or a sufficiently similar match is found with respect to the compared cardholder names, the NVS server 50 returns an appropriate response 44 to the merchant server 20, indicating, for example, that the cardholder name in request 42 matches exactly or sufficiently similarly to a cardholder name in DB 52 that historically accompanied by a corresponding PAN (or more precisely, its hash_ID).

[0065] As you may understand, DB 52 may contain multiple records corresponding to multiple transactions using the same payment device over time. Therefore, after searching for a matching hash_ID (e.g., in step 400), multiple records that meet the matching criteria can be found. In this case, NVS server 50 can use the number and / or frequency of qualified records to generate a score representing the relative confidence and / or reliability of a given verification response 44. See also... Figure 4 An exemplary scoring process is shown (e.g., performed by NVS server 50).

[0066] As shown in the figure, in step 402, all records in DB 52 are queried to find those records with hash_IDs that appropriately match the hash_IDs corresponding to the PANs received in the currently processed request 42. Then, in step 404, all such records are returned. Furthermore, in step 502, the cardholder names included in the returned records from DB 52 are compared with the cardholder names received in the currently processed request 42 to identify those records where there is an exact or sufficiently similar match. In step 504, the number of such identified records and / or the transaction frequency corresponding to such identified records (which may include the number of transactions in each recent week, month, year, etc.) are calculated and / or otherwise determined. In step 506, the quantity and / or frequency obtained in step 504 are input into a suitable scoring algorithm. In step 508, the scoring algorithm generates a score using the input quantity and / or frequency, which represents the relative confidence and / or reliability of a given verification response 44. For example, when a matching cardholder name appears multiple times and / or frequently along with a matching hash_ID in DB52 records, it might be safer to conclude that the matching name is actually the real cardholder of the PAN corresponding to the hash_ID. Therefore, a stronger score can be generated in such cases. Conversely, when a matching cardholder name appears relatively few times and / or relatively infrequently along with a matching hash_ID in DB52 records, it might be relatively less safe to conclude that the matching name is actually the real cardholder of the PAN corresponding to the hash_ID. Therefore, a relatively weaker score can be generated in such cases. Optionally, other criteria and / or factors may be considered when generating confidence scores. For example, newer transactions in DB52 may be given relatively greater weight than older transactions when calculating scores.

[0067] In either case, in step 510, the final score generated by the scoring algorithm is output and transmitted along with response 44 to, for example, merchant server 20. Appropriately, the score may also be recorded in a score repository or other data storage device for future reference and / or use. Optionally, the score may be stored, for example, in DB 52 along with the record that generated the score.

[0068] Now back Figure 2If, in step 500 (e.g., between the cardholder name associated with the matching hash_ID in DB 52 found in step 400 and the cardholder name received in the request 42 being processed), there is no exact match or sufficiently similar match, the process continues to step 600. In step 600, it is determined whether the cardholder name (if not sufficiently similar for an exact match) is still sufficiently similar to require further processing. For example, if the cardholder name in request 42 is "John Doe," while the name obtained from DB 52 is "Jon G. Doe," then it can be considered that there is insufficient similarity to require the so-called "exact" or "sufficiently similar" designation in response 44. However, there is still sufficient similarity to require further processing. That is, in the case of the middle initial, it is simply omitted in one instance, and in the case of the name, it is simply a typo.

[0069] If the comparison between the corresponding cardholder names in step 600 determines that the names are too dissimilar to require further processing, the process branches to step 800. Otherwise, if the compared cardholder names are determined to be sufficiently similar to require further processing, the process continues to step 700.

[0070] In step 700, alternative information and / or data are optionally compared and / or examined for a sufficient match. Such alternative information may include, but is not limited to, email addresses, phone numbers, delivery or receipt addresses and / or billing addresses, and / or other order fulfillment information, which may optionally be submitted from merchant server 20 to NVS server 50 along with request 42. Similarly, for previously processed requests, the aforementioned alternative data and / or information may have also been provided to NVS server 50 and stored in DB 52 along with records created for the previous transaction.

[0071] Therefore, if the alternative information being compared results in one or more full matches, response 44 can be returned, such as indicating that although the cardholder name does not match, other alternative information matches fully, and thus it can be assumed to some extent that the cardholder specified in the request may and / or is still actually the actual and / or real cardholder.

[0072] When the process reaches step 800, it has been determined that although a matching hash_ID has been found in at least one record in DB 52, the cardholder name contained in the record with the matching hash_ID does not sufficiently match the cardholder name provided in the currently processed request 42. Therefore, in step 800, DB 52 is queried to check for cardholder names that sufficiently match the cardholder name provided with request 42, regardless of the hash_ID associated with the cardholder name in the various records of DB 52. If no such match is found, a response can be returned to merchant server 20, indicating, for example, that although the hash_ID and / or corresponding PAN have been previously processed, the cardholder name provided in request 42 does not sufficiently match the cardholder name previously connected and / or used with the hash_ID and / or PAN. In this case, it can be concluded that and / or response 44 may indicate that the cardholder name has not been verified and / or there is reasonable suspicion that consumer 10 is not actually the genuine cardholder. Alternatively, in this case, response 44 may also indicate that no cardholder name sufficiently matching the cardholder name provided with request 42 was found in DB 52. Or, if a matching cardholder name is found in DB 52 in step 800, but the record shows the cardholder name along with a different hash_ID, response 44 may indicate this.

[0073] In non-limiting embodiments or aspects, the means and / or methods of inputting cardholder name and / or other payment information 40 and / or data into merchant server 20 are appropriately detected and / or used to adjust the tolerance used in combination with name matching and / or comparison. That is, some payment information 40 can be manually entered (e.g., by specific keystrokes) and / or some payment information 40 can be entered via autocomplete or similar functions. For example, if autocomplete is used, whether javascript is enabled can be detected by looking at key events. As can be understood, when autocomplete is used, it is reasonable to expect that typos when entering payment information 40 and cardholder name will not be a significant factor. Therefore, the tolerance for name matching may be relatively low; for example, the cardholder name should match exactly or very close to match exactly to verify the name. Conversely, when manual data input is detected, the probability of typos can be considered relatively higher (compared to the case of autocomplete). Therefore, the name matching tolerance can be relaxed so that a relatively inaccurate match of the cardholder name can still produce a response 44 indicating that sufficient verification of the cardholder name has been achieved.

[0074] Now for special reference Figure 1B It shows the relationship with Figure 1AThis is a non-limiting embodiment or aspect similar to the one described above. In this non-limiting embodiment or aspect, historical transaction details may not be maintained in transaction DB 52. In practice, the issuing bank 70 is queried and / or consulted to obtain the cardholder name associated with a given PAN. Typically, the issuing bank 70 maintains a record of the PAN and associated cardholder name for each payment device or other similar payment instrument issued by the bank 70. Therefore, when the NVS server 50 processes a request to confirm the cardholder name associated with a given PAN, the NVS server 50 then queries the issuing bank 70. For example, as... Figure 1B As shown, the NVS server 50 appropriately submits API calls and / or other similar requests 72 to the issuing bank 70, and the issuing bank 70 returns an appropriate response 74 to the NVS server 50.

[0075] In practice, request 72 may only include the PAN currently being processed by NVS server 50. In this case, issuing bank 70 returns response 74 based on bank records, which includes the cardholder name associated with the PAN received in request 72. Therefore, NVS server 50 will compare the cardholder name received in response 74 with the cardholder name received along with request 42. If there is an exact or sufficiently similar match between the compared cardholder names, response 44 will indicate (e.g., the cardholder name is valid). Similarly, if there is no exact or sufficiently similar match between the compared cardholder names, response 44 will indicate (e.g., the cardholder name is invalid).

[0076] Alternatively, request 72 may include the PAN and cardholder name received by NVS server 50, along with request 42. In this case, issuing bank 70 may compare the received PAN and cardholder name with its bank records. After checking its own records, response 74 returned from issuing bank 70 to NVS server 50 appropriately indicates that the cardholder name matches appropriately with the name associated with the PAN in the bank records (e.g., the cardholder name is valid), or that the cardholder name does not match appropriately with the name associated with the PAN in the bank records (e.g., the cardholder name is invalid). Appropriately, NVS server 50 translates and / or interprets response 74 received from issuing bank 70 and sends the corresponding response 44 to merchant server 20.

[0077] Various aspects of the subject matter have been described herein with reference to exemplary and / or preferred embodiments or aspects. Modifications and variations may arise in others upon reading and understanding the foregoing detailed description. This disclosure is intended to be understood to include all such modifications and variations, provided they fall within the scope of the appended claims or their equivalents.

[0078] The methods, systems, platforms, modules, processes, algorithms, and / or devices described above have been described with respect to specific embodiments or aspects. However, it should be understood that certain modifications and / or variations are also contemplated. Furthermore, certain nomenclatures are used herein to refer to various messages, information, and / or data. Such nomenclatures are used herein for illustrative and / or exemplary purposes only, and in practice, other similar messages, information, and / or data are contemplated regardless of the names or labels applied to them, provided they otherwise function and / or similarly represent their intended purpose.

[0079] It should be understood that, in conjunction with the specific exemplary embodiments presented herein, certain structural and / or functional features are described as being incorporated into the defined elements and / or components. However, for the same or similar benefits, it is contemplated that these features may also be similarly incorporated into other elements and / or components where appropriate. It should also be understood that different aspects of the exemplary embodiments or aspects may be appropriately and selectively employed to implement other alternative embodiments or aspects suitable for the desired application, thereby achieving the corresponding advantages of the aspects incorporated therein.

[0080] It should also be understood that any one or more of the specific tasks, steps, processes, methods, functions, elements, and / or components described herein can be suitably implemented via hardware, software, firmware, or a combination thereof. Specifically, various modules, components, and / or elements can be implemented by processors, circuits, computers, and / or other electronic data processing devices configured and / or otherwise provided to perform one or more of the tasks, steps, processes, methods, and / or functions described herein. For example, a processor, computer, or other electronic data processing device implementing a particular element may provide, supply, and / or be programmed with a suitable list of code (e.g., source code, interpreted code, object code, directly executable code, etc.) or other similar instructions or software or firmware such that, when run and / or executed by a computer or other electronic data processing device, one or more of the tasks, steps, processes, methods, and / or functions described herein are performed or otherwise carried out. Appropriately, a code list or other similar instructions or software or firmware implementation is made, and / or recorded, stored, contained, or included in and / or on a non-transient computer- and / or machine-readable storage medium, so as to be available to and / or executable by a computer or other electronic data processing apparatus. For example, suitable storage media may include, but are not limited to: floppy disks, floppy disks, hard disks, magnetic tapes or any other magnetic storage media, CD-ROMs, DVDs, optical discs or any other optical media, RAM, ROMs, PROMs, EPROMs, FLASH-EPROMs, or other memories or chips or cassette tapes, or any other tangible medium from which a computer or machine or electronic data processing apparatus may read and use. Essentially, as used herein, non-transient computer-readable and / or machine-readable media includes all computer-readable and / or machine-readable media except for transient propagating signals.

[0081] Optionally, any one or more of the specific tasks, steps, processes, methods, functions, elements, and / or components described herein may be implemented on and / or in one or more general-purpose computers, special-purpose computers, programmable microprocessors or microcontrollers and peripheral integrated circuit elements, ASICs or other integrated circuits, digital signal processors, hardwired electronic or logic circuits such as discrete element circuits, programmable logic devices such as PLDs, PLAs, FPGAs, graphics card CPUs (GPUs), or PALs. Generally, any means capable of implementing a finite state machine, and thus capable of implementing the corresponding tasks, steps, processes, methods, and / or functions described herein, may be used.

[0082] Furthermore, it should be understood that certain elements described herein as being incorporated together may, where appropriate, be separate elements or otherwise divided. Similarly, multiple specific functions described as being performed by a particular element may be performed by multiple different elements independently used to perform the separate functions, or certain separate functions may be performed by multiple different elements acting together. Alternatively, some elements or components otherwise described and / or shown herein as different from each other may, where appropriate, be physically or functionally combined.

[0083] In short, this specification has been described with reference to non-limiting embodiments or aspects. Obvious modifications and variations may arise in others upon reading and understanding this specification. It is intended that this disclosure be understood to include all such modifications and variations, provided they fall within the scope of the appended claims or their equivalents.

Claims

1. A method for verifying the name of a cardholder associated with a payment device used in conjunction with cardless transactions, the method comprising: A database is maintained using at least one processor. The database includes multiple records related to historically processed transactions, each record including an indication of the payment device's primary account and the cardholder's name for making the transaction related to the record; wherein, before the record is stored in the database, at least a hash is applied to the primary account in the record to generate a hash_ID. The name verification server receives a cardholder name verification request sent from the merchant server via a data communication network. The cardholder name verification request includes the submitted main account of the payment device and the submitted cardholder name; wherein, at least the submitted main account is converted into a corresponding hash_ID. The database is queried using at least one processor to identify one or more records, the records including an indication of a primary account that matches the submitted primary account included in the cardholder name verification request; Using at least one processor, at least one cardholder name from one or more identified records is compared with the submitted cardholder name included in the cardholder name verification request to identify those records where there is an exact or sufficiently similar match between them; Determining whether a sufficient match exists as obtained from the comparison using at least one processor includes: Calculate the number of such identified records and / or the transaction frequency corresponding to such identified records; The number and / or frequency of the identified records are input into the scoring algorithm; A score is generated by a scoring algorithm using the number and / or frequency of inputs, the score representing the relative confidence and / or reliability of a given name verification response; when the matching cardholder name appears multiple times and / or frequently in records of the database along with the matching hash_ID, the matching name is the real cardholder corresponding to the hash_ID; A name verification response is generated using at least one processor, wherein the content of the name verification response is based at least in part on determining whether a sufficient match exists, and the content of the name verification response indicates at least: based on the existence of a sufficient match, that the cardholder specified in the cardholder name verification request is an actual and / or genuine cardholder; and based on the absence of a sufficient match, that the cardholder's name has not been verified; and The name verification response is sent to the merchant server via the data communication network.

2. The method according to claim 1, further comprising: The database is updated with an additional record relating to the cardless transaction for which the cardholder name verification request was received.

3. The method of claim 2, wherein the additional record comprises: The payment device includes an indication of the submitted primary account in the cardholder name verification request; The submitted cardholder name is included in the cardholder name verification request; as well as The name verification response generated in response to the name verification request.

4. The method of claim 1, wherein when it is determined that a sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is valid; otherwise, when it is determined that no sufficient match is obtained from the comparison, the name verification response indicates that the submitted cardholder name is invalid.

5. The method of claim 1, wherein receiving the cardholder name verification request, querying the database to identify the one or more records, comparing the cardholder names, determining whether a sufficient match exists, and generating the name verification response are performed by at least one processor of the name verification server.

6. A system for verifying the name of a cardholder associated with a payment device used in conjunction with cardless transactions, the system comprising: A database comprising multiple records relating to historically processed transactions, each record including an indication of the payment device's primary account and the cardholder's name for making the transaction associated with the record; wherein, prior to the record being stored in the database, a hash is applied to the primary account in the record to generate a hash_ID; and A name verification server, comprising at least one processor, is programmed or configured to: The system receives a cardholder name verification request sent from a merchant server via a data communication network. The cardholder name verification request includes the submitted main account of the payment device and the submitted cardholder name. At least the submitted main account is converted into a corresponding hash_ID. The database is queried to identify one or more records, the records including an indication of a primary account that matches the submitted primary account included in the cardholder name verification request; Compare at least one cardholder name from one or more identified records with the submitted cardholder name included in the cardholder name verification request to identify those records where there is an exact or sufficiently similar match between them; Determining whether a sufficient match exists as obtained from the comparison includes: Calculate the number of such identified records and / or the transaction frequency corresponding to such identified records; Input the obtained quantity and / or frequency into the scoring algorithm; A score is generated by a scoring algorithm using the number and / or frequency of inputs, the score representing the relative confidence and / or reliability of a given name verification response; when the matching cardholder name appears multiple times and / or frequently in records of the database along with the matching hash_ID, the matching name is the real cardholder corresponding to the hash_ID; A name verification response is generated, wherein the content of the name verification response is established at least in part based on determining whether a sufficient match exists, and the content of the name verification response indicates at least: based on the existence of a sufficient match, that the cardholder specified in the cardholder name verification request is an actual and / or genuine cardholder; and based on the absence of a sufficient match, that the cardholder's name has not been verified; and The name verification response is sent to the merchant server via the data communication network.

7. The system of claim 6, wherein the name verification server is further programmed or configured to: The database is updated with an additional record relating to the cardless transaction for which the cardholder name verification request was received.

8. The system of claim 7, wherein the additional record comprises: The payment device includes an indication of the submitted primary account in the cardholder name verification request; The submitted cardholder name is included in the cardholder name verification request; as well as The name verification response generated in response to the name verification request.

9. The system of claim 6, wherein when a sufficient match is determined to exist as obtained by the comparison, the name verification response indicates that the submitted cardholder name is valid; otherwise, when a sufficient match is determined not to exist as obtained by the comparison, the name verification response indicates that the submitted cardholder name is invalid.

10. A computer program product for verifying the name of a cardholder associated with a payment device used in conjunction with cardless transactions, comprising at least one non-transient computer-readable medium, the non-transient computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: A database is maintained, comprising multiple records related to historically processed transactions, each record including an instruction for the payment device's primary account and the cardholder's name used to conduct the transaction associated with that record; wherein, Before the record is stored in the database, at least the hash is applied to the primary account in the record to generate a hash_ID; The system receives a cardholder name verification request sent from a merchant server via a data communication network. The cardholder name verification request includes the submitted main account of the payment device and the submitted cardholder name. At least the submitted main account is converted into a corresponding hash_ID. The database is queried to identify one or more records, the records including an indication of a primary account that matches the submitted primary account included in the cardholder name verification request; Compare at least one cardholder name from one or more identified records with the submitted cardholder name included in the cardholder name verification request to identify those records where there is an exact or sufficiently similar match between them; Determining whether a sufficient match exists as obtained from the comparison includes: Calculate the number of such identified records and / or the transaction frequency corresponding to such identified records; Input the obtained quantity and / or frequency into the scoring algorithm; A score is generated by a scoring algorithm using the number and / or frequency of inputs, the score representing the relative confidence and / or reliability of a given name verification response; when the matching cardholder name appears multiple times and / or frequently in records of the database along with the matching hash_ID, the matching name is the real cardholder corresponding to the hash_ID; A name verification response is generated, wherein the content of the name verification response is established at least in part based on determining whether a sufficient match exists, and the content of the name verification response indicates at least: based on the existence of a sufficient match, that the cardholder specified in the cardholder name verification request is an actual and / or genuine cardholder; and based on the absence of a sufficient match, that the cardholder's name has not been verified; and The name verification response is sent to the merchant server via the data communication network.

11. The computer program product of claim 10, wherein the program instructions further cause the at least one processor to: The database is updated with an additional record relating to the cardless transaction for which the cardholder name verification request was received.

Images