3D Secure
3D Secure (3DS) is a security protocol that requires customers to complete an additional authentication step when attempting online card payments. Authenticating your customers' payments with 3DS helps reduce fraud and meet regulatory requirements.
3D refers to the three domains involved in the authentication process:
- The card issuer
- The merchant
- The infrastructure that mediates between the customer and the merchant
In Europe, 3DS is required to comply with the Strong Customer Authentication (SCA) regulation for all card payments.
In other regions, 3DS is optional.
Information
Checkout.com supports up to and including version 2.2.0 of the 3DS protocol.
Many major card schemes provide their own 3DS solutions. For example:
- American Express SafeKey
- Diners Club ProtectBuy
- Mastercard Identity Check
- Visa Secure
In a 3DS authentication journey, you redirect the customer to their bank’s website to verify the payment with a password or a code sent to their phone. You can also embed the authentication process in your checkout.
When a customer makes a payment, the merchant and payment service provider can use 3DS to send data to the card issuer. For example, the customer's shipping address, device ID, or payment history.
The issuer can then use this data to assess the transaction's risk level and take one of the following actions:
- Immediately authenticate the payment using a frictionless flow.
- Request further information before authenticating the payment using a challenge flow.
The data and risk assessment metrics provided by 3DS help you provide a secure, frictionless authentication experience to your customers.
The 3DS frictionless flow is as follows:
- The cardholder initiates a transaction and the 3DS data is sent to the 3DS Server.
- The 3DS Server sends the Authentication Request (AReq) to the payment network, and then on to the issuer.
- If the issuer has sufficient data to confirm the transaction is legitimate and was initiated by the cardholder, they continue with a frictionless flow.
- The issuer returns their decision to the payment network within the Authentication Response (ARes), and then on to the 3DS Server.
- The 3DS Server sends the decision back to the browser or SDK from where the transaction was initiated and complete the payment.
The 3DS challenge flow is as follows:
- The cardholder initiates a transaction and the 3DS data is sent to the 3DS Server.
- The 3DS Server sends the AReq to the payment network, and then on to the issuer.
- If the issuer has insufficient data to confirm the transaction is legitimate and was initiated by the cardholder, they continue with a challenge flow.
- The issuer returns their decision to the payment network within the ARes, and then on to the 3DS Server.
- The 3DS Server sends the decision back to the browser or SDK from where the transaction was initiated.
- The browser or SDK can then send a Challenge Request (CReq) to the issuer. This prompts the issuer to present a 3DS challenge screen to the cardholder.
- The issuer sends the result of the challenge to the browser or SDK within the Challenge Response (CRes). The CRes can also be used to indicate to the origin app that further cardholder interaction is required.
- When the challenge is successfully completed, the issuer sends the result to the payment network in the Result Request (RReq), and then on to the 3DS Server.
- The 3DS Server acknowledges that it received the RReq by sending a Result Response (RRes) to the payment network, and then on to the issuer.
Liability shift is when the liability for fraud-related chargebacks for card payments (for example, if your customer denies making a purchase) shifts from you to the card issuer.
As a general rule, the shift occurs when a payment is successfully authenticated with 3DS.
In specific scenarios, liability shift occurs as follows:
| Scenario | More information |
|---|---|
If the card is enrolled for 3DS and authentication is successful, liability shifts from you to the issuer, and you can authorize the payment. | |
If the card supports 3DS but authentication could not be attempted for technical reasons (for example, there was a network error, or the customer closed the window during authentication), liability remains with you, but you can decide whether or not to authorize the transaction. | |
If authentication fails because the cardholder does not pass the challenge, liability remains with you and you should not proceed with the payment. | |
If you request and apply an exemption, you can proceed to authorize the payment but liability remains with you. | |
If you specify the This applies even if you receive ECI value 05 (non-Mastercard) / 02. | |
Mastercard has additional rules specific to 3DS versions 2.2.0 and 2.3.1. | |
If you request a non-payment authentication with Mastercard, the transaction does not go to authorization and liability does not shift. |
You can apply 3D Secure to payment requests using the Payments API, and the Standalone (Sessions) API, which follows the EMV 3DS protocol.