US-12619989-B2 - Systems, apparatus and methods for improved authentication

US12619989B2US 12619989 B2US12619989 B2US 12619989B2US-12619989-B2

Abstract

A cardholder authentication method includes receiving, at an authentication network, an authentication request involving an account. The method further includes determining, based at least in part on a portion of an account identifier associated with said account, an authentication service. In addition, the method includes determining, based at least on said authentication service and a portion of said account identifier, an authentication response. The method also includes transmitting, to a merchant associated with a transaction involving said account, said authentication response.

Inventors

Craig Gilbert
Brian John Piel
Gregory D. Williamson

Assignees

MASTERCARD INTERNATIONAL INCORPORATED

Dates

Publication Date: 20260505
Application Date: 20231120

Claims (13)

1 . An authentication server, comprising: a memory; and an authentication processor coupled to the memory, the authentication processor configured to: store configuration data associated with an issuer of a payment account in the memory, determine, based on the configuration data, that use of a risk-based decisioning service has been selected for transactions associated with the issuer, receive a message transmitted from a software application on a merchant device, the message comprising a request to authenticate the payment account, determine to perform a step-up authentication of the payment account on behalf of the issuer based on a risk assessment from the risk-based decisioning service and on the configuration data associated with the issuer; transmit a response message to the software application on the merchant device with an indicator of the step-up authentication to be performed on behalf of the issuer, load web content into a user interface of a software application of a user device to enable the step-up authentication of the payment account on behalf of the issuer, receive a response comprising authentication data of the payment account from the user device via the user interface, determine, based on the response, to authenticate the payment account, and transmit an authentication response to the merchant device.
2 . The apparatus of claim 1 , wherein the message comprises one or more of an extensible markup language (XML) message and a JavaScript Object Notation (JSON) message, and the web content comprises one or more of HyperText Markup Language (HTML) web content and XML web content.
3 . The apparatus of claim 1 , wherein the processor is configured to receive a message from the issuer which establishes different authentication rules for different subsets of payment accounts of the issuer, and authenticate the different subsets of payment accounts based on the different authentication rules, respectively.
4 . The apparatus of claim 1 , wherein the processor is configured to load web content into the user interface of the software application of the user device which enables an additional authentication step that is not available from the issuer.
5 . The apparatus of claim 1 , further comprising, prior to loading web content into a user interface of the software application of the user device, establishing a secure channel between a server and the user device through an application programming interface (API), and wherein the message is received from the user device via the secure channel.
6 . The apparatus of claim 1 , wherein the processor is configured to transmit a message to the merchant device with a flag to indicate that an authentication of the payment account is being performed on behalf of the issuer.
7 . A cardholder authentication method, comprising: receiving, by an authentication server, configuration data associated with an issuer of a payment account; determining, by the authentication server based on the configuration data, that use of a risk-based decisioning service has been selected for transactions associated with the issuer; receiving, by the authentication server from a merchant device, a message transmitted from a software application on the merchant device, the message comprising a request to authenticate the payment account; determining, by the authentication server, to perform a step-up authentication of the payment account on behalf of the issuer based on a risk assessment from the risk-based decisioning service and on the configuration data associated with the issuer; transmitting, by the authentication server, a response message to the software application on the merchant device with an indicator of the step-up authentication to be performed on behalf of the issuer; loading, by the authentication server, web content into a user interface of a software application of a user device to enable the step-up authentication of the payment account on behalf of the issuer; receiving, by the authentication server from the user device via the user interface, a response comprising authentication data of the payment account; determining, by the authentication server based on the response, to authenticate the payment account; and transmitting, by the authentication server to the merchant device, an authentication response.
8 . The method of claim 7 , wherein the message comprises one or more of an extensible markup language (XML) message and a JavaScript Object Notation (JSON) message, and the web content comprises one or more of HyperText Markup Language (HTML) web content and XML web content.
9 . The method of claim 7 , wherein loading comprises loading web content into the user interface of the software application of the user device which enables an additional authentication step that is not available from the issuer.
10 . The method of claim 7 , further comprising, prior to loading web content into a user interface of the software application of the user device, establishing a secure channel with the user device through an application programming interface (API) of the server, and wherein the message is received from the user device via the secure channel.
11 . The method of claim 7 , wherein the transmitting the response message comprises transmitting a message to the merchant device with a flag to indicate that an authentication of the payment account is being performed on behalf of the issuer.
12 . A non-transitory computer-readable medium comprising instructions which when executed by a processor cause a computer to perform: receiving, by an authentication server, configuration data associated with an issuer of a payment account; determining, by the authentication server based on the configuration data, that use of a risk-based decisioning service has been selected for transactions associated with the issuer; receiving, by the authentication server from a merchant device, a message transmitted from a software application on the merchant device, the message comprising a request to authenticate the payment account; determining, by the authentication server, to perform a step-up authentication of the payment account on behalf of the issuer based on a risk assessment from the risk-based decisioning service and on the configuration data associated with the issuer; transmitting, by the authentication server, a response message to the software application on the merchant device with an indicator of the step-up authentication to be performed on behalf of the issuer; loading, by the authentication server, web content into a user interface of a software application of a user device to enable the step-up authentication of the payment account on behalf of the issuer; receiving, by the authentication server from the user device via the user interface, a response comprising authentication data of the payment account; determining, by the authentication server based on the response and on a risk-based decisioning service, to authenticate the payment account; and transmitting, by the authentication server to the merchant device, an authentication response.
13 . The non-transitory computer-readable medium of claim 12 , wherein the loading comprises loading web content into the user interface of the software application of the user device which enables an additional authentication step that is not available from the issuer.

Description

CROSS REFERENCE TO RELATED APPLICATION This application is a continuation of U.S. patent application Ser. No. 14/509,247 filed on Oct. 8, 2014, in the United States Patent and Trademark Office, which claims the benefit of U.S. Provisional Patent Application No. 61/913,670 filed on Dec. 9, 2013, the contents of all of which are hereby incorporated by reference for all purposes. BACKGROUND Embodiments of the present invention described herein relate to transactions for payment of goods/services and, more particularly, to the provision of authenticated transactions across multiple channels of commerce. Card issuers and other financial institutions now offer or use standardized Internet transaction protocols to improve on-line transaction performance and to accelerate the growth of electronic commerce. Under some standardized protocols card issuers or issuing banks may authenticate transactions thereby reducing the likelihood of fraud and associated chargebacks attributed to cardholder not-authorized transactions. One example of such a standardized protocol is the 3-D Secure Protocol. The presence of an authenticated transaction may result in an issuer assuming liability for fraud should it occur despite efforts to authenticate the cardholder during an online purchase. Merchants are assured by card issuers or issuing banks that they will be paid for issuer-authenticated transactions. The 3-D Secure (3DS) protocol is consistent with and underlies the authentication programs offered by card issuers (e.g., Verified by Visa or MasterCard SecureCode) to authenticate customers for merchants during remote transactions such as those associated with the Internet. The 3-D Secure Protocol leverages existing Secure Sockets layer (SSL) encryption functionality and provides enhanced security through issuer “authentication” of the cardholder during the online shopping session. A piece of software called the Merchant Plug In (MPI) is used by participating merchants to exchange messages, pass information and query participants in order to establish an authentication session between the cardholder and their card issuer during an online purchase. The 3-D Secure Protocol services are generally based on a three-domain model—the issuer domain, acquirer and interoperability domain. The issuer is responsible for managing the enrollment of cardholders in the service, and for authenticating cardholders during on-line transactions. The acquirer is responsible for defining procedures so that merchants participating in Internet transactions operate under an agreement with the acquirer, and for providing back end processing for authenticated transactions. The interoperability domain facilitates the transaction exchange between the other two domains with a common protocol and shared services. Cardholders and their banks may come under the “Issuer Domain”, merchants and their banks may come under the “Acquirer Domain”. Communication between issuing and acquiring banks or financial institutions and card issuer infrastructure may come under “Interoperability Domain”. While transacting with 3-D Secure compliant banks and merchants, a consumer may have the same Internet shopping experience as previously, except that there is a separate authentication window or i-frame element from the cardholder's bank to determine if the transacting party is indeed the cardholder of record. The transaction flow for an on-line Internet purchase transaction under the protocol may be as follows: (1) Customers fill in payment data at merchant web sites in the usual fashion, via an encrypted Secure Sockets Layer (SSL) connection.(2) The merchant then sends a message through an MPI to a directory server or system which in turn queries the card issuer to find out whether the customer is enrolled in the 3-D Secure program.(3) The card issuer responds to the directory with a message indicating whether the cardholder is enrolled and, if so, provides a Web address for the financial institution that issued the card. This message is then processed and a response forwarded to the merchant.(4) The merchant then sends a message to the issuing financial institution, through the cardholder device, to initiate an authentication session between the cardholder and the card issuer in which transaction details such as merchant name and transaction amount may also be presented to the cardholder for confirmation.(5) The issuing financial institution will then populate an authentication window to the cardholder detailing information related to the transaction such as merchant name and amount, a personal security message, and a response area where authentication details can be entered by the cardholder.(6) The customer approves the transaction in one of a variety of ways, depending on how the issuing financial institution chooses to implement the system. Options may range from entering a static password or PIN to utilizing a smart card and a Personal Card Reader (PCR) to generate an authe