3-D Secure (3DS) Overview

Introduction

3DS is an authentication process that merchants can use to verify that a cardholder is who they say they are prior to sending a purchase authorization. If a merchant successfully runs 3DS on one of your cards, liability shifts to you as the issuer, and you forfeit the ability to dispute a transaction for fraud. Read this guide to learn how Lithic enables you to manage that liability shift and better manage fraud on your card program.

How 3DS Works

3-D Secure is an authentication protocol that provides an additional layer of security for e-commerce transactions. The protocol consists of three domains:

• The acquirer domain (”3DS Server”) — the acquirer's system that the merchant uses to initiate the 3DS authentication flow.
• The interoperability domain (”Directory Server”) — the network's system that facilitates the movement of 3DS-related information between the acquirer and issuer domains.
• The issuer domain (”Access Control Server”) — the issuer and its cardholders' systems that respond to the 3DS authentication request.

The 3DS authentication process is initiated by the merchant/acquirer and is intended to verify that the person making an e-commerce transaction is the cardholder who is authorized to spend on the card. The acquirer passes standardized information to the issuer, who responds with one of several possible outcomes, including authenticating the cardholder, declining to authenticate the cardholder, or requiring further interaction with the cardholder before authentication can be completed. As the entire 3DS authentication is run before the purchase authorization is sent to the issuer for approval, it enables merchants to minimize fraud by ensuring that the cardholder is who they say they are before they run the authorization.

When a 3DS authentication takes place, an “authentication value” is provided in the subsequent authorization, allowing the issuer to tie the two events together.

How 3DS Impacts Your Cards

In the US, the use of the 3DS protocol to authenticate a cardholder’s identity is up to the merchant, and how often 3DS will take place on your cards can vary depending on if your program’s spend is concentrated on merchants who have adopted 3DS. In certain jurisdictions such as the European Union where banks and other payment service providers are required to meet Strong Customer Authentication (SCA) requirements, 3DS authentication takes place on nearly all online transactions.

When a merchant initiates a 3DS authentication, the issuer is required to respond in some form and cannot opt out of participation. Since 3DS authentications can result in liability shifting from the merchant to the issuer for a given transaction, card programs should ensure they are accounting for these outcomes when they approve or decline the authorization that follows.

To better understand why this is important, consider a standard e-commerce transaction where 3DS authentication does not take place. In this scenario, issuers have the ability to file a dispute for fraud if the card was used by an unauthorized individual. However, if a 3DS authentication does take place and the issuer authenticates the cardholder, then liability shifts to the issuer, and they do not have the ability to file a dispute for fraud.

Options for Participating in 3DS

Note: Lithic currently only offers 3DS for Mastercard.

When a merchant initiates a 3DS authentication on one of your cards, Lithic provides two options for handling the response:

• Lithic Decisioning: When Lithic receives a 3DS authentication on one of your cards, it runs a set of risk-based rules, and responds to the 3DS authentication on your behalf. No real-time response is required from you in order to respond to these authentication requests
• Customer Decisioning: When Lithic receives a 3DS authentication on one of your cards, a request is sent to your endpoint containing critical data elements provided in the authentication request. You have 1 second to respond with your decision of whether or not to approve the authentication, and that response is sent back to the merchant/acquirer

See the 3DS Decisioning page for more detail on the above two options. Lithic currently supports “frictionless” flows only, meaning each 3DS authentication results in an approved or failed outcome, and no cardholder interaction takes place.

In either option, you can subscribe to listen for three_ds_authentication.created event types via the Events API to receive webhooks in real-time indicating that an authentication has taken place on your card program.

Since the 3DS authentication process runs before authorizations, you can take advantage of the data contained in these webhooks to improve your authorization decisioning logic. During an authorization, the cardholder_authentication object in the ASA request indicates whether 3DS has taken place. If the liability_shift is 3DS_AUTHENTICATED, then liability shift has applied and you should incorporate this information into your authorization decisioning. Even if 3DS authentication takes place and liability has shifted, you still have the ability to decline the authorization via ASA to protect your card program in the case of suspected fraud.

Implementation Steps

• BIN configuration update
  • The card network routes messages between the acquirer domain to Lithic during a 3DS authentication. Your Implementation Manager (for implementing programs) or our Support Team (for live programs) will work with you to ensure that the correct network configuration is set up so that it knows to route your card program’s 3DS authentications to Lithic
• (Customer Decisioning only) Set up and test your 3DS decisioning responder
  • If you are participating in the real-time decisioning flow, you will need to set up and test your responder to ensure you are ready to ingest the three_ds_authentication request and respond appropriately. This can be done through a dedicated set of endpoints here and we encourage you to test the flow in Sandbox before attempting to respond to requests in Production
• Subscribe to 3DS authentication events via the Events API
  • To ensure you are finding out about authentications taking place on your cards in real-time, you can subscribe to the three_ds_authentication.created event type via the Events API

3DS and Authorization Decisioning

To get the most out of 3DS, we strongly recommend that card programs incorporate the outcome of 3DS authentications into their authorization decisioning.

When a 3DS authentication takes place before an authorization, the cardholder_authentication object in the ASA request contains data indicating the outcome of the 3DS authentication. Refer to this documentation for the latest. A few key fields to note:

• liability_shift: Indicates whether chargeback liability shift to the issuer applies to the transaction; in other words, whether the issuer forfeits the ability to dispute the transaction for fraud if it approves the authorization
• authentication_result: Indicates what the outcome of the 3DS authentication process is
• decision_made_by: Indicates which party made the 3DS authentication decision
• three_ds_authentication_token: Unique identifier you can use to match a given 3DS authentication (available via the three_ds_authentication.created event webhook) and the subsequent authorization