3D Secure is a protocol that adds identity verification to online card payments. When enabled, the cardholder’s bank confirms their identity before the transaction completes, rather than relying solely on card number, expiry, and CVV.
The “3D” refers to three domains involved in every authenticated transaction: the acquirer domain (your payment processor), the issuer domain (the cardholder’s bank), and the interoperability domain (the card network infrastructure connecting them). EMVCo maintains the protocol specification, currently at version 2.3.1.
For card-not-present transactions, 3D Secure authentication is the primary defense against unauthorized card use. Visa reports that CNP fraud runs 7.5x higher than card-present fraud, accounting for nearly 89% of all payment fraud (Visa). Authentication closes that gap by confirming the person making the purchase actually holds the card.
Key takeaways:
- 3DS2 routes 85-95% of transactions through frictionless authentication with no customer challenge
- Visa reports 45% fraud reduction and 9% authorization uplift on authenticated transactions
- Regional conversion impact varies wildly: India sees +30%, Brazil sees -55% when 3DS is applied universally. Selective, risk-based application eliminates the negative impact.
- SCA exemptions (TRA, low-value, recurring, whitelisting) are how you avoid adding friction to every purchase in regulated markets
3D Secure 1.0 vs 2.0
3DS1 worked, but badly. It redirected every cardholder to their bank’s authentication page, which was often a poorly designed external site in a separate browser window. The experience confused customers, and checkout conversion dropped 3-15% as a result (Justt). Both Visa and Mastercard ended 3DS1 support in late 2021 and 2022 respectively.
3DS2 fixes the core problem by introducing risk-based authentication. Instead of challenging every transaction, the issuer receives rich transaction data (device fingerprint, transaction history, shipping address) and decides whether to authenticate silently or present a challenge. Mastercard estimates that 90% of 3DS2 transactions require no customer interaction at all (Chargeflow, citing Mastercard).
The practical differences:
| 3DS1 | 3DS2 | |
|---|---|---|
| Authentication | Full-page redirect to bank site | In-app overlay or silent (frictionless) |
| Data shared with issuer | Minimal | 10x more data fields for risk scoring |
| Mobile experience | Poor (designed for desktop browsers) | Native mobile SDK support |
| Conversion impact | 3-15% drop | Under 5%, often neutral or positive |
| Card network support | Sunset (2021-2022) | Current standard (EMV 3DS 2.3.1) |
Both Visa and Mastercard deprecated 3DS 2.1.0 in 2024, requiring migration to 3DS 2.2.0 or later. If your PSP still sends 2.1 messages, check their upgrade timeline.
How 3D Secure authentication works
The authentication flow sits between card details capture and payment authorization. When your payment gateway sends a 3DS request, the following sequence executes:
- Your server (or your PSP) submits the payment with 3DS data to the card network’s Directory Server.
- The Directory Server routes the request to the issuer’s Access Control Server (ACS).
- The ACS evaluates transaction risk using the data provided.
- If low risk: the ACS returns a frictionless authentication result. The cardholder sees nothing.
- If elevated risk: the ACS returns a challenge. The cardholder verifies via their bank app, SMS OTP, or biometrics.
- The authentication result (success, failure, or attempted) flows back through the Directory Server to your PSP.
- Your PSP includes the authentication result in the authorization request to the issuer.
Most cardholders never see step 5. Issuers typically route 85-95% of 3DS2 transactions through the frictionless path (2Accept). When a challenge does occur, the authentication method varies by issuer and region. In the UK, over 75% of challenges are handled through bank apps, where the cardholder approves a push notification (Stripe). Other common challenge methods include SMS one-time passwords, biometric verification through the banking app, and in-app PIN entry. The method is determined by the issuer, not by you or your PSP.
The authentication outcome also determines liability. When 3DS authentication succeeds, fraud liability shifts from you to the card issuer. If a transaction that passed 3DS is later disputed as unauthorized, the issuer absorbs the chargeback. This shift only applies to fraud-related chargebacks. Product disputes and service complaints remain your responsibility.
When 3D Secure triggers
Three factors determine whether a transaction goes through 3DS: regulation, issuer risk policy, and your own configuration.
Regulation is the non-negotiable layer. Multiple jurisdictions now mandate authentication for online card payments:
| Region | Regulation | What it requires |
|---|---|---|
| European Union | PSD2 / SCA | Two-factor authentication for electronic payments in the EEA |
| United Kingdom | FCA SCA rules | Same SCA requirements, post-Brexit adaptation of PSD2 |
| India | RBI AFA | Additional Factor Authentication for online card payments. Expanding to all digital payments from April 2026 |
| Japan | SCA guidelines | 3DS2 mandatory on all card transactions since April 2025 |
| Brazil | BCB 2FA | Mandatory two-factor authentication for Pix and digital payments |
Warning: India’s RBI currently mandates AFA for domestic online card transactions, but from April 2026, two-factor authentication becomes mandatory for all digital payment types (Business Standard). If you process payments in India, your authentication infrastructure needs to be ready before that deadline.
Where regulation doesn’t mandate 3DS, issuers still trigger it based on risk signals: transaction amount, cardholder location, device fingerprint, merchant category, and historical fraud patterns. A $5 purchase from a known device typically passes frictionless. A $2,000 purchase from a new device in a different country probably gets challenged.
You can also request 3DS proactively. Some merchants run 3DS on every transaction above a certain threshold as an additional fraud prevention layer, trading a small amount of friction for liability protection.
SCA exemptions and frictionless flow
PSD2 mandates authentication, but it also provides exemptions for lower-risk transactions. Using exemptions correctly is what separates a good 3DS implementation from one that adds friction to every purchase.
| Exemption | Condition | Limit |
|---|---|---|
| Low-value payments | Transaction under €30 | Max 5 consecutive or €100 cumulative |
| Transaction Risk Analysis | Acquirer and issuer fraud rates below thresholds | Under 13 bps fraud rate → exemptions up to €500 |
| Recurring payments | Same amount, same merchant, after initial SCA | All subsequent charges exempt |
| Merchant whitelisting | Cardholder adds merchant to issuer’s allowlist | Issuer can override if risk signals change |
The frictionless flow is the mechanism that makes exemptions work in practice. When you or your acquirer request an exemption, the 3DS2 protocol routes the transaction through the frictionless path. The issuer evaluates the request and, if accepted, authenticates silently in the background. The cardholder never leaves your checkout page.
UK issuers accept exemption requests at a rate 10 percentage points higher than their EEA counterparts (Stripe), which is one reason UK conversion rates with 3DS tend to run higher.
The conversion impact
3DS authentication has a measurable effect on conversion, and the direction depends entirely on how you implement it.
Applying 3DS to every transaction produces wildly different results by region:
| Region | Impact with universal 3DS | Issuer readiness |
|---|---|---|
| India | +30% conversion uplift | Mature 3DS2, high frictionless rates |
| UK | +2.5% conversion uplift | Mature, 75%+ challenges via bank app |
| US | -43% conversion drop | Low 3DS2 adoption, high challenge rates |
| Brazil | -55% conversion drop | Low frictionless rates |
Source: Adyen. Selective application by risk and value eliminates negative impact even in underperforming markets.
The selective approach performs better. Stripe reports that across SCA-regulated markets, their optimized 3DS implementation produces a 1.20% conversion uplift while reducing fraud by 7.67% overall and by over 30% on eligible transactions (Stripe).
Japan’s 3DS2 mandate, which took effect in April 2025, provides the clearest recent case study. Post-mandate, 60% of transactions route through the frictionless path with a 93% conversion rate, and dispute rates dropped more than 30% compared to the same period the prior year (Stripe).
Visa’s own data shows a 9% lift in authorization approval rates for transactions authenticated through Visa Secure, and a 45% reduction in fraud on authenticated versus non-authenticated eCommerce transactions (Visa).
The fraud reduction compounds across protocol versions. Without 3DS, fraud rates sit around 0.29%. 3DS1 reduced that to roughly 0.12%. 3DS2 targets approximately 0.05%, driven by the combination of better risk data and frictionless authentication that encourages broader adoption (Justt).
The takeaway for implementation: don’t blanket-apply 3DS to everything. Use exemptions where you qualify, apply 3DS selectively based on risk and regulation, and track your frictionless rate by issuer country to identify where conversion drag is coming from. If you’re seeing high challenge rates in a specific market, the problem is likely data quality in the 3DS request rather than the protocol itself. Richer device and transaction data gives issuers more confidence to approve frictionless.
Implementing 3D Secure with Orchestra
When you process payments through multiple PSPs, 3DS becomes a consistency problem. Each processor handles authentication differently: different API contracts for initiating 3DS, different webhook formats for receiving results, different behaviors when the issuer requests a challenge. If you’re integrated directly with three PSPs, you’re maintaining three separate 3DS implementations.
Orchestra’s library handles 3DS as part of the payment flow regardless of which PSP processes the transaction. When authentication is required, the library renders the challenge as an in-page overlay. The cardholder stays on your checkout page, with no redirects, no pop-ups, and no loss of session context.
For API integrations, Orchestra manages the 3DS handshake and returns structured authentication results with the redirects and status updates your application needs to handle the customer experience.
This matters for two reasons. First, consistent 3DS behavior across all your PSPs means your conversion metrics aren’t skewed by one processor’s worse authentication UX. Second, you don’t write or maintain 3DS code per provider. When Visa updates its 3DS data requirements, Orchestra handles the update across all connected processors.
We’ve seen teams build separate 3DS integrations for each PSP, each with its own quirks around challenge rendering and result handling. That’s engineering time spent on authentication plumbing rather than your core product. If that sounds familiar, outsourcing that compliance burden is worth evaluating.
Frequently asked questions
What is the difference between 3D Secure 1.0 and 2.0?
3DS1 redirected cardholders to a separate bank-hosted page for every transaction, causing 3-15% conversion drops. 3DS2 uses risk-based authentication, where the issuer receives detailed transaction data and decides whether to authenticate silently (frictionless) or present a challenge. Mastercard estimates 90% of 3DS2 transactions proceed without any customer interaction. Both Visa and Mastercard sunset 3DS1 in 2021-2022.
Does 3D Secure reduce chargebacks?
Successful 3DS authentication triggers a liability shift: fraud-related chargebacks become the card issuer’s responsibility rather than yours. Visa reports a 45% fraud reduction on authenticated transactions compared to non-authenticated eCommerce. The liability shift only covers fraud chargebacks. Product disputes and service complaints stay with the merchant.
Which countries require 3D Secure?
The EU mandates it under PSD2’s Strong Customer Authentication rules. The UK requires it under FCA regulations. India’s RBI mandates Additional Factor Authentication, expanding to all digital payment types from April 2026. Japan mandated 3DS2 for all card transactions from April 2025. Brazil requires 2FA for Pix and digital payments. Even in markets without legal mandates, like the US, issuers frequently trigger 3DS based on their own risk assessment.
Does 3D Secure increase checkout abandonment?
It depends on the version and implementation. 3DS1 caused 3-15% conversion drops due to full-page redirects. 3DS2 limits this to roughly 5% at most, and often produces neutral or positive conversion effects. Stripe reports a 1.20% conversion uplift in SCA-regulated markets using optimized 3DS (Stripe). The key factor is frictionless authentication rate: when 85-95% of transactions authenticate silently, the remaining challenges don’t materially drag conversion.
What are SCA exemptions?
PSD2 allows merchants and acquirers to request exemptions from Strong Customer Authentication for specific transaction types: low-value payments under €30 (with cumulative limits), transactions passing Transaction Risk Analysis thresholds, recurring payments after initial authentication, and merchant-whitelisted transactions. Exemptions route through the 3DS2 frictionless flow, authenticating silently without customer interaction.
