3D Secure version 2 (3DS2) is the enhanced version of the 3D Secure online payment authentication. As opposed to 3DS version 1, where only challenge flows were supported, 3DS version 2 introduces frictionless, risk-based  decisions and supports seamless background verification or step-up prompts (via an app, push notification, or biometrics). It collects more data (device, location, behavior) to reduce unnecessary prompts, improves mobile UX, and aims to maintain strong customer authentication (SCA) while preserving conversion.

Key benefits of 3D Secure 2

• Better user experience: frictionless/step-up flows reduce checkout friction, especially on mobile.
• Higher approval rates: risk-based decisions keep more legitimate transactions intact.
• More data for risk assessment: device, location, behavior, and merchant data improve decisions.
• Fewer redirects: in-app or seamless authentication keeps users in flow.
• Stronger security with SCA alignment: supports two-factor-like authentication without heavy disruption.
• Broad device support: works well with mobile wallets and newer devices.
• Flexible exemptions: supports exemptions for low-value, low-risk or recurring payments in the EEA region. 

Supported 3D Secure version 2 flows

On our platform, we support multiple scenarios of performing 3D Secure 2, responding to the payment context and conditions. 

• Frictionless without Method URL - Frictionless authentication occurs entirely in the background; no user-facing redirect or URL routing.
• Frictionless with Method URL - Frictionless authentication still happens in the background, but a Method URL is used to establish or maintain the authentication context (often for risk signaling or to align with certain issuer networks). The user experience stays seamless, but the flow uses a URL-based handoff behind the scenes.
• Challenge without Method URL - An explicit user-facing challenge is presented without relying on a Method URL handoff (e.g., a visible in-flow prompt via an app or browser).
• Challenge with Method URL - The explicit challenge is delivered with a Method URL handoff involved (URL routing to the issuer’s authenticator, then back to the merchant).

You can find the flow diagrams, test card data, and API examples for these 3D Secure 2 flows in the Test cases section in additional information.

Liability Shift

If both the cardholder and the merchant are participating in the 3D Secure scheme and the transaction has been successfully authenticated, the liability of a chargeback shifts from the merchant to the cardholder's issuing bank. Please note that the liability shift only applies for chargebacks based on a fraud reason code. Any reason codes related to other types disputes are not covered by the liability shift.

Key Benefits

• Enhance trust and confidence for your consumer's online shopping experience
• Additional layer of protection against fraud
• Especially valuable for high transaction amounts

In case of a fraud chargeback reason code, the liability shifts to the card issuing bank if the obtained authentication values were used during the authorization and settlement.

Supported Card Types

Process Flows

1. Consumer places an order.
2. You pass the card details to us.
3. We send authentication request to card scheme (Verified by Visa, MasterCard SecureCode, Discover/Diners ProtectBuy, or Amex SafeKey).
4. Card scheme returns authentication result to us.
5. We send authorization request to the acquiring bank.
6. Acquiring bank sends authorization request to issuing bank.
7. Issuing bank returns authorization result to acquiring bank.
8. Acquiring bank returns authorization result to us.
9. We return authorization result to you.
10. We send settlement request to the acquiring bank.
11. Acquiring bank sends settlement request to issuing bank.
12. Issuing bank sends settlement funds to acquiring bank.
13. Acquiring bank sends settlement funds to us.
14. We send reporting and funds to you.

ECI & CAVV

The authentication values provided by the issuer are exchanged in the authorization and settlement messages. It consists of the following elements:

• Electronic Commerce Indicator (ECI): This indicator shows the value of the result of the authentication.
• Cardholder Authentication Verification Value (CAVV): This value is the end-to-end reference generated by the issuer to recognize that the authentication has taken place.

Please be advised that there are scenarios where a Liability Shift applies, even if the transaction was only partially authenticated. An example of such a scenario is you are participating in the authentication, but the cardholder is not participating. Please find more information about these scenarios in below tables.

Additional Information

Liability Shift Protection

Depending on where the card is issued and the level of authentication, liability shift may or may not be applicable. Below tables will help you to determine whether your liability shift is applicable.

Liability Shift: Visa

Liability Shift and COF Transactions

Liability Shift: Mastercard / Maestro

Liability Shift: Amex

Liability Shift: Diners & Discover

Liability shift applies in the following scenarios:

• The Issuer, Merchant/Acquirer, and Card Member are enrolled in ProtectBuy and the authentication response is either Full Authentication or Attempts Authentication.
• Only the Issuer and Merchant/Acquirer are enrolled in ProtectBuy and the Card Member is not participating. This includes when a Card Member opts-out of Activation During Shopping (ADS) or ADS is not offered. Liability shift occurs when the authentication response is Attempts Authentication.
• The Issuer and Merchant/Acquirer are both participating but the Issuer's Access Control Server (ACS) is unreachable, requiring the DCI Attempts ACS to perform stand-in authentication, and the authentication response is Attempts Authentication. This may occur whether or not the Card Member is enrolled.

Chargeback Reason Codes

Visa

Mastercard

Maestro

Diners

Additional information

1. Introduction
2. Highlevel implementation
3. Consumer user experience
4. MyCheckout hosted payment pages implementation
5. Create Payment API implementation
6. Test cases
7. Special use cases
8. Webhooks