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
What 3D Secure authentication does
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.
3DS1 vs 3DS2: what changed and what still breaks
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.
What still breaks with 3DS2. The protocol is better, not perfect. Three problems persist:
First, deprecated version handling. Some PSPs still default to 3DS 2.1.0 message formats even though the networks deprecated them in 2024. Transactions sent with 2.1 messages may receive degraded issuer responses or trigger unnecessary challenges. If your frictionless rate dropped after the deprecation window, your PSP’s version support is the first thing to check.
Second, data quality variance. 3DS2’s risk-based authentication depends on the data your PSP sends to the issuer. The protocol supports over 100 optional data fields, but not every PSP populates them all. A PSP that sends minimal device data gets worse frictionless rates than one that sends full browser fingerprints, screen resolution, timezone, and language. The issuer’s risk model is only as good as the data it receives. Two different PSPs processing the same transaction can get different authentication outcomes because they send different data.
Third, issuer-side inconsistency. Each issuing bank runs its own Access Control Server (ACS) with its own risk thresholds. A transaction that authenticates frictionlessly with one issuer might trigger a challenge with another, even with identical data. This is outside your control, but it means frictionless rates vary by issuer and by country.
The authentication flow and liability shift
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.
Regional conversion impact: the data that matters
3DS authentication has a measurable effect on conversion, and the direction depends entirely on how you implement it and where your customers are.
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.
SCA exemptions and when to use them
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.
When to request exemptions: Use TRA exemptions for returning customers with clean transaction histories. Use low-value exemptions for microtransactions and in-app purchases where authentication friction is disproportionate to the transaction value. Use recurring exemptions for subscriptions after the initial authenticated setup. Don’t request exemptions on high-value first-time purchases from new customers. The liability shift from successful 3DS authentication is more valuable than avoiding the authentication step.
When the issuer overrides your exemption request: The issuer always has final say. If they determine the transaction is high-risk, they can reject the exemption and force a challenge, regardless of what you requested. This is normal and happens more frequently for new card-on-file setups and cross-border transactions.
Why frictionless rates vary and how to improve them
If your 3DS frictionless rate is below 80%, you’re losing conversions to unnecessary challenges. The frictionless rate is the single most important metric for 3DS performance, and it varies widely based on factors you can control.
Data quality is the biggest lever. The 3DS2 protocol supports over 100 optional data fields that help the issuer’s risk model. The more data you send, the more confident the issuer is in authenticating frictionlessly. Fields that have the highest impact on frictionless rates:
- Browser and device data (user agent, screen height/width, color depth, timezone, language)
- Customer account age and transaction history with your business
- Shipping address match with billing address
- Email address and phone number
- Previous authentication outcomes
If your PSP sends minimal data fields, your frictionless rate will suffer regardless of how low-risk your customer base is. Check with your PSP what data they include in 3DS requests. Some populate only the mandatory fields. Others send the full complement. The difference in frictionless rates between minimal and comprehensive data can be 15-20 percentage points.
Issuer-side variance is the factor you can’t control, but can diagnose. Track your frictionless rate by issuer country and by issuing bank where possible. If your frictionless rate is 90% for UK issuers but 60% for a specific German bank, the problem is that bank’s ACS configuration, not your data quality. You can’t fix their risk model, but you can use this data to decide where exemption requests make sense versus where you should accept the challenge flow.
PSP version support matters. Transactions sent using older 3DS message versions (2.1.0) receive worse frictionless rates than those sent using 2.2.0 or 2.3.1. The newer versions support richer data exchange and better risk signaling. If your PSP hasn’t upgraded, your frictionless rate is artificially depressed.
Challenge method affects completion rate. Even when a challenge does trigger, the cardholder still needs to complete it. Push-notification challenges through bank apps (common in the UK) have higher completion rates than SMS OTP challenges (more common in other markets). You can’t choose the challenge method, but understanding the dominant method in each market helps you forecast conversion impact. Markets where SMS OTP is the primary challenge method will show higher abandonment on challenged transactions.
The multi-PSP problem: 3DS across payment processors
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.
This creates two problems. First, inconsistent authentication UX. One processor might render challenges as an in-page overlay while another does a full-page redirect. Your conversion metrics become skewed by which processor happened to handle a given transaction. Second, inconsistent data quality. Each PSP sends different optional data fields to the issuer, producing different frictionless rates for the same customer base.
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.
Where 3DS mandates are heading
The direction is clear: more markets are mandating authentication, not fewer.
The EU and UK have had SCA mandates in place since 2021. Japan mandated 3DS2 for all card transactions from April 2025. India’s RBI currently mandates Additional Factor Authentication for domestic online card transactions, and from April 2026, two-factor authentication becomes mandatory for all digital payment types (Business Standard). Brazil requires 2FA for Pix and digital payments.
The trend beyond mandates: even in markets without legal requirements, like the US, issuers are increasingly triggering 3DS based on their own risk assessment. 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. The issuer bears the fraud liability when 3DS succeeds, so they have strong incentive to push authentication.
What this means for your implementation:
If you’re only in SCA-mandated markets (EU, UK): You’re already handling 3DS. Focus on exemption strategy and frictionless rate optimization. The mandate isn’t going away, so the competitive advantage comes from implementation quality.
If you process in India: Your authentication infrastructure needs to support the April 2026 expansion from card transactions to all digital payment types. The scope change is significant.
If you’re primarily US-based: 3DS isn’t mandated, but issuer-initiated 3DS challenges are increasing. Building your 3DS infrastructure now means you’re prepared when (not if) your issuer mix starts triggering more authentication. The US is the largest card market and has the highest CNP fraud rate globally (42% of global fraud on 26% of card volume, per the Nilson Report). Regulatory pressure will follow.
If you operate cross-border: You need authentication infrastructure that handles different mandates per market. A transaction from an EU customer requires SCA. A transaction from a US customer might not. A transaction from India has its own AFA requirements. Managing these rules per-PSP is the kind of complexity that breaks when you’re not watching. Managing them once through an orchestration layer or a dedicated 3DS provider is more sustainable — and the payment orchestration PCI compliance benefits extend well beyond 3DS, reducing your overall audit scope.
Japan’s post-mandate data is the strongest signal: 60% frictionless rate, 93% conversion, 30%+ dispute reduction. The markets that mandate 3DS and have mature issuer infrastructure show better outcomes, not worse. The question isn’t whether 3DS is coming to your market. It’s whether you’ll be ready when it does.
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.
