# 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 --- ## 3D Secure applicability In Europe, 3DS is required to comply with the [Strong Customer Authentication (SCA) regulation](https://www.checkout.com/docs/business-operations/ensure-regulatory-compliance/sca-compliance.md) 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. --- ## How it works 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](#Frictionless_flow). - Request further information before authenticating the payment using a [challenge flow](#Challenge_flow). The data and risk assessment metrics provided by 3DS help you provide a secure, frictionless authentication experience to your customers. ### Frictionless flow The 3DS frictionless flow is as follows: 1. The cardholder initiates a transaction and the 3DS data is sent to the 3DS Server. 2. The 3DS Server sends the Authentication Request (AReq) to the payment network, and then on to the issuer. 3. If the issuer has sufficient data to confirm the transaction is legitimate and was initiated by the cardholder, they continue with a frictionless flow. 4. The issuer returns their decision to the payment network within the Authentication Response (ARes), and then on to the 3DS Server. 5. The 3DS Server sends the decision back to the browser or SDK from where the transaction was initiated and complete the payment. ### Challenge flow The 3DS challenge flow is as follows: 1. The cardholder initiates a transaction and the 3DS data is sent to the 3DS Server. 2. The 3DS Server sends the AReq to the payment network, and then on to the issuer. 3. If the issuer has insufficient data to confirm the transaction is legitimate and was initiated by the cardholder, they continue with a challenge flow. 4. The issuer returns their decision to the payment network within the ARes, and then on to the 3DS Server. 5. The 3DS Server sends the decision back to the browser or SDK from where the transaction was initiated. 6. 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. 7. 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. 8. 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. 9. 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 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 | Electronic Commerce Indicator (ECI) value | | --- | --- | | If the card is enrolled for 3DS and authentication is successful, liability shifts from you to the issuer, and you can authorize the payment. | - [Mastercard 02](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift)
- [Non-Mastercard 05](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Non-Mastercard_liability_shift) | | 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. | - [Mastercard 00](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift)
- [Non-Mastercard 07](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Non-Mastercard_liability_shift) | | If authentication fails because the cardholder does not pass the challenge, liability remains with you and you should not proceed with the payment. | - [Mastercard 00](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift)
- [Non-Mastercard 07](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Non-Mastercard_liability_shift) | | If you request and apply an exemption, you can proceed to authorize the payment but liability remains with you. | - [Mastercard 06](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift)
- [Non-Mastercard 07](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Non-Mastercard_liability_shift) | | If you specify the `no_challenge_requested` challenge indicator in your authentication request and it's applied with Cartes Bancaires, you can proceed to authorize the payment but liability remains with you.

This applies even if you receive Non-Mastercard value 05 or Mastercard 02. | - [Mastercard 02](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift)
- [Non-Mastercard 05](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Non-Mastercard_liability_shift) | | Mastercard has additional rules specific to 3DS versions 2.2.0 and 2.3.1. | [Mastercard 04, 06, and 07](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift) | | If you request a non-payment authentication with Mastercard, the transaction does not go to authorization and liability does not shift. | [Mastercard N0/N2](https://www.checkout.com/docs/developer-resources/codes/eci-values.md#Mastercard_liability_shift) | --- ## 3D Secure with Checkout.com You can apply 3D Secure to payment requests using the [Payments API](https://www.checkout.com/docs/payments/authenticate-payments.md#Authenticate_payments_using_our_integrated_authentication), and the [Standalone (Sessions) API](https://www.checkout.com/docs/risk-management/3d-secure/sessions.md), which follows the Europay, Mastercard, Visa (EMV) 3DS protocol. --- ## Related topics - [Standalone (Sessions)](https://www.checkout.com/docs/payments/authenticate-payments/3d-secure/standalone-sessions.md): Learn more about our standalone authentication solution. - [Diagnose authentication failures](https://www.checkout.com/docs/payments/authenticate-payments/3d-secure/diagnose-authentication-failures.md): Learn more about common authentication failures you may encounter. - [Improve authentication performance](https://www.checkout.com/docs/payments/authenticate-payments/3d-secure/improve-authentication-performance.md): Improve your authentication performance by including optional fields to enhance risk analysis. - [Request 3RI authentication](https://www.checkout.com/docs/payments/authenticate-payments/3d-secure/request-3ri-authentication.md): Learn how to submit authentication data for transactions in which the cardholder is not present.