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) – commonly known by its branded names: Visa Secure, Mastercard Identity Check, American Express SafeKey, and Diners Club ProtectBuy – requires customers to complete an extra authentication step with their card issuer when making a payment. Typically, you direct the customer to their bank’s website where they enter a password or a code sent to their phone to verify the payment. It uses a wider range of data and risk assessment metrics to allow for "frictionless authentication", meaning a smoother, more secure payment flow for both you and your customers. If you do business in Europe, it's the best way to comply with the new Strong Customer Authentication (SCA) requirements introduced by the revised Payment Services Directive (PSD2).
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
The following liability shift rules apply to:
- American Express
- Diners Club International (DCI)
- Discover
- JCB
- Visa
| Transaction type | Electronic Commerce Indicator | 3D Secure version | Liability shift |
|---|---|---|---|
3DS authentication was successful; transaction secured by 3DS. | 05 | 3DS 2.2.0 and 2.3.1 | Yes |
3DS authentication was processed by a stand-in service, and is classed as successful. | 06 | 3DS 2.2 and 2.3 | Yes |
3DS authentication was processed successfully using an SCA exemption, failed, or could not be attempted. | 07 | 3DS 2.2.0 and 2.3.1 | No |
| Transaction type | Electronic Commerce Indicator | 3D Secure version | Liability shift |
|---|---|---|---|
3DS authentication either failed or could not be attempted. | 00 | 3DS 2.2.0 and 2.3.1 | No |
3DS authentication was processed by a stand-in service, and is classed as successful. | 01 | 3DS 2.2.0 and 2.3.1 | Yes |
3DS authentication was successful; transaction secured by 3DS. | 02 | 3DS 2.2.0 and 2.3.1 | Yes |
Frictionless authentication via the Mastercard Identity Check Data Only service. | 04 | 3DS 2.2.0 and 2.3.1 | No |
Transaction is out of scope or exempt from Strong Customer Authentication. | 06 | 3DS 2.2.0 and 2.3.1 | No |
3DS authentication was successful; recurring transaction secured by 3DS. | 07 | 3DS 2.2.0 and 2.3.1 | Yes Transactions processed through Apple Pay without a cryptogram do not benefit from liability shift. |
See the Apple Pay and Google Pay documentation for more information on how liability shift applies to each digital wallet.
You can request 3D Secure payments by using our Unified Payments API, or the Standalone (Sessions) API – our standalone solution that uses the EMV 3D Secure (3DS) protocol.