3D Secure
Authenticate your customers' payments with 3D Secure to reduce fraud and meet regulatory requirements.
Information
We currently support versions up to, and including, 2.2.0 of the 3D Secure protocol.
3D Secure (3DS) is a security protocol that requires customers to complete an additional authentication step when attempting an online card payment. The 3D refers to the three domains involved in the authentication process:
- The card issuer
- The merchant
- The infrastructure that mediates between the consumer and the merchant
In Europe, 3DS is required to comply with the Strong Customer Authentication (SCA) regulation for all card payments.
Information
In other regions, 3DS authentication is optional.
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 flow, you redirect the customer to their bank’s website where they can verify the payment with a password or a code sent to their phone. The data and risk assessment metrics provided by 3DS allow you to provide a secure frictionless authentication experience to your customers.
With 3DS you can embed the authentication process in your checkout flow to provide a seamless user experience.
When a customer makes a payment, the merchant and payment service provider can use 3DS to send data to the cardholder's 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 either:
- Immediately authenticate the payment using a frictionless flow.
- Request further information before authenticating the payment using a challenge flow.
- In a frictionless flow, 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 determines that there is sufficient data to confirm that the transaction is legitimate and was initiated by the cardholder, they will continue with a frictionless flow.
- The issuer will return their decision to the payment network within the Authentication Response (ARes), and then on to the 3DS Server.
- The 3DS Server will send the decision back to the browser or SDK from where the transaction was initiated and complete the payment.
- In a challenge flow, 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 determines that there is insufficient data to confirm that the transaction is legitimate and was initiated by the cardholder, they will continue with a challenge flow.
- The issuer will return their decision to the payment network within the ARes, and then on to the 3DS Server.
- The 3DS Server will send 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 will prompt 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 of the challenge to the payment network within 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.
This is when the liability for fraud-related chargebacks (for instance, your customer denies they made the purchase, suspecting someone has stolen their card details) shifts from you to the card issuer.
As a general rule, the shift occurs when a payment is successfully authenticated with 3DS.
Specifically:
- If the card is enrolled for 3DS and authentication is successful, the liability shifts from you to the issuer, and you can authorize the payment – see Electronic Commerce Indicator (ECI) values 05 / 02.
- 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 verification), liability remains with you, but you can decide whether or not to authorize the transaction – see ECI 07 (non-Mastercard) / 00.
- If authentication fails because the cardholder does not pass the challenge, liability remains with you and you should not proceed with the payment – see ECI 07 (non-Mastercard) / 00.
- If you request and apply an exemption, you can proceed to authorize the payment but liability will remain with you – see ECI 07 (non-Mastercard) / 06.
- If you specify the
no_challenge_requestedchallenge indicator in your authentication request and it's applied with Cartes Bancaires, you can proceed to authorize the payment but liability will remain with you – this applies even if you receive ECI value 05 (non-Mastercard) / 02. - Mastercard has additional rules specific to 3DS 2.2.0 and 2.3.1 – see Mastercard ECIs 04, 06, and 07.
- If you request a non-payment authentication with Mastercard, the transaction does not go to authorization and liability does not shift – see ECI N0/N2.
You can request 3D Secure payments using the Payments API, or the Standalone (Sessions) API – our standalone solution that uses the EMV 3D Secure (3DS) protocol.