ENHANCEMENTS TO TRANSACTION PROCESSING IN A SECURE ENVIRONMENT
Embodiments of the present invention are directed to methods, systems, and apparatuses for performing a secure authentication process to authenticate a payment device used in a transaction between a merchant and a user. The secure authentication process may receive an authentication request message including user data, user computing device data and transaction data to verify that an account is enrolled in the secure authentication process and perform a risk analysis to determine whether the transaction should be authenticated.
This application claims the benefit of priority U.S. Provisional Application No. 61/897,167, filed Oct. 29, 2013, titled “ENHANCEMENTS TO TRANSACTION PROCESSING IN A SECURE ENVIRONMENT,” and U.S. Provisional Application No. 61/936,298, filed Feb. 5, 2014, titled “ENHANCED DEVICE DATA FOR PROCESSING IN A SECURE ENVIRONMENT,” which are incorporated by reference in their entirety for all purposes.
This application is related to co-pending U.S. patent application Ser. No. ______ (Attorney Docket No. 79900-922590), which is being filed on the same day as the present application, titled “ENHANCEMENTS TO TRANSACTION PROCESSING IN A SECURE ENVIRONMENT USING A MERCHANT COMPUTER,” which is incorporated by reference in its entirety for all purposes.
BACKGROUNDThe Internet has made it increasingly easy for users to conduct electronic commerce transactions (e.g., online purchases). Users can perform transactions using computing devices, such as smartphones, tablet computers, and personal computers, without having to interact with another person. However, it has also increased the risks to merchants and issuers from fraudulent transactions. Transactions conducted over a communications network, such as the Internet, make it very difficult for a merchant, issuer or payment processing network to know whether the person conducting the transaction is the actual account holder or user.
One solution is to have the user to enroll in an authentication scheme through a secure environment that requires the user to provide a password when conducting a transaction. When the user conducts a transaction, typical transaction processing in the secure environment is a multi-stage process, as described in U.S. patent application Ser. No. 12/419,115. This process may require: (1) a first pair of data messages for an enrollment verification process to determine whether a user is enrolled in the authentication process, and (2) a second pair of data messages for a payment authentication process to authenticate the payment device used in the transaction. Each stage is conducted using separate pairs of request and response data messages.
One problem with the prior solution is that the process of sending and receiving enrollment verification messages and then conducting a second process of sending and receiving payment authentication messages may be time-consuming and resource-consuming as it requires many messages being passed between computers. In addition, the prior art solution creates friction that slows down transaction processing as every transaction must include a challenge process that requires user interaction to provide a password to authenticate every transaction.
Embodiments of the invention address the above problems, and other problems, individually and collectively.
BRIEF SUMMARYEmbodiments of the invention are directed to methods, systems, and apparatuses for performing authentications for transactions using a single message pair sent by a user computing device to an authentication program. An access control server computer may be configured to receive an authentication request message including user data, user computing data and transaction data. The access control server computer may be further configured to verify the enrollment of an account in a secure authentication program, perform a risk analysis to determine whether the transaction should be authenticated, and return an authentication response message to the user computing device while requiring only limited or no action by the user associated with the user computing device.
One embodiment of the invention is directed to a method comprising, receiving an authentication request message for a transaction involving a user computing device associated with a user. The authentication request message may include user data, user computing device data, and transaction data. The method further comprises determining if authentication is available for the transaction by determining whether an account identifier associated with the user is enrolled in an authentication program. When authentication is available for the transaction, a risk analysis is performed using the user data, the user computing device data, and the transaction data received in the authentication request message to compute a risk score. When the risk score determined from the risk analysis is on a first side of a threshold, the method further comprises initiating generating a verification value, and provisioning the verification value to the user computing device in an authentication response message. When the risk score determined from the risk analysis is on a second side of the threshold, the method further comprises initiating generating and sending a challenge request message to the user computing device, and provisioning the verification value to the user computing device in the authentication response message, after the challenge request message is generated and sent.
Another embodiment of invention is directed to a access server computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for implementing a method. The method comprises receiving an authentication request message for a transaction involving a user computing device associated with a user. The authentication request message may include user data, user computing device data, and transaction data. The method further comprises determining if authentication is available for the transaction by determining whether an account identifier associated with the user is enrolled in an authentication program. When authentication is available for the transaction, a risk analysis is performed using the user data, the user computing device data, and the transaction data received in the authentication request message to compute a risk score. When the risk score determined from the risk analysis is on a first side of a threshold, the method further comprises initiating generating a verification value, and provisioning the verification value to the user computing device in an authentication response message. When the risk score determined from the risk analysis is on a second side of the threshold, the method further comprises initiating generating and sending a challenge request message to the user computing device, and provisioning the verification value to the user computing device in the authentication response message, after the challenge request message is generated and sent.
These and other embodiments of the invention are described in further detail below with reference to the Drawings and the Detailed Description.
Embodiments of the present invention may be directed at enhancing the process of verifying and authenticating payment devices used in financial transactions between a user and a merchant. Embodiments of the invention may also be directed to authenticating a user for verifying the age or identity of the user for non-financial transactions. Embodiments of the present invention may use an existing secure environment (e.g., 3-D Secure® or Verified by Visa®) in order to conduct an enrollment verification and authentication in a single message pair process. The single message pair process may include user data, transaction data, and user computing device data to verify enrollment of a payment device in the secure authentication program, as well as part of a risk analysis to determine a risk level associated with the transaction. Low risk levels may result in the generation of a verification value (e.g., cardholder authentication verification value or CAVV) for the transaction, while high risk levels may result in a request for additional authentication processes (e.g., secure data elements, passwords or challenge questions).
Prior to discussing embodiments of the invention, descriptions of some terms may be helpful in providing a better understanding of the invention.
The term “transaction” may include an exchange or interaction between two entities. In some embodiments, a transaction may refer to a transfer of value between two users (e.g., individuals or entities). A transaction may involve the exchange of monetary funds, or the exchange of goods or services for monetary funds between two individuals or entities. In other embodiments, the transaction may be a purchase transaction involving an individual or entity purchasing goods or services from a merchant or other entity in exchange for monetary funds. In other embodiments, the transaction may be a non-financial transaction, such as exchanging of data or information between two entities, such as the transfer of data. Examples of non-financial transactions may include transactions verifying a user's age or identity (e.g., verifying identity with a government agency, verifying age for the purchase of alcohol).
An “authentication request message” may include a message sent as part of an authentication process. The authentication request message may request an authentication process be performed for a user, a user computing device, or a payment device.
An “authentication response message” may include a message sent as part of an authentication process in response to an authentication request message. An authentication response message may include the results of an authentication process based on data received in the authentication request message.
The term “message” may include any data or information that may be transported from one entity to another entity (e.g., one computing device to another computing device). Messages may be communicated internally between devices/components within a computer or computing system or externally between devices over a communications network. Additionally, messages may be modified, altered, or otherwise changed to comprise encrypted or anonymized information.
The term “account identifier” may include any information that may be used to identify an account. For example, the account identifier may be an account number associated with a financial account (e.g., a credit card number or debit card number) or a non-financial account, or may be a special identifier generated randomly or according to a predetermined algorithm, code, or shared secret. The account identifier for a financial account may be generated by an issuer associated with the financial account. The account identifier may also be embedded in a payment device, such as in a magnetic stripe portion or a contact/contactless chip of a payment device in the form of a payment card. In other embodiments, the account identifier may be stored in a memory component of a user computing device for identifying the financial account associated with the account identifier. In some embodiments, the account identifier may be based on user or consumer data. In some embodiments, the account identifier may include a series of alphanumeric characters, one or more graphics, a token, a bar code, a QR code, or any other information that may be associated with an account.
The term “initiating” may include the first steps taken in order to begin a process or the steps conducted in order to complete a process. For example, “initiating generating a verification value” can refer to the actual process required to generate the verification value. However, “initiating generating a verification value” can also refer to the process of sending a message from one computer to another computer, with instructions for performing the process required to generate the verification value.
The term “authorization process” may include a process for authorizing a transaction. In some embodiments, an authorization process involves a payment processing server computer and an issuer computer associated with a payment account or payment device. In some embodiments, the authorization process may involve the generation and sending of authorization request messages to an issuer computer to authorize a financial transaction involving a user account issued by the issuer associated with the issuer computer, and an authorization response message from the issuer computer indicating an authorization or rejection of the transaction.
A “risk analysis” may include a process for determining a risk level. The risk analysis may use data to calculate or determine a level of risk associated with a transaction. The risk analysis may use data received in an authentication request message for a transaction to determine a risk score for the transaction.
A “risk score” may include results of a risk analysis or evaluation. A risk score may be in the form of a numeric or an alphanumeric value, such as a number from 1-10 or a letter from A-Z. A risk score may indicate a relative degree of risk in a particular situation, such as a transaction. In some cases, a high risk score may indicate high risk, while a low risk score may indicate low risk.
The term “user” may refer to an individual or entity. The user may be an individual interacting with a user computing device (e.g., a mobile phone or tablet). The user may be a consumer or business that is associated with a financial account and whose financial account can be used to conduct financial transactions using a payment device associated with the financial account.
A “user computing device” may include a device that can be used to communicate with another device or system. It can include a consumer or user device that is used to conduct a transaction. The user computing device may be capable of conducting communications over a network. A user computing device may be in any suitable form. For example, suitable user computing devices can be hand-held and compact so that it can fit into a user's wallet and/or pocket (e.g., pocket-sized). The user computing device can include a processor, and memory, input devices, and output devices, operatively coupled to the processor. Specific examples of user computing devices include cellular or mobile phones, tablet computers, desktop computers personal digital assistants (PDAs), pagers, portable computers, smart cards, and the like.
A “payment device” may include a device that can be used to perform a payment transaction. Payment device may be linked to a financial account associated with the holder of the payment device, and may be useable to provide payment information for a transaction. Payment devices can include debit devices (e.g., a debit card), credit devices (e.g., a credit card), or stored value devices (e.g., a pre-paid or stored value cards). Payment devices can also include mobile phones, tablet computers, personal digital assistants (PDAs), portable computers, smart cards, and the like. Other payment devices may include non-physical forms of payment (e.g., virtual wallets, virtual accounts).
A “verification value” may include a value that may be used for establishing the authenticity of a user, an account and/or payment device. In some embodiments, the verification value may be a value or a token provided in response to a successful authentication. An example of a verification value is a cardholder authentication verification value, or CAVV, that may be provided by an issuer associated with a payment device upon authentication of the payment device. The verification value may be used in processing a payment authorization for a financial transaction.
The term “user computing device data” may include data associated with a user computing device. User computing device data may refer to data regarding a portable computing device, such as a computer or mobile phone. Examples of user computing device data may include unique device identifiers for a computer or mobile phone, an IP address, SIM card data, application data, mobile application data, browser data, and device make and model data. User computing device data may also include the device's MSISDN, or Mobile Subscriber Integrated Services Digital Network-Number, which is a number that uniquely identifies a subscription in a mobile network.
The term “user data” may include data that regarding a user or a consumer. User data may include a name, mailing address, shipping address, phone number, payment account number, date of birth, marital status, income, social security number, demographic data, etc. In some embodiments, user data may also include consumer preferences, notification methods, and prior transaction history.
The term “transaction data” may include data that regarding a transaction. Transaction data may include data for a specific transaction, including items purchased, item prices, total cost, shipping address, payment methods, merchant data, etc. In some embodiments, transaction data may be generated when the user or consumer attempts to initiate a transaction for processing. In other embodiments, transaction data may be generated and sent based on items added to a consumer's shopping cart.
A “challenge request message” may include a message sent as part of an authentication process for a transaction. In some embodiments, the challenge request message may contain a request for the user to submit a pre-established secure data element in order to authenticate an account or payment device. The challenge request message may be generated and sent prior to authenticating the account or payment device.
A “challenge response message” may include a message sent as part of an authentication process for a transaction. In some embodiments, the challenge response message may be transmitted from a user computing device to an access control server computer or a directory server computer. The challenge response message may contain a response from the user computing device to the challenge request message comprising a pre-established secure data element in order to authenticate an account or payment device.
The term “secure data element” may include a unique expression that uniquely identifies a user. The secure data element may be created by the user in an enrollment process. In other embodiments, the secure data element may be created by a computer on behalf of the user. The secure data element may be alphanumeric, or composed of only numbers or only letters. Secure data element are not limited to strings of characters. In some embodiments, a secure data element may be a password, a token, or biometric data (e.g., fingerprint, voiceprint). Other examples of secure data elements include a personal identification number (PIN) and a unique visual image or pattern.
An “application” may include a computer program. An application may be a computer program stored and/or operating on a user computing device (e.g., a computer, mobile device). An application may be used to perform financial transactions (e.g., purchase transactions) and/or non-financial transactions (e.g., using a mobile application for age or identity verification).
The term “enrolled” may refer to a registration status of a user or an account with respect to a pre-existing program. In some embodiments, in order for an account or user computing device to be authenticated by a secure authentication program, a user and/or the account is enrolled in the secure authentication program. In some embodiments, in order to be enrolled in the secure authentication program, the user may have to complete an enrollment process. In some embodiments, enrollment in the secure authentication program may be automatic.
The term “secure authentication program” may include a computer-implemented program for performing authentication processes. The secure authentication program may be performed by a directory server computer and/or an access control server computer on behalf of an issuer and/or payment processor. The secure authentication program may require enrollment of an account or user in order to provide secure authentication processes for transactions.
A “threshold” may refer to a boundary value. A value compared to the value of the threshold may be used to determine an action to perform. A threshold may be a numerical value in which values below the threshold result in the performance of a first set of actions, and values above the threshold result in the performance of a second set of actions. In some embodiments, the threshold may be a pre-established value.
The term “direct connection” may refer to a connection between two computing devices that does not have a major data processing computer such as a directory server computer, merchant computer, acquirer computer, or payment processing server computer between them. In some embodiments, a direct connection may be a direct wired or wireless communications (e.g., across a network, such as the Internet) connection between two or more computers.
A “bank identification number” may be a sequence identifying a financial institution. The bank identification number, or BIN, may include a number of digits of a debit card number, credit card number and/or an account number. The BIN may be used to identify the financial institution (e.g., bank, financial services corporation) associated with the debit card, credit card or account.
The term “merchant computer” may include a computer associated with a merchant. Examples of merchant computers may include an access device, point of sale terminal, or a web server computer hosting a merchant Internet website. The merchant computer may be in any suitable form. Additional examples of merchant computers include any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet PCs, and handheld specialized readers.
The term “issuer computer” may include a computer associated with an entity that issues an account. An issuer is typically a business entity (e.g. a bank) which maintains financial accounts for a plurality of users (e.g., consumers) and issues payment devices (e.g., credit cards, debit cards). Some entities can perform both issuer computer and acquirer computer functions. Embodiments of the invention encompass such single entity issuer-acquirers.
The term “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer 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. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
A “directory server computer” may include a server that can perform message routing. In some embodiments, the directory server computer may be capable of receiving messages (e.g., authentication request messages and authentication response response), determining the appropriate destination computer for the received messages, and routing the received messages to the appropriate destination computer. In some embodiments, the directory server computer may include or be associated with a database containing routing tables that may be used to determine an appropriate issuer computer associated with an account identifier (e.g., a bank identification number). In some embodiments, the directory server computer may be further configured to perform an enrollment verification process for the account identifier and a risk analysis process.
An “access control server computer” may be a computer or system that is configured to provide authentication and/or verification services. The access control server computer may provide authentication services for both financial and non-financial (e.g., access) transactions. In some embodiments, the access control server computer may be associated with an issuer computer. In other embodiments, the access control server computer may be associated with a payment processing server computer.
The term “payment processing server computer” may include a server computer used for payment processing. In some embodiments, the payment processing server computer 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. The payment processing server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. In some embodiments, the payment processing server computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transaction for a given region or handles transactions of a specific type based on transaction data.
The payment processing server computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing server computer may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system, which performs clearing and settlement services. The payment processing server computer may use any suitable wired or wireless network, including the Internet.
The payment processing server computer may process transaction-related messages (e.g., authorization request messages and authorization response messages) and determine the appropriate destination computer (e.g., issuer computer) for the transaction-related messages. In some embodiments, the payment processing server computer may authorize transactions on behalf of an issuer. The payment processing server computer may also handle and/or facilitate the clearing and settlement of financial transactions.
I. Exemplary SystemFor simplicity of illustration, a certain number of components are shown in
The user computing device 102 may be in any suitable form. For example, suitable user computing devices 102 may be hand-held and compact so that they can fit into a user's pocket. Examples of user computing devices 102 may include any device capable of accessing the Internet. Specific examples of user computing devices 102 include cellular or wireless phones (e.g., smartphones), tablet phones, tablet computers, laptop computers, desktop computers, personal digital assistants (PDAs), pagers, portable computers, smart cards, and the like.
The user computing device 102 may include a processor, memory, input/output devices, and a computer readable medium coupled to the processor. The computer readable medium may comprise code, executable by the processor for performing the functionality described below. The user computing device 102 may include a browser and/or applications (e.g., mobile applications, computer programs) stored in the memory and configured to retrieve, present, and send data across a communications network (e.g., the Internet).
The user computing device 102 may be configured to send data to any suitable entity as part of a transaction. The data may include user computing device data, user data and transaction data. The data may also include payment device data, geolocation data, user address, user email address, user phone number, account data, or other comparable data. In some embodiments, a mobile application used in the transaction may determine the data that is sent in the authentication request message. In some embodiments, the data that is sent in the authentication request message may be based on a merchant category code (MCC) for the merchant in the transaction. For example, if the merchant is a hotel, the number of nights being reserved may be specifically sent as part of the transaction data sent to the access control server computer 108. In other embodiments, the data sent in the authentication request message to the access control server computer 108 may be dynamically determined based on the transaction data, the user data, and the computing device data.
The merchant computer 104 may be comprised of various modules that may be embodied by computer code, residing on computer readable media. The merchant computer 104 may include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described below. Examples of merchant computer 104 may include an access device, a point of sale terminal, or a server computer hosting a merchant Internet website. The merchant computer 104 may be in any suitable form. Additional examples of merchant computers include any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet computers, and handheld specialized readers.
In some embodiments, the merchant computer 104 may transmit data through a communications medium to an acquirer computer 112 as part of an authorization process for a transaction. In some embodiments of the invention, the merchant computer 104 may receive transaction data from a user computing device 102 and transmits the transaction data to the acquirer computer 112 for transaction-related processes (e.g., authorization) in an authorization request message. In such embodiments, the authorization request message may include a verification value generated in the secure authentication process by the access control server computer 108 and sent to the user computing device 102.
The directory server computer 106 may be a server computer configured to route messages. In some embodiments, the directory server computer 106 may route messages between the user computing device 102 and the access control server computer 108. In some embodiments, the directory server computer 106 may route authentication request and response messages between the user computing device 102 and the access control server computer 108 as part of a financial or non-financial transaction. In some embodiments, the directory server computer 106 may be operated by a payment processing server computer 114.
In some embodiments, the directory server computer 106 may be configured to perform an enrollment verification process on behalf of the access control server computer 108. In such embodiments, the directory server computer 106 may store data regarding accounts or account identifiers that are enrolled in the secure authentication program.
In some embodiments, the directory server computer 106 may be further configured to perform a risk analysis using user data, user computing device data and/or transaction data received in the authentication request message for a transaction from the user computing device 102. In such embodiments, the directory server computer 106 may determine a risk score for the transaction and send the risk score to the access control server computer 108 for additional authentication processing.
In some embodiments, the directory server computer 106 may be configured to conduct a challenge process with the user computing device 102. In such embodiments, the directory server computer 106 may generate a challenge request message requesting a user provide a pre-established secure data element (e.g., password, token, biometric data) in order to authenticate the transaction and/or the payment device. In such embodiments, the directory server computer 106 may evaluate the secure data element received in a challenge response message and determine whether the received secure data element matches a stored secure data element.
The access control server computer 108 may comprise a server computer that may be configured to conduct authentication and authorization processes. The access control server computer 108 may be associated with an issuer, which can be an entity (e.g., bank, financial institution) that issues and maintains financial accounts for a user. The access control server computer 108 may authenticate a transaction using an account identifier (e.g., account number) associated with the user. The access control server computer 108 may use user data, user computing device data and/or transaction data, PAN, payment device data, geolocation data, account data, or other comparable data, in order to perform an authentication for the transaction. In some embodiments, at the time of a transaction, the access control server computer 108 may perform the authentication, and may provide digitally signed responses to the user computing device 102 through the directory server computer 106. In other embodiments, the access control server computer 108 may send an authentication response message back to the user computing device 102 directly via a direct connection.
In some embodiments, the access control server computer 108 may be configured to perform a risk analysis using user data, user computing device data and/or transaction data received in the authentication request message for a transaction from the user computing device 102. As noted above, the authentication request message may include payment device data, geolocation data, account data, or other similar data related to financial transactions. In some embodiments, the authentication request message may include non-financial transaction-related data, including browser data, mobile application data, etc. The access control server computer 108 may use this data to determine a risk score associated with a payment device or account that is being used for a transaction.
The access control server computer 108 may be configured to return an authentication response message. The authentication response message may be based on the risk analysis conducted by the access control server computer 108 or the directory server computer 106. The authentication response message may provide an indication to the user computing device 102 the account or payment device has been authenticated or not authenticated.
In some embodiments, when the risk score associated with the payment device or account is on one side of a pre-defined or user-defined risk threshold (e.g., below a threshold), the access control server computer 108 may provide an indication in the authentication response message that the account or payment device has been authenticated and that the transaction may proceed. For example, given a risk analysis where the risk score is within a range from 0-10, with 10 being the highest likelihood of fraud and 0 being the lowest likelihood of fraud, a risk score of 5 may be established as a risk threshold. In such an example, transactions with risk scores of 0-4 may be considered low risk, while transactions with risk scores of 5-10 may be considered higher risk and subject to additional authentication processes.
In some embodiments, when the risk score associated with the payment device or account is on another side of the pre-defined or user-defined risk threshold (e.g., above the threshold), the access control server computer 108 may provide an indication in the authentication response message that the account or payment device has not been authenticated and that the transaction may not proceed. In such embodiments, the access control server computer 108 may be further configured to conduct additional authentication processes using a challenge process with the user computing device 102. In such embodiments, the access control server computer 108 may generate a challenge request message requesting a user provide a pre-established secure data element (e.g., password, token, biometric data) in order to authenticate the transaction and/or the payment device. In such embodiments, the access control server computer 108 may evaluate the secure data element received in a challenge response message and determine whether the received secure data element matches a stored secure data element. In some embodiments, the challenge process may be conducted through a direct connection between the access control server computer 108 and the user computing device 102. In other embodiments, the challenge process may be conducted between the user computing device 102 and the access control server computer 108 through a directory server computer 106.
As noted above, the enrollment verification process and the risk analysis process of the secure authentication process may be performed by either the directory server computer 106, the access control server computer 108, or a combination of the two computers.
During an authorization process for a transaction, the access control server computer 108 may generate authorization response messages for authorizing or rejecting a user's account or payment device for payment for a requested transaction and provide digitally signed receipts to merchants. In some embodiments, the access control server computer 108 may be operated by an issuer. In other embodiments, a payment processing server computer 114 may operate the access control server computer 108 on behalf of the issuer.
The authentication history server computer 110 may be a database connected to the directory server computer 106 that can be accessed as part of the authentication process. For example, the authentication history server computer 110 may store user authentication data associated with user computing devices, payment devices or account numbers. The authentication history server computer 110 may further store user computing device authentication data for user enrolled in account authentication services. In some embodiments, the directory server computer 106 may query the authentication history server computer 110 as part of an authentication process. In some embodiments, after an authentication process has been completed, data related to the authentication process, including an indication of whether the authentication process was completed successfully or unsuccessfully, may be stored in the authentication history server computer 110.
The acquirer computer 112 is typically a system associated with an entity (e.g., a bank) that has a business relationship with a particular merchant or other entity. The acquirer computer 112 may include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described below. The acquirer computer 112 may be configured to route transaction authorization messages between the merchant computer 104 and the payment processing server computer 114.
The payment processing server computer 114 may comprise a server computer comprising a processor and computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described below. In some embodiments, the server computer 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.
The payment processing server computer 114 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing server computer 114 may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system that processes authorization requests and a Base II system that performs clearing and settlement services. The payment processing server computer 114 may use any suitable wired or wireless network, including the Internet.
II. Exemplary MethodsIn step 1, a user initiates a transaction. In some embodiments, the user may access a mobile application stored on the user computing device 102 in order to initiate a transaction. The mobile application may be associated with a merchant operating a merchant computer 104. When the user has selected goods or services via the mobile application, the user may proceed to a checkout process for the transaction. For example, the user may select a “Buy” or “Checkout” option presented on a display of the user computing device 102.
In step 2, the mobile application on the user computing device 102 generates and sends an authentication request message. When the checkout process for the transaction is initiated, the user computing device 102 may be configured to generate and send data an authentication request message to a directory server computer 106 to be used in an enrollment verification and risk analysis, as part of an authentication process. The authentication request message may be sent over a secure connection by the user computing device 102 to the directory server computer 106.
The data sent in the authentication request message may include user computing device data (e.g., operating system data, browser data, mobile application data, geo-location data), user data (e.g., user name, user address data, user email address, user phone number), and transaction data (e.g., shopping cart data, payment device data, payment account number), and/or other comparable data.
In some embodiments, the mobile application stored on the user computing device 102 may store all the data for the merchant within the mobile application, and accessing the merchant computer 104 may not be required. In such embodiments of the present invention, software and data libraries associated with the secure authentication process may be integrated into the mobile application stored on the user computing device 102. In such embodiments, the software, application programming interfaces, and data libraries may enable the mobile application to generate and format the authentication request message to perform the secure authentication process with the access control server computer 108. The mobile application may also store software components for a merchant plug-in module, which may act as a proxy for re-directing the user computing device 102 to the web address (or URL) of the directory server computer 106 and/or the access control server computer 108.
In step 3, the directory server computer 106 may route the authentication request message to an appropriate access control server computer 108 associated with the received payment device data. In some embodiments, the payment device may be a virtual wallet or virtual account. For example, the directory server computer 106 may evaluate the data in the authentication request message and search for an account range that includes a bank identification number (“BIN”) or personal account number (“PAN”) received in the authentication request message.
In step 4, the access control server computer 108 may receive the authentication request message from the directory server computer 106. The access control server computer 108 may then perform an enrollment verification process and a risk analysis using the data received in the authentication request message.
In some embodiments, as part of the enrollment verification process, the access control server computer 108 may determine whether an account identifier (e.g., an account number) has been previously enrolled in the secure authentication program provided by the access control server computer 108. The access control server computer 108 may contain or have access to a database which stores enrolled account identifiers. In some embodiments, authentication may be available for the payment device used in the transaction when a bank identification number (BIN) associated with the payment device is within a BIN range provided by an issuer (e.g., bank). In some embodiments, when the account identifier is not enrolled in the secure authentication program, the access control server computer 108 may not perform an authentication for the transaction and return an authentication response message indicating that no authentication process was performed.
In some embodiments, when the account identifier is enrolled in the secure authentication program, the access control server computer 108 may perform a risk analysis using the user data, user computing device data, and transaction data received in the authentication request message. In some embodiments, the risk analysis may include analyzing previous transactions associated with the payment device, an account identifier and/or the user computing device data. In some embodiments, the risk analysis may return a risk score associated with the transaction. The access control server computer 108 may evaluate the risk score against a pre-established risk threshold.
When the risk score is on a first side of the threshold (e.g., below the threshold), the transaction may be deemed to be low risk. In such situations, the access control server computer 108 may not require any interaction with the user or the user computing device for additional authentication data. In some embodiments, where the risk score indicates that the transaction is low risk, steps 5 and 6 may not be required. For example, given a risk analysis where the risk score is within a range from 0-10, with 10 being the highest likelihood of fraud and 0 being the lowest likelihood of fraud, a risk score of 5 may be established as a risk threshold. In such situations, where the risk score determined from the risk analysis is between 0 and 4, the transaction may be considered low risk, and the process may proceed to step 7 for generation and sending of a verification value.
However, when the risk score is on a second side of the threshold (e.g., above the threshold), the transaction may be deemed to be high risk. In such situation, the access control server computer 108 may require additional data from the user associated with the user computing device 102 in order to authenticate the transaction. Using the example above, where the risk score determined from the risk analysis is between 5 and 10, the transaction may be considered high risk, and the process may continue to step 5 for further authentication processes (e.g., a challenge process).
In some embodiments, the enrollment verification process and the risk analysis using the data received in the authentication request message may be performed by the directory server computer 106 on behalf of the access control server computer 108. In some embodiments, the risk score determined by the risk analysis by the directory server computer 106 may then be sent to the access control server computer 108 for further authentication decisioning.
In step 5, when the access control server computer 108 requires additional data to authenticate the transaction, the access control server computer 108 may initiate a challenge process with the user. The access control server computer 108 may generate and send a challenge request message to the user computing device 102. The challenge request message may request that the user associated with the user computing device provide a pre-established secure data element (e.g., password, token or biometric data). The challenge request message may be presented to the user on the display of the user computing device as a web interface sent across a communications network (e.g., Internet), or may be sent to the consumer via other types of communications (e.g., SMS messaging, email messaging). In some embodiments, the challenge request message may be sent directly from the access control server computer 108 to the user computing device 102. In other embodiments, the challenge request message may be sent to the user computing device 102 through the directory server computer 106. The challenge request message may be sent through the secure connection established by the mobile application.
In step 6, the user computing device 102 returns a challenge response message to the access control server computer 108. The challenge response message may include the secure data element request by the access control server computer 108 in the challenge request message. In some embodiments, the challenge response message may be sent directly to the access control server computer 108 from the user computing device 102. In other embodiments, the challenge response message may be sent from the user computing device 102 to the access control server computer 108 through the directory server computer 106. The access control server computer 108 may evaluate the received secure data element against the pre-established secure data element stored by the access control server computer 108. When the received secure data element and the stored secure data element match or are within an expected range, the transaction may be authenticated.
In some embodiments, steps 5 and 6 may be repeated until either the number of times the secure data element can be requested from the user computing device 102 is exceeded, the access control server computer 108 successfully authenticates the user and generates the verification value, or the authentication is determined to be unsuccessful and the access control server computer 108 generates the authentication response message indicating a failed authentication.
In step 7, the access control server computer 107 may generate and send an authentication response message to the directory server computer 106. The generated authentication response message may include a verification value for the transaction generated in response to a successful authentication. In some embodiments, the verification value may be a card authentication verification value (“CAVV”). This value can be a cryptogram that has any suitable number of characters (e.g., 3-10). The directory server computer 106 may then route the authentication response message back to the user computing device 102. In other embodiments, the authentication response message may be sent back to the user computing device 102 through a direct connection. The direct connection may be a wired or wireless communications connection.
In step 8, the mobile application stored on the user computing device 102 may receive the authentication response message including the verification value from the directory server computer 106. The mobile application may send the verification value to the merchant computer 104 associated with the mobile application to conduct authorization processes for the transaction.
In step 9, the merchant computer 104 may generate an authorization request message for the transaction. The authorization request message may include transaction data, payment data, and the verification value generated by the access control server computer 108. The merchant computer 104 may send the authorization request message to an acquirer computer 112 associated with an account of the merchant. The acquirer computer 112 may then send the authorization request message to the access control server computer 108 via a payment processing server computer 114. In such embodiments, the access control server computer 108 may be associated with an issuer computer of the user account provided by the user for the transaction. In other embodiments, the authorization request message may be sent to an issuer computer separate from the access control server computer 108. The access control server computer 108 may determine whether the transaction should be authorized or declined by evaluating account details (e.g., account balance, transaction velocity). The access control server computer 108 may then generate an authorization response message indicating that the transaction has been authorized or rejected. The authorization response message may be sent back to the merchant computer via the payment processing server computer 114 and the acquirer computer 112.
In step 10, based on the result of the authorization process, the merchant computer 104 may proceed and finalize the transaction, or may end the transaction. The merchant computer 104 may finalize the transaction by providing goods or services to the user.
In step 11, data for the authentication process may be stored in the authentication history server 114. The authentication history server 114 may store data received in the authentication request message and data indicating the result of the authentication process performed by the directory server computer 106 and the access control server computer 108.
The embodiment described in
For example, a user may want to prove their age in order to purchase alcohol. In this non-financial transaction scenario, the user may access a mobile application on the user computing device 102 that is configured for generating and formatting authentication request messages for the secure authentication program. The mobile application may send user computing device data and user data in the authentication request message to request an age verification of the user. For example, the mobile application may provide the user's name and other identifying information as part of the authentication request message. In some embodiments, a payment device enrolled in the secure authentication program may include user data that may be used in verifying the age of the user. In this situation, the access control server computer 108 would evaluate the user data and generate an authentication response message with an indicator (e.g., a Yes/No, a risk level or risk confidence indicator) in response to the query.
In step 202, the server computer receives an authentication request message for a transaction involving a user computing device 102. The authentication request message may include user data, user computing device data, and transaction data. In some embodiments, the transaction may be a purchase transaction. In other embodiments, the transaction may be a transaction verify a user identity. The server computer may receive the authentication request from a user computing device 102 associated with a user. In some embodiments, the server computer may be a directory server computer 106. In other embodiments, the server computer may be an access control server computer 108.
In step 204, the server computer determines if authentication is available for the transaction by determining whether an account identifier associated with the user is enrolled in a secure authentication program. For example, the server computer may determine whether the account identifier (e.g., BIN, PAN) is an account identifier that has been enrolled in the secure authentication program. In some embodiments, enrollment may be performed by the user or by the issuer of a payment device associated with the account identifier.
In step 206, the server computer performs a risk analysis using the user data, the user computing device data, and the transaction data received in the authentication request message to compute a risk score. The risk score may be determined based on the data received in the authentication request message and data retrieved from an authentication history server computer 110 from previous authentication processes involving the account identifier. In some embodiments, the risk analysis may include analyzing previous transactions associated with the payment device, an account identifier and/or the user computing device data.
In step 208, the server computer determines whether the risk score determined from the risk analysis is on a first side of a threshold. Once the risk score has been determined by the server computer, the risk score is compared against a pre-established risk threshold to determine whether the risk score exceeds a risk level established by the issuer.
In step 210, when the risk score is on the first side of the threshold, the server computer initiates generating a verification value. In some embodiments, when the risk score is on the first side of the threshold (e.g., below the threshold), the transaction may be deemed not risky. In such embodiments, the server computer may initiate the generation of a verification value for the payment device to be used in the transaction.
In step 212, the server computer provisions the verification value to the user computing device 102 in an authentication response message. The server computer may initiate the process of sending the verification value to the user computing device 102 by generating the authentication response message and providing the authentication response message to the user computing device 102 or by providing the authentication response message generated by the access control server computer 108 to the user computing device 102.
In step 214, the server computer initiates generating a challenge request message. In some embodiments, when the risk score is on the second side of the threshold (e.g., above the threshold), the transaction may be deemed higher risk. In such embodiments, the server computer may initiate the generation of a challenge request message. The challenge request message may request that a secure data element be provided by the user. Examples of secure data elements include a password, a token, and/or biometric data.
In step 216, the server computer sends the challenge request message to the user computing device 102. The challenge request message may be sent to the user computing device 102 by a direct connection between the user computing device 102 and the server computer.
In step 218, the server computer receives a challenge response message from the user computing device 102. The challenge response message may include the secure data element provided by a user associated with the user computing device 102.
In step 220, the server computer evaluates the received secure data element against a stored secure data element. The server computer may evaluate the received secure data element to determine whether the received secure data element matches or is within a range of a stored secure data element. The stored secure data element may have been stored by the server computer during an enrollment process previously performed for the account identifier.
In step 222, when the received secure data element matches a stored secure data element, the transaction is authenticated by the server computer. In such situations, the process proceeds to steps 210 for the generation of a verification value. In some embodiments, when the received secure data element does not match the stored secure data element or is not within the range of the stored secure data element, the authentication process may terminate and the server computer may provide an indication in the authentication response message that authentication was unsuccessful. In other embodiments, additional authentication processes may be performed to authenticate the transaction.
In step 301, a user initiates a transaction. In some embodiments, the user may access a mobile application stored on the user computing device 102 in order to initiate a transaction. The mobile application may be associated with a merchant operating a merchant computer 104. In some embodiments, the user may access a merchant website stored on the merchant computer 104 (e.g., a merchant web server computer) using an Internet browser stored on the user computing device 102.
In step 302, the mobile application stored on the user computing device 102 accesses a merchant computer 104 to retrieve merchant content (e.g., merchant product catalog, merchant website). In such embodiments, the mobile application stored on the user computing device 102 may include a user interface configured for accessing merchant data on the merchant computer 104.
In other embodiments, the user may access a merchant website hosted on a merchant computer 104 using a browser stored on the user computing device 102. In such embodiments, the browser may access the merchant computer 104 to retrieve merchant data for presentation on the display of the user computing device 102. In such embodiments, the merchant computer 104 may be configured to re-direct the browser on the user computing device 102 to the web address (i.e., URL) of the directory server computer 106 and/or the access control server computer 108.
In step 303, the merchant computer 104 may send merchant data to the mobile application for presentation on the user computing device 102. For example, the mobile application may provide a user interface or web portal on the display of the user computing device 102, while presenting merchant content and data retrieved from the merchant computer 104.
In step 304, when the user has selected goods or services via the mobile application, the user may proceed to a checkout process for the transaction. For example, the user may select a “Buy” or “Checkout” option presented on a display of the user computing device 102. When the checkout process for the transaction is initiated, the user computing device 102 may be configured to generate and send data in the authentication request message to a directory server computer 106 to be used in an enrollment verification and risk analysis, as part of an authentication process. In some embodiments, the authentication request message may be generated by the merchant computer 104 associated with the mobile application, and sent to the user computing device 102. The authentication request message may be sent over a secure connection by the user computing device 102 to the directory server computer 106.
In step 305, the directory server computer 106 may route the authentication request message to an appropriate access control server computer 108 associated with the received payment device data as described previously in step 3 of
In step 306, the access control server computer 108 may receive the authentication request message from the directory server computer 106. The access control server computer 108 may then perform an enrollment verification process and a risk analysis using the data received in the authentication request message, as described previously in step 4 of
In steps 307 and 308, when the risk score indicates that the transaction is high risk, a challenge process may be performed between the access control server computer 108 and the user computing device, as described previously in steps 5-6 of
In step 309, the access control server computer 107 may generate and send an authentication response message to the user computing device 102 via directory server computer 106, as described previously in step 7 of
In steps 310-311, the verification value may be sent from the user computing device 102 to a payment processing server computer 314 via a merchant computer 304 associated with the transaction as part of an authorization process for the transaction The authorization process for the transaction in steps 310-313 may be performed as described previously in steps 8-11, respectively, of
Embodiments of the present invention provide a number of advantages and technical benefits. For example, embodiments of the present invention provide the benefit of minimizing the messages that are required in order to perform an authentication process. Rather than performing enrollment verification and then a payment authentication step, each using separate message pairs, embodiments of the present invention may perform the entire authentication process using a single message pair.
Further, unlike previous solutions, as a risk assessment is performed based on the data received in the authentication request message, the challenge process that requires user interaction (e.g., providing a password, token, or biometric data) may only be required when there is a high risk associated with the payment device, rather than for every transaction. This results in the use fewer resources and results in less network congestion than would be required through having to perform the enrollment verification process and the payment authentication process using two message pairs.
Also, as the challenge process may be conducted between the user computing device and the access control server computer without interacting with a merchant computer, system resources and time may be saved that would typically be used to notify the merchant that additional authentication processes are required.
In addition, performing a risk analysis provides the benefit of greater confidence that a payment device and/or user are authentic. Even performing the payment authentication step requiring a user password could be susceptible to fraud if a third party comes into possession of the user password. However, the risk analysis is based on a plurality of data points including user data, payment device data, user computing device data, transaction data, geolocation data, and other comparable data, and thus may have greater reliability at preventing unauthorized transactions.
Another benefit provided by embodiments of the present invention is that the messages and the data sent as part of the secure authentication program have to travel over fewer networks. In locations where the data or communications networks are not as reliable, such as in developing countries, conducting the secure authentication process in fewer steps reduces the risk that the process may be lost, interrupted, or slowed by unreliable networks.
Additional benefits may be provided by embodiments of the present invention. For example, by re-directing the browser on the user computing device to the directory server computer, a session may be opened between the access control server computer and the user computing device, which allows the access control server computer access to additional user computing device data that would otherwise not be readily accessible. Typically, this data would not be retrieved by a merchant plug-in associated with a merchant computer as it would require the merchant to modify its transaction infrastructure.
IV. Exemplary ApparatusesExamples of such subsystems or components are shown in
Further, while the present invention has been described using a particular combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.
The software components or functions described in this application may be implemented as software code to be executed by one or more processors 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, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.
The above description is illustrative and is not restrictive. Many variations of the technology will become apparent to those skilled in the art upon review of the disclosure. The scope of the technology should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
In some embodiments, any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the technology.
Any recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.
Claims
1. A method comprising:
- receiving, at a server computer, an authentication request message for a transaction involving a user computing device associated with a user, the authentication request message including user data, user computing device data, and transaction data;
- determining, by the server computer, if authentication is available for the transaction by determining whether an account identifier associated with the user is enrolled in an authentication program;
- when authentication is available for the transaction, performing, by the server computer, a risk analysis using the user data, the user computing device data, and the transaction data received in the authentication request message to compute a risk score;
- and
- when the risk score determined from the risk analysis is on a first side of a threshold, initiating generating a verification value, and provisioning the verification value to the user computing device in an authentication response message, and
- when the risk score determined from the risk analysis is on a second side of the threshold, initiating generating and sending a challenge request message to the user computing device, and provisioning the verification value to the user computing device in the authentication response message, after the challenge request message is generated and sent.
2. The method of claim 1, wherein the server computer is an access control server computer, and wherein initiating generating and sending the challenge request message to the user computing device includes generating and sending, by the access control server computer, the challenge request message to the user computing device, and wherein the method further comprises:
- receiving, by the access control server computer, a challenge response message from the user computing device, the challenge response message including a secure data element, and
- evaluating, by the access control server computer, the received secure data element against a stored secure data element.
3. The method of claim 2, wherein evaluating the received secure data element against the stored secure data element further comprises:
- determining if the received secure data element and the stored secure data element match.
4. The method of claim 1, wherein the server computer a directory server computer.
5. The method of claim 1, wherein performing the risk analysis further comprises using previous transactions associated with the account identifier to compute the risk score.
6. The method of claim 1, wherein the secure data element includes one or more of a password, a token, and biometric data.
7. The method of claim 1, wherein the challenge request message is sent to the user computing device.
8. The method of claim 1, wherein the authentication request message is generated by an application stored on the user computing device.
9. The method of claim 8, wherein the transaction is for verification of a user identity.
10. The method of claim 1, wherein the transaction is a purchase transaction.
11. The method of claim 1, wherein the verification value is sent from the merchant computer to a payment processing server computer as part of an authorization process for the transaction.
12. The method of claim 1, wherein the first side of the threshold is below the threshold, and wherein the second side of the threshold is above the threshold.
13. The method of claim 1, wherein the authentication request message is generated by the merchant computer.
14. A server computer comprising:
- a processor; and
- a tangible non-transitory computer readable medium coupled to the processor, the tangible non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising: receiving an authentication request message for a transaction involving a user computing device associated with a user, the authentication request message including user data, user computing device data, and transaction data; determining if authentication is available for the transaction by determining whether an account identifier associated with the user is enrolled in an authentication program; when authentication is available for the transaction, performing a risk analysis using the user data, the user computing device data, and the transaction data received in the authentication request message to compute a risk score; and when the risk score determined from the risk analysis is on a first side of a threshold, initiating generating a verification value, and provisioning the verification value to the user computing device in an authentication response message, and when the risk score determined from the risk analysis is on a second side of the threshold, initiating generating and sending a challenge request message to the user computing device, and provisioning the verification value to the user computing device in the authentication response message, after the challenge request message is generated and sent.
15. The server computer of claim 14, wherein the server computer is an access control server computer, and wherein initiating generating and sending the challenge request message to the user computing device includes generating and sending, by the access control server computer, the challenge request message to the user computing device, and wherein the method further comprises:
- receiving, by the access control server computer, a challenge response message from the user computing device, the challenge response message including a secure data element, and
- evaluating, by the access control server computer, the received secure data element against a stored secure data element.
16. The server computer of claim 15, wherein evaluating the received secure data element against the stored secure data element further comprises:
- determining if the received secure data element and the stored secure data element match.
17. The server computer of claim 14, wherein the transaction is a purchase transaction.
18. The server computer of claim 14, wherein the server computer is a directory server computer.
19. The server computer of claim 14, wherein the server computer is an access control server computer.
20. The server computer of claim 14, wherein performing the risk analysis further comprises using previous transactions associated with the account identifier to compute the risk score.
Type: Application
Filed: Oct 29, 2014
Publication Date: Apr 30, 2015
Inventors: Douglas Fisher (Mountain View, CA), Karl Newland (Pacifica, CA), Patrick Wright (Mountain View, CA), Kevin Wong (Sausalito, CA), Christopher Brownlee (Alameda, CA)
Application Number: 14/527,647
International Classification: G06Q 20/40 (20060101); G06F 21/44 (20060101);
