Mobile device-based authentication for card-based transaction

Abstract

Methods and systems for mobile cardholder authentication are provided. A processing server can receive transaction data for a transaction between a user and a resource provider. The processing server can identify that authentication data is missing from the transaction data and that the user is enrolled in a digital authentication program. The processing server can retrieve authentication data of the user via a user device of the user and perform a cardholder verification process using the authentication data. The processing server can generate an authorization message including an outcome of the cardholder verification process and can transmit the authorization request message to an issuer computer. The authorization request message can cause the issuer computer to authorize or decline the transaction.

Description

MOBILE DEVICE-BASED AUTHENTICATION FOR CARD-BASED TRANSACTIONBACKGROUND

[0001] In transactions completed using a payment card at a point-of-sale (POS), traditionally the user is asked to enter a personal identification number (PIN) as a cardholder verification method (CVM), or the transaction is processed without performing a CVM. The more modern verification methods, such consumer device cardholder verification methods (CDCVMs) are not supported for card-based POS transactions. For example, when a user completes a transaction at a POS using a payment card, the transaction is processed either using no cardholder verification method (CVM), or using authentication of the user via PIN entered at the POS. This leads to transactions completed using a payment card at a POS being unsecured when no CVM is performed or expose the user’s PIN (e.g., to be captured by a skimmer or entered at a fraudulent POS) when PIN is entered at the POS. In addition, certain jurisdictions do not allow transactions to proceed without a CVM being performed (e.g., no CVM tr may be against local regulations).

[0002] Cardholders often carry their smart devices at all times. While cardholders may not prefer to use digital wallets for payments, cardholders may still benefit from authentication methods available to smart devices when performing card transactions at POS terminals. However, conventional systems do not allow CDCVMs to be performed for card- based POS transactions.

[0003] Embodiments of the present application address these and other problems individually and collectively.SUMMARY

[0004] One embodiment of the invention includes a method. The method includes: receiving, by a processing server, transaction data including an account identifier from a resource provider computer for a transaction between a user associated with the account identifier and a resource provider associated with the resource provider computer; identifying, by the processing server, that authentication data is missing from the transaction data; identifying, by the processing server, that the user is enrolled in a digital authentication program; retrieving, by the processing 1SUBSTITUTE SHEET ( RULE 26 )server, the authentication data of the user via a user device of the user; performing, by the processing server, a cardholder verification process using the authentication data retrieved from the user device; generating, by the processing server, an authorization request message including the transaction data received from the resource provider computer and an outcome of the cardholder verification process using the authentication data retrieved from the user device; and transmitting, by the processing server, the authorization request message to an issuer computer, wherein the issuer computer authorizes or declines the transaction based on at least the outcome of the cardholder verification process.

[0005] Another embodiment of the invention includes a processing server comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising: receiving transaction data including an account identifier from a resource provider computer for a transaction between a user associated with the account identifier and a resource provider associated with the resource provider computer; identifying that authentication data is missing from the transaction data; identifying that the user is enrolled in a digital authentication program; retrieving the authentication data of the user via a user device of the user; performing a cardholder verification process using the authentication data retrieved from the user device; generating an authorization request message including the transaction data received from the resource provider computer and an outcome of the cardholder verification process using the authentication data retrieved from the user device; and transmitting the authorization request message to an issuer computer, wherein the issuer computer authorizes or declines the transaction based on at least the outcome of the cardholder verification process.

[0006] Further details regarding embodiments of the invention can be found in the Detailed Description and the Figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 shows a block diagram of a system according to an embodiment of the invention.2SUBSTITUTE SHEET ( RULE 26 )

[0008] FIG. 2 shows a block diagram of an exemplary access device according to an embodiment of the invention.

[0009] FIG. 3 shows a block diagram of an exemplary processing server according to an embodiment of the invention.

[0010] FIG. 4 shows a flow diagram illustrating a process according to an embodiment of the invention.

[0011] FIG. 5 shows a flow diagram illustrating a method according to an embodiment of the invention.

[0012] FIG. 6 shows a flow diagram illustrating a process according to an embodiment of the invention.

[0013] FIG. 7 shows an illustration of a mobile device according to an embodiment of the invention.DETAILED DESCRIPTION

[0014] Embodiments include systems and methods for authenticating a user via a user device before or during a transaction conducted using a payment or access card at a POS or other merchant device. For instance, a user can present a payment card to complete a transaction with a merchant and authenticate their identity using a user device (e.g., a mobile device). Systems and methods described herein mitigate the risk of fraudulent transactions in which a bad actor uses a payment card belonging to a user at a POS as well as the risk of having the user’s PI N recorded by a skimmer or fraudulent POS. Accordingly, disclosed embodiments increase security by enabling biometric authentication for payment card transactions, while reducing the above-described risks associated with the use of payment cards.

[0015] As an illustrative example, a payment card can be swiped, dipped, or tapped to a reader of an access device (e.g., a POS) to provide payment card data (e.g., a token, a cryptogram, details such as payment details or access details) specific to the payment card. In conventional implementations, a merchant may simply complete a transaction with the payment card without requesting or requiring 3SUBSTITUTE SHEET ( RULE 26 )authentication of the user. In another example, the user may be prompted, via the access device, to enter authentication information (e.g., a PIN unique to the payment card and / or user).

[0016] In some embodiments, to authenticate the user, a resource provider computer associated with, or integrated with, the access device can transmit transaction data to a processing server. In response, the processing server can determine whether the user associated with the transaction is enrolled in a digital authentication program. If the user is enrolled in a digital authentication program, the processing server retrieves authentication data that is captured at or stored on the user device. Using this authentication data, the processing server can perform a cardholder verification process to determine whether to authorize the pending transaction. Based on the outcome of the verification process, the processing server can generate an authorization request message and transmit the authorization message to an issuer computer to cause the issuer computer to authorize or decline the pending transaction. In some embodiments, the issuer computer may authorize or decline the pending transaction based on the outcome of the verification process using the authentication data received from the user device.

[0017] Accordingly, rather than entering a PIN manually at a POS, a user may be authenticated and a transaction approved seamlessly via a user device. Additionally, in examples in which a PIN is not requested to complete a transaction, authentication via user device adds an additional layer of security to prevent fraud using a stolen or otherwise compromised payment card.

[0018] Prior to discussing specific embodiments of the invention, some terms may be described in detail.

[0019] A “user” may include an individual. In some examples, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0020] A “user device” may be any suitable device that a user can interact with (e.g., a mobile device). User devices may be in any suitable form. Some examples4SUBSTITUTE SHEET ( RULE 26 )of user devices include mobile devices, cellular phones, PDAs, personal computers (PCs), tablet computers, wearables, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component.

[0021] A “mobile device” (sometimes referred to as a mobile communication device) may include any suitable electronic device that may be transported and operated by a user, which may also provide remote communication capabilities to a network. A mobile communication device may communicate using a mobile phone (wireless) network, wireless data network (e.g. , 3G, 4G, 5G or similar networks), WiFi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, wearable devices (e.g., watches, rings, glasses), vehicles such as automobiles and motorcycles, personal music players, hand-held specialized readers, etc. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device - i.e. , using the other device as a modem - both devices taken together may be considered a single mobile device).

[0022] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of payment credentials may include a PAN (primary account number or “account number”), user name, expiration date, and verification values such as CW (card verification value), dCW (dynamic card verification value), CW2 (card verification value 2), CVC3 card verification values, a token, etc. An example of a PAN is a 16-digit number, such as “400 1234 5678 9010.” In some embodiments, payment credentials can include additional information that may be used for authorizing a transaction. For example, payment credentials can include a cryptogram associated with the transaction.5SUBSTITUTE SHEET ( RULE 26 )

[0023] An “access device” may be any suitable device that provides access to a remote system. An access device may also be used for communicating with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include ROS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user device. In some embodiments, where an access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a user device. In some embodiments, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or an “mPOS” terminal.

[0024] An “authorization request message” may be an electronic message that communicates or causes authorization or denial for a transaction. In some examples, an authorization request message is sent to a transaction processing computer and / or an issuer of a payment card to cause the transaction processing or issuer computer to authorize or decline the transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also include additional data elements corresponding to “identification information” including, by way of example only: a service code, a CW (card verification value), a dCW (dynamic card verification value), a consumer device6SUBSTITUTE SHEET ( RULE 26 )cardholder verification value, a PAN (primary account number or “account number”), a payment token, a username, an expiration date, etc. An authorization request message may also include “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0025] The term “identification data” may include any data or information associated with a user or device. Examples of identification data may include a name of a user associated with the device, an organization associated with the device, payment information such as a primary account number (PAN) associated with the device, an expiration date of the device, a certificate associated with the device, an IMEI or serial number of the device, etc.

[0026] The term “authentication” generally refers to a process of establishing confidence in the identity of a user or a computer. Certain electronic authentication systems may require a user to input authentication information (e.g., a password, a personal identification number (PIN), or other similar information) for authentication of the user. For example, a user may request access to a website by entering a user ID and a PIN into their user device, which communicates the user ID and PIN to a server hosting the website. The server may authenticate the user my comparing the user ID and PIN received from the user device to a stored PIN corresponding to that user ID. Authentication may also be performed via a user device by the user providing authenticating information to the user device, and / or by confirming the identity of the user device through the use of public key cryptography and through the use of digital signatures.

[0027] The term “authentication data” or “authentication information” may include any data or information suitable to authenticate a user or device. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), a digital signature, biometric information, an indication that the device is storing certain information (e.g., biometric information), etc.7SUBSTITUTE SHEET ( RULE 26 )

[0028] A “processing server” may include a powerful computer or cluster of computers associated with a payment processor or other financial entity. For example, the processing server can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the processing server may be a database server coupled to a Web server. The processing server may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers.

[0029] A “resource provider computer” can include a computer, server, or series of interconnected computers maintained by or associated with a resource provider. A resource provider can include an entity (e.g , a merchant, retailer) providing resources (e.g., goods / services) to a user. The resource provider computer can provide a webpage / portal allowing for users to request / order goods or services. The information provided by the user requesting the goods / services can be referred to as “interaction data.” The interaction data can include information relating to the requested goods / services (e.g., item numbers, a total value for the goods / services), user details (e.g., username, age, address), user device details, etc.

[0030] An “issuer computer” can include a computer, server, or series of interconnected computers maintained by or associated with an issuer (e.g., an access or payment card issuer). An issuer can include an entity (e.g., a financial institution) providing financial services and products (e.g., credit / debit cards, checking accounts, etc.) to a user. The issuer computer can interact with a resource provider computer and a processing server to complete transactions between, for example, a merchant and a user.

[0031] FIG. 1 shows a system 100 comprising a number of components. The system 100 comprises a user device 115 associated with and operated by a user 110. The system 100 further comprises an access device 120, a resource provider computer 125, a processing server 135, and an issuer computer 140, each of which may be embodied by one or more computers.

[0032] The user device 115 may be capable of interacting with the access device 120, which may in turn be in communication with the resource provider computer8SUBSTITUTE SHEET ( RULE 26 )125 and / or the processing server 135. Also, the access device 120, resource provider computer 125, processing server 135, and the issuer computer 140 may all be in operative communication with each other through any suitable communication channel or communications network. Suitable communications networks may be any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like.

[0033] Messages between the computers, networks, servers, and devices may be transmitted using a secure communications protocols such as, but not limited to, Secure File Transfer Protocol (SFTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and / or the like.

[0034] An example of the user device 115 is a mobile device such as a smart phone, smart watch, wearable device, etc. capable of executing one or more applications stored thereon. For example, the user device 115 may be configured to execute an authentication application 130. The authentication application 130 may be an application configured to store identity information associated with the user 110. Identity information may include, for example, biometric information or other authentication data. The identity information may be encrypted and stored on the user device 115. In some embodiments, the identify information may be captured by one or more components of the user device 115.

[0035] The user 110 may be able to use the access device 120 to conduct transactions with a resource provider associated with the resource provider computer 125. For example, the access device 120 may be a POS terminal with which the user 110 can interact, for example, at a merchant location.

[0036] The resource provider computer 125 may be associated with a resource provider, which may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of a resource provider include merchants, access devices, secure data access points, etc. A merchant may 9SUBSTITUTE SHEET ( RULE 26 )typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services. The resource provider may accept multiple forms of payment (e g., a payment card such as a credit or debit card) and may use multiple tools to conduct different types of transactions. For example, the resource provider may operate a physical store and use a terminal, such as the access device 120, for in-person transactions.

[0037] One or more components of the system 100 can be used to complete a card-based transaction using mobile device-based authentication. For example, the user 110 can initiate a card-based transaction by presenting a credential device 111 at a location of a resource provider. The credential device 111 can be a payment or transaction card such as a debit or credit card, or a key fob or other device. The credential device 111 can be configured to communicate with external devices through near-field communication (NFC) using a radio-frequency identification (RFID) device or through magnetic strip or other electronic means of communication. The credential device 111 can further be linked to a PAN associated with an account of the user 110 provided by an issuer.

[0038] To execute a transaction with the resource provider, the user 110 can tap, swipe, insert, or otherwise provide the credential device 111 to the access device 120 for completion of the transaction. In another embodiment, the PAN associated with the credential device 111 can be manually entered into the access device 120 or the resource provider computer 125 by an operator of the resource provider computer 125. The processing server 135 can receive the transaction data, including the PAN associated with the user 110 and the credential device 111. Using the PAN, the processing server 135 can identify the user 110 and determine whether the credential device 111 is enrolled in an authentication application 130.

[0039] Upon determination that the credential device 111 is enrolled in the authentication application 130, the processing server 135 can transmit a push notification to the authentication application 130 to cause the user device 115 to display the notification. For example, the notification may indicate that a card-based transaction is being attempted and may prompt the user 110 to provide10SUBSTITUTE SHEET ( RULE 26 )authentication information, such as a password or biometric authentication information.

[0040] The user 110 can provide the requested authentication information using the user device 115 by entering information via a touchscreen or keyboard of the user device 115 or by providing biometric or other information via one or more components of the user device 115 such as a gyroscope, fingerprint reader, camera, microphone, accelerometer, and the like.

[0041] The authentication application 130 can compare the received authentication information to stored authentication information that is stored by the authentication application 130 on the user device 115. If the authentication information received from the user 110 matches the authentication information that was previously stored during enrollment of the credential device 111, the authentication application 130 can transmit a message causing the processing server 135 to authorize the transaction. Upon receiving the message from the authentication application 130, the processing server 135 can generate an authorization message, which is then transmitted to the issuer computer 140 to cause the issuer to accept the card-based transaction.

[0042] Alternatively, if the user 110 rejects the transaction, or if the received authentication information does not match the authentication information stored upon enrollment, the authentication application 130 can transmit a message to the processing server 135 to deny the transaction. In some embodiments, the authentication application 130, via the user device 115, can provide the user 110 with a notification of potential fraudulent use of the credential device 111.

[0043] An example of the access device 120, according to some embodiments of the invention, is shown in FIG. 2. The access device 120 may include a processor 120(c) operatively coupled to a computer readable medium 120(d) (e.g., one or more memory chips, etc.), input elements 120(b) such as buttons or the like, one or more readers 120(a) (e.g., a contact chip reader, a contactless reader, a magnetic stripe reader, etc.), an output device 120(e) (e.g., a display, a speaker, etc.) and a network interface 120(f). A housing may house one or more of these components.11SUBSTITUTE SHEET ( RULE 26 )

[0044] The computer readable medium 120(d) may include instructions or code, executable by a processor, e.g., processor 120(c). The instructions may include instructions for communicating with a processing server, e.g., the processing server 135 to complete transactions between a user and a resource provider, and instructions for any other suitable function as described herein.

[0045] The computer readable medium 120(d) can include a series of instructions that, when executed, cause the processor 120(c) to communicate with the processing server 135 to authenticate the user 110 and to communicate transaction information to the processing server 135. The computer readable medium 120(d) of the access device 120 can include a mobile authentication application 120(g), which may generate one or more messages for transmittal to the processing server 135 that are configured to trigger authentication of the user 110 by the processing server 135. The one or more messages may include, for example, transaction data from the resource provider computer 125, as well as identity information associated with the user 110 and received via the access device 120. For example, identity information may be received at the access device 120 from a payment card of the user 110 via an input element 120(b) of the access device.

[0046] The computer readable medium 120(d) can also include an application programming interface (API) 120(h) allowing for secure connection and communication with resource provider computer 125 and / or processing server 135. The API 120(h) can define the interaction between the access device 120 and the resource provider. The API 120(h) can enhance security of data communicated between access device 120 and the resource provider computer 125 and / or processing server 135.

[0047] In another example, the access device 120 may be integrated with the resource provider computer 125 such that a processor of the resource provider computer 125 generates the one or more messages configured to initiate an authentication process with the processing server 135. The one or more messages may contain transaction and / or identity information received via the input elements 120(b) and / or readers 120(a) of the integrated access device.12SUBSTITUTE SHEET ( RULE 26 )

[0048] Referring back to FIG. 1 , the processing server 135 may be disposed between (e.g., in an operational sense) the access device 120 and / or the resource provider computer 125 and the issuer computer 140. The processing server 135 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the processing server 135 may include a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The processing server 135 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The processing computer 135 may use any suitable wired or wireless network, including the Internet.

[0049] An example of the processing server 135 is illustrated in FIG. 3. The processing server 135 may include a processor 135(a) operatively coupled to a computer readable medium 135(b) (e.g., one or more memory chips, etc.), memory 135(e), and a network interface 135(f).

[0050] The computer readable medium 135(b) may include instructions or code, executable by a processor, e.g., processor 135(a). The instructions may include instructions for communicating with the access device 120, resource provider computer 125, and / or issuer computer 140 to complete transactions between the user 110 and a resource provider, and instructions for any other suitable function as described herein. For example, the computer readable medium 135(b) may store a verification application 135(c) configured to communicate, via a network, with the user device 115 to retrieve authentication data associated with the user 110 and to perform a cardholder verification process to verify the user 110 prior to completing a transaction.

[0051] The computer readable medium 135(b) can also include an application programming interface (API) 135(d) allowing for secure connection and13SUBSTITUTE SHEET ( RULE 26 )communication with the access device 120 and / or resource provider computer 125. The API 135(d) can define the interaction between the access device 120 and / or the resource provider computer 125, and the processor associated with the processing server 135. The API 135(d) can enhance security of data communicated between access device 120 and / or the resource provider computer 125 and the processing server 135. In another example, API 135(d) can define the interaction between the processing server 135 and the issuer computer 140. For example, the processing server 135 may communicate an authorization request message to the issuer computer 140. The authorization request message can include transaction data received from the access device 120 and / or resource provider computer 125, as well as an outcome of the cardholder verification process.

[0052] The memory 135(e) can be a database, or other memory, physical storage device, or cloud-based storage device. The memory 135(e) can, for example, store enrollment information associated with users of a digital authentication program, including control authentication data associated with each user in the digital authentication program. Enrollment and / or control authentication information can be used in lieu of a PIN entered at a terminal of the resource provider during a transaction in which a credential device (e.g., payment device, payment card, access card) is physically present.

[0053] The computer readable medium 135(b) can also include instructions stored thereon that, when executed by the processor 135(a), cause the processing server 135 to perform a method including: receiving transaction data including an account identifier from a resource provider computer for a transaction between a user associated with the account identifier and a resource provider associated with the resource provider computer; identifying that authentication data is missing from the transaction data; identifying that the user is enrolled in a digital authentication program; retrieving the authentication data of the user via a user device of the user; performing a cardholder verification process using the authentication data retrieved from the user device; generating an authorization request message including the transaction data received from the resource provider computer and an outcome of the cardholder verification process using the authentication data retrieved from the user device; and transmitting the authorization request message to an issuer 14SUBSTITUTE SHEET ( RULE 26 )computer, wherein the issuer computer authorizes or declines the transaction based on at least the outcome of the cardholder verification process.

[0054] The issuer computer 140 may be associated with an authorizing entity, which may be an entity that authorizes a request. An example of an authorizing entity may be an issuer, which may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue and manage a payment account associated with the user 110 or a payment card thereof.

[0055] The processing server 135 and the issuer computer 140 may operate suitable routing tables to route authorization request messages and / or authorization response messages using payment credentials, merchant identifiers, or other account identifiers.

[0056] A process 400 according to examples of the present application can be described with respect to FIG. 4.

[0057] The process 400 provides authentication, via a user device 115 associated with a user, of the user interacting with an access device 120 and / or a resource provider computer 125 using a payment card. In a specific example, the process 400 may be used to verify the identity of the user attempting to complete a transaction using a payment card at a POS (e.g., the access device 120 / resource provider computer 125).

[0058] At step S402, the user 110 may communicate, via user device 115, a request to enroll in a digital authentication program to the processing server 135. In some examples, the digital authentication program may be managed and provided by the processing server 135. In other examples an authentication server may manage and provide the digital authentication program.

[0059] At step S404, the processing server 135 may transmit a push notification to the user device 115 to instruct the user 110 to provide a control authentication data to the user device 115. For example, the processing server 135 can transmit one or more messages to the user device 115 to cause the user device 115, or an application stored on the user device 115, to display a push notification prompting15SUBSTITUTE SHEET ( RULE 26 )the user 110 to enter or otherwise provider control authentication data such as biometric information, a username / password combination, PIN, etc.

[0060] In some examples, the processing server 135 can manage an application executing on the user device 115. The application can be configured to control one or more components of the user device 115 to capture the authentication data of the user 110 using one or more components of the user device 115. For example, authentication information may be recorded using software and / or hardware of the user device (e.g., a camera, a microphone, a gyroscope, an accelerometer, a keyboard, a touchscreen display, etc.).

[0061] At step S406, during enrollment of the user in the digital authentication program, the processing server 135 can receive authentication data from the user device 115 to be stored by the processing server 135 as a control authentication data. The control authentication data may be the password, biometric information, PIN, etc. that can be used to authenticate the user during a verification process.

[0062] At step S408, the processing server 135 enrolls the user 110 in the digital authentication program. This may include, for example, storing, by the processing server 135, the control authentication data. The control authentication data may be stored in a database or other storage device maintained by the processing server 135. In some examples, the control authentication data may be encrypted and stored.

[0063] At step S410, the processing server 135 can receive from the resource provider computer 125 associated with a resource provider, transaction data including an account identifier for a transaction between the user 110 associated with the account identifier. As an example, transaction data may be transmitted from the resource provider computer 125 in response to the initiation of a transaction between the user 110 and the resource provider. Transaction information, such as an account identifier, may be received via a reader 120(a) of an access device 120 that is associated with or integrated in the resource provider computer 125. For example, the user 110 may tap, swipe, or insert a payment card associated with an account of the user 110 at the access device 120 to enable the access device 120 to16SUBSTITUTE SHEET ( RULE 26 )read data, such as the account identifier, from the payment card. This information, as well as, for example, a payment amount, transaction identifier, resource provider identifier, etc., may be transmitted from the resource provider computer 125 to the processing server 135.

[0064] At step S412, the processing server 135 may identify that authentication data is missing from the transaction data. This example may occur when the user 110 does not input or is not prompted to input a PIN or signature into the access device 120. The processing server 135 may further identify that the user 110 is enrolled in a digital authorization program, for example, by querying a database associated with the digital authorization program using the account identifier or other information identifying the user 110.

[0065] At step S414, the processing server 135 can retrieve the authentication data of the user 110 via the user device 115 of the user 110. In some examples, the authentication data may be stored by the user device 115 or the authentication application 130 of the user device 115. The stored authentication data can be a token, certificate, or private key associated with the account identifier of the payment card or associated with the user 110 of the payment card. In another example, the processing server 135 may transmit a push notification to the user device 115 to prompt the user 110 to enter authentication data in an application (e.g., authentication application 130). The user 110 can enter authentication data using one or more components of the user device 115.

[0066] At step S416, the processing server 135 can perform a cardholder verification process using the authentication data retrieved from the user device 115. The verification process can include, for example, authenticating a certificate retrieved from the user device 115 or performing a token-based authentication protocol. In another example, the processing server 135 may receive authentication data from the user device 115 and compare the received authentication data with the stored control authentication data. The user 110 can be verified based on a degree of matching between the received authentication data and control authentication data being above a predetermined threshold. In yet another example, the17SUBSTITUTE SHEET ( RULE 26 )authentication application 130 of the user device 115 can perforin the comparison of the received authentication data and the control authentication data.

[0067] At step S418, the processing server can generate an authorization request message including the transaction data received from the resource provider computer 125 and an outcome of the cardholder verification process using the authentication data retrieved from the user device 115.

[0068] At step S420, the processing server 135 can transmit the authorization request message to the issuer computer 140. The authorization request message can cause the issuer computer 140 to authorize or decline the transaction based on at least the outcome of the cardholder verification process. For example, the authorization request message may include data indicating that the cardholder verification process failed or that the authentication data retrieved by the processing server 135 did not match the control authentication data. In this case, the authorization request message can cause the issuer computer 140 to decline the transaction. Alternatively, the authorization request message may include data indicating that the cardholder verification process was successful in authenticating the user 110. In this case, the authorization request message can cause the issuer computer 140 to authorize and / or complete the transaction.

[0069] A method 500 according to embodiments of the present application can be described with respect to FIG. 5.

[0070] The method 500 provides secure authentication of a user by determining whether a user 110 is associated with a payment card being used to execute a transaction at an access device 120 or resource provider computer 125. In a specific example, the method 500 can include authenticating a user attempting to complete a transaction using a payment card in lieu of authentication at a POS terminal using a PIN.

[0071] At step S502, the method 500 includes receiving, by a processing server 135, transaction data including an account identifier from a resource provider computer 125 for a transaction between a user 110 associated with the account identifier and a resource provider associated with the resource provider computer18SUBSTITUTE SHEET ( RULE 26 )125. The transaction can be a card-present transaction during which a payment device (e.g., a payment card or account card) is physically presented to the resource provider. As described above, the transaction information can be received when the user 110 interacts with the resource provider computer 125 or with an access device 120 of the resource provider computer 125. Transaction information can be received from the user 110, from the payment card associated with the user 110, and / or as input from an operator of the resource provider computer 125.

[0072] At step S504, the method 500 includes identifying, by the processing server 135, that authentication data is missing from the transaction data. For example, the processing server 135 can receive transaction information that does not include an indication of whether the user 110 has been authenticated, e.g., using a PIN input into the access device 120. In this case, the user device 115 can be used to authenticate the user 110 in lieu of a PIN entered on a terminal (e.g., access device 120) of the resource provider.

[0073] At step S506, the method 500 includes identifying, by the processing server 135, that the user is enrolled in a digital authentication program. As described above, the method 500 can include enrolling, by the processing server 135, the user in the digital authentication program. The enrollment can be completed by the user 110 via an authentication application 130 associated with and / or managed by the processing server 135.

[0074] In some examples, the method 500 can include: receiving, by the processing server 135, a control authentication data from the user device 115 during enrollment of the user in the digital authentication program; and comparing, by the processing server 135, the control authentication data to the authentication data retrieved in connection with the transaction.

[0075] At step S508, the method 500 can include retrieving, by the processing server 135, the authentication data of the user via a user device 115 of the user. This can include, for example, receiving, by the processing server 135, the authentication data from the user device 115 prior to or during processing of the transaction. This authentication data can be provided in lieu of a PIN entered on a terminal (e.g., access device 120) of the resource provider. The authentication data can be, for19SUBSTITUTE SHEET ( RULE 26 )example, one or more of biometric data or a password. In other examples, the authentication data can be a secure certificate, token, or other digital identifier.

[0076] In another example, the method 500 can include: upon identifying that the user is enrolled in the digital authentication program, transmitting a push notification to the user device 115; and receiving, by the processing server 135, the authentication data from the user device 115 in response to the push notification.

[0077] In another example, the method 500 can include managing, by the processing server 135, an application (e.g., authentication application 130) executing on the user device 115, wherein the application is configured to control one or more components of the user device 115 to capture the authentication data of the user 110 using one or more components of the user device 115. The authentication application 130 may, for example, prompt the user 110 to enter authentication data that is captured via the one or more components of the user device 115, such as a gyroscope, a camera, a microphone, a touchscreen, a keyboard, etc of the user device 115.

[0078] In another example, the application (e.g., authentication application 130) is launched on the user device 115 prior to initiating the transaction, and receives the authentication data from the user 110. In this example, the method 500 can include retrieving, by the processing server 135, the authentication data from the application after the processing server receives the transaction data from the resource provider computer 125. In another example, the application is launched on the user device 115 in response to the processing server 135 requesting the authentication data. In this example, the processing server 135 can then retrieve the authentication data from the application after receiving the transaction data from the resource provider computer 125.

[0079] At step S510, the method 500 includes performing, by the processing server 135, a cardholder verification process using the authentication data retrieved from the user device 115. In some examples, the cardholder verification process can be performed in whole or in part by the authentication application 130 managed by the processing server 135.20SUBSTITUTE SHEET ( RULE 26 )

[0080] In one example, the method 500 can include: enrolling, by the processing server 135, the user 110 in the digital authentication program by instructing the user 110 to provide a control authentication data to the user device 115; transmitting, by the processing server 135, a push notification to the user device 115; receiving, by the processing server 135, the authentication data from the user device 115 in response to the push notification; receiving, by the processing server 135, the control authentication data from the user device 115; and comparing, by the processing server 135, the control authentication data to the authentication data retrieved in connection with the transaction.

[0081] At step S512, the method 500 includes generating, by the processing server 135, an authorization request message including the transaction data received from the resource provider computer 125 and an outcome of the cardholder verification process using the authentication data retrieved from the user device 115. The authorization request message may be a file containing data in a format readable and / or executable by the issuer computer 140.

[0082] At step S514, the method 500 includes transmitting, by the processing server 135, the authorization request message to an issuer computer 140, wherein the issuer computer 140 authorizes or declines the transaction based on at least the outcome of the cardholder verification process. Thus, the transaction can be authorized or declined by the processing server 135 using authentication data retrieved from the user device 115 in lieu of a PIN entered on a terminal associated with the resource provider.

[0083] A process 600 according to examples of the present application can be described with respect to FIG. 6.

[0084] The process 600 provides a CDCVM process that uses a payment network’s server to intercept a no CVM card transaction and apply CDCVM to that transaction. Process 600 may enable a user to authenticate themselves during a transaction at a resource provider location without the use of a terminal (e.g., a POS) associated with a resource provider computer. Process 600 will be described in conjunction with FIG. 7, which illustrates a mobile device 702 which can be used by21SUBSTITUTE SHEET ( RULE 26 )a user or cardholder during process 600. The mobile device 702 can display a series of GUIs (e.g., GUIs 704A-704F) during completion of the process 600.

[0085] At step S601 , a cardholder downloads an application to a mobile device (e g., mobile device 702). The application can be used to enroll a cardholder biometric authentication method or password as CDCVM. For example, the cardholder can interact with an interface of the mobile device 702 to complete the enrollment process by entering or recording authentication data using the mobile device 702.

[0086] The interface of the mobile device 702 can display a GUI 704A during enrollment in the application (e.g., a mobile card authentication application). The GUI 704A can prompt the cardholder to enroll an authentication method, e.g., facial recognition, to be used as CDCVM. The application can have access to issuer information, such as a number of cards associated with the cardholder. The cards associated with the cardholder can be displayed in the application, e.g., via a GUI 704B. The cardholder can then select a card (e.g., a card associated with a PAN) to link with the CDCVM. The application can store, or encrypt and store, the authentication information received from the cardholder. Upon successful enrollment of the cardholder by the application, the mobile device 702 can display a GUI 704C.

[0087] At step S602, the cardholder can launch the application and perform CDCVM and the CDCVM is transmitted to a server via a network, e.g., a mobile internet connection. For example, the cardholder can launch the application and perform CDCVM prior to beginning a card-based transaction at a location of a resource provider. In such cases, an issuer, payment network, or the cardholder can configure the mobile CDCVM to be valid for a particular amount of time (e.g., sixty seconds) or within a particular radius of the mobile device (e.g., a geolocation radius of three miles). Thus, a transaction occurring outside the set parameters can be denied, can be flagged as fraud, or can require additional means of authentication (e.g., a PIN).

[0088] At step S603, the cardholder can start a card-based transaction at a PCS associated with a resource provider. The POS can be pre-configured to allow a22SUBSTITUTE SHEET ( RULE 26 )cardholder to select “No CVM” as an authentication method, or as the primary authentication method. Thus, the POS can proceed with “No CVM” to process the transaction.

[0089] At step S604, the card-based transaction is sent, via a network, to a payment service provider, then an acquirer, then a payment network where the payment network server (e.g, a processing server) intercepts the transaction and begins the “No CVM” authentication process.

[0090] At step S604.A, if CDCVM is set for the card in the card-based transaction, e.g, if the card has been enrolled using the application, the payment network server can flag the CDCVM in an authorization message to overwrite the “No CVM” selection. The payment network server can then transmit the authorization message to an issuer 606, associated with the card used in the card-based transaction. The authorization message can include information configure to cause the issuer 606 to accept the card-based transaction.

[0091] At step S604.B, the payment network server can determine that CDCVM is not set for the card used in the card-based transaction and that no CVM is needed for the pending transaction. In such case, the payment network server sends an authorization to the issuer 606 to accept the transaction.

[0092] At step S604.C, if CVM is required for the card-based transaction, one of steps S604.C.a or S604.C.b can occur. SVM can be required in cases in which strong consumer authentication (SCA) is required or when the transaction is of an amount above a preset threshold.

[0093] At step S604.C.a, if the card used in the card-based transaction is not registered with the application, the payment network server can send a SCA message to the POS 608 to cause the POS 608 to request the cardholder enter their PIN via the POS 608.

[0094] At step S604.C.b, if the card used in the card-based transaction is registered, then the payment network server can transmit a push notification to the mobile device 702 of the cardholder to cause the mobile device 702 to display a notification, e.g, to display a GUI 704D.23SUBSTITUTE SHEET ( RULE 26 )

[0095] At step 6O4.C.b.i, responsive to the push notification, the cardholder can authenticate the CDCVM in the application. For example, the mobile device 702 can display a GUI 704E configured to prompt the cardholder to provide authentication information associated with the card used in the card-based transaction. The GUI 704E can also include functionality to allow the cardholder to reject the transaction as described at step 6O4.C.b.ii,

[0096] Upon successful authentication, the payment network server can overwrite “No CVM” in an authorization message and transmit the authorization message to the issuer 606 to cause the issuer 606 to accept the transaction.

[0097] At step 6O4.C.b.ii, the cardholder rejects the CDCVM in the application, (e.g., the application 610) via the GUI 704E. In response, the application can notify, via a GUI 704F, the cardholder of a security threat such as a lost or stolen card. The GUI 704F may additionally prompt the cardholder to contact the issuer of the card. Further, in response to the transaction being rejected by the cardholder, the payment network server can deny the transaction authorization and notify the issuer 606 to decline the transaction.

[0098] At step 6O4.C.b.iii, a GUI, such as the GUI 704E can be provided to the cardholder via the mobile device 702 and the cardholder may not provide a response. For example, the notification can timeout after a preset period of time (e.g., ten seconds, thirty second, sixty seconds, etc.). The preset period of time can be set by the issuer or payment service provider. Once the preset time is reached and no input is received, the payment network server can send an SCA message to the POS 608 to prompt the cardholder to enter a PIN on the POS 608 to proceed with the card-based transaction.

[0099] As described, the inventive service may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In 24SUBSTITUTE SHEET ( RULE 26 )other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0100] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, integrated circuit assemblies memory such as a flash memory or a solid state storage, or an optical medium such as a CD- ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0101] While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to be restrictive of the broad invention, and that this invention is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.

[0102] As used herein, the use of “a,” "an,” or “the,” is intended to mean “at least one,” unless specifically indicated to the contrary.25SUBSTITUTE SHEET ( RULE 26 )

Claims

WHAT IS CLAIMED IS:

1. A method comprising: receiving, by a processing server, transaction data including an account identifier from a resource provider computer for a transaction between a user associated with the account identifier and a resource provider associated with the resource provider computer; identifying, by the processing server, that authentication data is missing from the transaction data; identifying, by the processing server, that the user is enrolled in a digital authentication program; retrieving, by the processing server, the authentication data of the user via a user device of the user; performing, by the processing server, a cardholder verification process using the authentication data retrieved from the user device; generating, by the processing server, an authorization request message including the transaction data received from the resource provider computer and an outcome of the cardholder verification process using the authentication data retrieved from the user device; and transmitting, by the processing server, the authorization request message to an issuer computer, wherein the issuer computer authorizes or declines the transaction based on at least the outcome of the cardholder verification process.

2. The method of claim 1 , wherein the authentication data includes one or more of biometric data or a password.

3. The method of claim 1 , wherein retrieving the authentication data further comprises: receiving, by the processing server, the authentication data from the user device prior to or during processing of the transaction.26SUBSTITUTE SHEET ( RULE 26 )4. The method of claim 1 , wherein retrieving the authentication data further comprises: upon identifying that the user is enrolled in the digital authentication program, transmitting a push notification to the user device; and receiving, by the processing server, the authentication data from the user device in response to the push notification.

5. The method of claim 1 , wherein performing the cardholder verification process further comprises: receiving, by the processing server, a control authentication data from the user device during enrollment of the user in the digital authentication program; and comparing, by the processing server, the control authentication data to the authentication data retrieved in connection with the transaction.

6. The method of claim 1 , further comprising: enrolling, by the processing server, the user in the digital authentication program.

7. The method of claim 1 , wherein the transaction is a card-present transaction during which a payment device is physically presented to the resource provider.

8. The method of claim 1 , wherein the authentication data is provided in lieu of a PIN entered on a terminal of the resource provider.

9. The method of claim 1 , wherein the authentication data of the user is retrieved from an application provisioned on the user device, and managed by the processing server.

10. The method of claim 1 , further comprising: managing, by the processing server, an application executing on the user device, wherein the application is configured to control one or more27SUBSTITUTE SHEET ( RULE 26 )components of the user device to capture the authentication data of the user using one or more components of the user device.

11. The method of claim 10, wherein the application is launched on the user device prior to initiating the transaction, and receives the authentication data from the user, wherein the method further comprises: retrieving, by the processing server, the authentication data from the application after the processing server receives the transaction data from the resource provider computer.

12. The method of claim 10, wherein the application is launched on the user device in response to the processing server requesting the authentication data, and wherein the method further comprises: retrieving, by the processing server, the authentication data from the application.

13. A processing server comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising: receiving transaction data including an account identifier from a resource provider computer for a transaction between a user associated with the account identifier and a resource provider associated with the resource provider computer; identifying that authentication data is missing from the transaction data; identifying that the user is enrolled in a digital authentication program; retrieving the authentication data of the user via a user device of the user; performing a cardholder verification process using the authentication data retrieved from the user device; generating an authorization request message including the transaction data received from the resource provider computer and an28SUBSTITUTE SHEET ( RULE 26 )outcome of the cardholder verification process using the authentication data retrieved from the user device; and transmitting the authorization request message to an issuer computer, wherein the issuer computer authorizes or declines the transaction based on at least the outcome of the cardholder verification process.

14. The processing server of claim 13, wherein the authentication data includes one or more of biometric data or a password, and wherein the authentication data is provided in lieu of a PIN entered on a terminal of the resource provider.

15. The processing server of claim 13, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: enroll the user in the digital authentication program by instructing the user to provide a control authentication data to the user device; transmit a push notification to the user device; receive the authentication data from the user device in response to the push notification; receive the control authentication data from the user device; and compare the control authentication data to the authentication data retrieved in connection with the transaction.

16. The processing server of claim 13, wherein the transaction is a card-present transaction during which a payment device is physically presented to the resource provider.

17. The processing server of claim 13, wherein the authentication data of the user is retrieved from an application provisioned on the user device, and managed by the processing server.

18. The processing server of claim 13, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to:29SUBSTITUTE SHEET ( RULE 26 )manage an application executing on the user device, wherein the application is configured to control one or more components of the user device to capture the authentication data of the user via one or more components of the user device.

19. The processing server of claim 18, wherein the application is launched on the user device prior to the transaction is initiated, and the application receives the authentication data, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: retrieve the authentication data from the application after the processing server receives the transaction data from the resource provider computer.

20. The processing server of claim 18, wherein the application is launched on the user device in response to the processing server requesting the authentication data, and wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: retrieve the authentication data from the application.30SUBSTITUTE SHEET ( RULE 26 )

Images