3D Secure 2 (3DS2) is the authentication protocol that decides whether most of your card-not-present transactions get approved silently, get challenged with extra friction, or get declined entirely. It governs how Strong Customer Authentication is satisfied across Europe, the UK, India, Japan, and now Asia-Pacific markets after the April 2026 Visa and Mastercard enforcement milestone. For European merchants, it has been mandatory for years. For everyone else, it is becoming the global standard for online card payment security.
The merchants who understand 3DS2 well capture meaningful authorization rate lifts, shift chargeback liability to issuers on authenticated transactions, and avoid the conversion drop that plagued the older 3DS1 protocol. The merchants who treat it as a compliance checkbox leak revenue at every step: unnecessary challenges, false declines, missed exemptions, and chargeback losses that should have been the issuer’s problem.
This guide explains what 3DS2 is, how the protocol actually works, the difference between frictionless and challenge flows, how SCA exemptions stack on top, the global regulatory picture as it stands in 2026, and what enterprise merchants should be doing to optimize authentication performance across multiple PSPs and acquirers.
3D Secure 2 (3DS2) is a real-time card authentication protocol that allows the issuing bank to verify a cardholder’s identity during a card-not-present transaction by exchanging rich contextual data with the merchant’s payment infrastructure, with the issuer deciding whether to approve the transaction frictionlessly, challenge the cardholder for additional verification, or decline.
Three elements define the protocol:
A data exchange. The merchant’s 3DS infrastructure sends over 100 data elements to the issuer at the moment of authorization, including device fingerprint, transaction history, IP address, billing and shipping consistency, merchant category, and transaction amount. The issuer uses this data to assess risk.
A real-time decision by the issuer. Based on the data and its own risk model, the issuer decides one of three outcomes: approve silently (the frictionless flow), approve after a customer challenge, or decline.
A liability shift on authenticated transactions. When an issuer authenticates a transaction through 3DS2, the chargeback liability for fraud disputes shifts from the merchant to the issuing bank. This is the single most commercially significant aspect of the protocol for enterprise merchants.
For a deeper look at how this fits into the broader authentication picture, see Gr4vy’s guide on payment authentication.
To understand why 3DS2 matters, it helps to know what 3DS1 did badly. The original 3D Secure protocol launched in 1999 (as Verified by Visa) and authenticated cardholders through static passwords and full-page browser redirects. It worked technically, but it produced one of the worst conversion impacts of any payment technology in the modern era.
The problems with 3DS1:
3DS2 (also called EMV 3-D Secure, formally maintained by EMVCo and used in current network programs like Visa Secure and Mastercard Identity Check) was redesigned to fix these problems. The differences:
| Dimension | 3DS1 (legacy) | 3DS2 (current) |
|---|---|---|
| Data exchanged | Handful of fields | 150+ data elements per transaction |
| Default flow | Challenge for every transaction | Frictionless (silent) for most transactions |
| Mobile experience | Web-only, poorly adapted | Native in-app SDKs |
| Authentication method | Static passwords | Biometrics, OTP, in-app prompts |
| Risk assessment | Limited | Risk-based authentication using rich data |
| Customer perception | Friction, abandonment | Mostly invisible |
| Liability shift | Yes, on authenticated transactions | Yes, on authenticated transactions |
3DS1 has been sunset by the major card schemes. Current implementations use EMV 3DS version 2.2 or 2.3.x, with version 2.3 adding updates targeted at mobile-native authentication and decoupled authentication scenarios.
A 3DS2 transaction involves four interoperating components that communicate in real time during the authentication request. Understanding these components is essential for diagnosing authentication problems and optimizing performance.
1. The 3DS Server (sometimes called the 3DS Requestor) sits inside the merchant’s payment infrastructure (or their PSP’s, or their orchestration platform’s). It collects the transaction data, formats the authentication request, and sends it to the Directory Server.
2. The Directory Server (DS) is operated by the card scheme (Visa, Mastercard, American Express, JCB, Discover). It routes the authentication request to the appropriate issuer’s Access Control Server based on the card BIN.
3. The Access Control Server (ACS) is operated by the issuer (or their authentication vendor). It applies the issuer’s fraud and risk model to the transaction data, decides the outcome, and returns the response.
4. The 3DS SDK (for mobile transactions) is integrated into the merchant’s iOS or Android app. It collects device and behavioral data and submits the authentication request natively, avoiding the web-view friction that mobile 3DS1 created.
The flow during a transaction:
All of this happens in seconds. For the majority of transactions, the customer experiences nothing visible.
The single most important strategic concept in 3DS2 is the distinction between frictionless and challenge flows. The issuer decides which one to use based on the data it receives. Better data produces more frictionless approvals; worse data produces more challenges and more drop-offs.
The issuer evaluates the transaction data, judges the risk acceptable, and approves the authentication without any customer interaction. The customer notices nothing. The merchant gets the liability shift. This is the outcome every merchant should be optimizing for.
The data elements that increase the likelihood of a frictionless decision include:
A returning customer on a recognized device, transacting with a familiar merchant for a normal amount, will almost always receive frictionless authentication. A new customer on an unfamiliar device, with mismatched billing and shipping addresses, transacting for an unusual amount, will likely face a challenge.
The implication for payment teams is direct: incomplete data integrations generate unnecessary challenges. If your 3DS Server is omitting device fingerprinting fields, missing account history, or sending stale shipping addresses, your issuers are challenging transactions they would otherwise approve frictionlessly. Authentication rates drop, and revenue with them.
The issuer decides the risk warrants additional verification and prompts the cardholder to complete an authentication challenge. The challenge is usually a biometric prompt (fingerprint, Face ID), an OTP sent via SMS or in-app push, or a banking app confirmation.
Challenge flows serve a real purpose: they protect high-risk transactions from fraud while still permitting legitimate purchases to proceed. The problem is that challenges produce drop-off. Industry data suggests 10-30% of customers abandon at the challenge step depending on the implementation quality, the customer’s familiarity with their bank’s authentication method, and the device.
The merchants who minimize unnecessary challenges through better data quality, more frictionless eligibility, and smart use of exemptions consistently achieve higher net authorization rates than those who challenge everything.
The third possible outcome is that the authentication fails entirely. Common reasons:
Failed authentication typically results in a declined transaction, though some merchants configure their workflows to retry through a different authentication path or to fall back to non-3DS processing in markets where that is permissible.
Strong Customer Authentication (SCA) is a regulation. 3DS2 is a protocol. The two are often used interchangeably, but they are distinct.
SCA is a regulatory requirement that says electronic payments above a defined threshold must be authenticated using two of three factors: something the cardholder knows (password, PIN), something they have (phone, hardware token), or something they are (biometric). It was introduced in Europe through PSD2’s Regulatory Technical Standards, took effect in 2019-2021 depending on the country, and has been fully enforced (no soft-decline grace period) since 2022.
3DS2 is the dominant technical mechanism for satisfying SCA on card-not-present transactions. Other authentication paths exist, but for most online card payments in SCA-regulated markets, 3DS2 is the path that gets used.
The 2026 regulatory picture by market:
Europe and UK. SCA is fully enforced. Non-authenticated card-not-present transactions get declined by issuers unless they qualify for a specific exemption (more on those in the next section). PSD3 and the Payment Services Regulation (PSR) are in late-stage trilogue between the European Commission, Council, and Parliament as of mid-2026, with the consolidated text expected to be adopted in the second half of 2026 and to apply 18 months after publication. PSD3 will refine rather than replace the SCA framework, but new 3DS implementations should anticipate its direction.
Asia-Pacific. Both Visa and Mastercard set April 2026 as the critical enforcement and fine-escalation milestone for issuers and acquirers in the APAC region. Markets including India, Japan, Singapore, and Australia have aligned to global 3DS2 standards, with India operating its own SCA-equivalent rules through the Reserve Bank of India.
Mastercard Identity Check set October 2025 as the hard deadline for all acquirers in the EEA to be compliant with the current Identity Check program. From October 2026, additional Mastercard mandates relating to transaction tracking come into effect (see Gr4vy’s guide on the Mastercard Transaction Link Identifier for the full timeline).
United States. SCA is not currently mandated, but 3DS2 is widely supported and increasingly adopted for liability shift on high-risk transactions. The US Payments Forum publishes ongoing guidance for US merchants implementing 3DS2 selectively.
For European subscription businesses specifically, recurring payments interact with SCA in important ways. Our guide on recurring payments in Europe covers the compliance and conversion implications in detail.
Not every transaction needs to go through a 3DS2 challenge. PSD2 and similar regulations include several exemptions, and using them well is one of the highest-impact authentication optimizations available.
The five main SCA exemptions:
The acquirer or issuer determines, based on real-time risk scoring, that the transaction is low risk and qualifies for SCA exemption. TRA is the most commercially valuable exemption because it can be applied to a large share of standard ecommerce transactions, but it requires the acquirer to maintain a low fraud rate (below specific thresholds defined by PSD2).
TRA thresholds are tied to fraud rates:
This is why acquirer choice matters. Acquirers with clean fraud books unlock TRA on higher transaction values for their merchants. Acquirers with elevated fraud rates lose TRA eligibility, with measurable conversion impact.
Transactions below €30 are exempt from SCA, provided the cardholder has not made more than five LVT-exempted transactions or accumulated more than €100 in LVT exemptions since their last full SCA authentication.
LVT is useful for low-AOV businesses (digital goods, microtransactions, parking, transit) but the cumulative limits prevent it from being a blanket solution.
MITs are exempt from SCA when properly classified, provided the original CIT that established the stored-credential relationship underwent SCA authentication. This is the exemption that makes subscription billing, installments, and unscheduled credential-on-file payments work in SCA-regulated markets without re-authenticating the customer for every charge.
For the full framework, see Gr4vy’s guide on merchant-initiated and customer-initiated transactions.
The cardholder can add a specific merchant to a “trusted list” maintained by their issuer, allowing future transactions with that merchant to bypass SCA. This is rarely used for general ecommerce because it requires customer action to set up, but it has applications in B2B and high-frequency commerce.
Lodged-card programs, virtual cards, and corporate procurement payments that meet PSD2’s secure corporate payment process criteria can be exempted. This is mostly relevant to travel and B2B procurement rather than B2C ecommerce.
The exemption that produces the biggest authorization lift for most merchants is TRA. Combining TRA with MIT classification on recurring billing typically eliminates most challenge flows in a properly-implemented stack, while maintaining full SCA compliance.
The liability shift is one of the most commercially significant aspects of 3DS2 implementation, but it is often misunderstood. The rules are specific.
What does shift: When a transaction is authenticated through 3DS2 (whether frictionless or challenge) and the cardholder subsequently disputes the transaction as fraudulent, the chargeback liability transfers from the merchant to the card-issuing bank. The merchant is not responsible for the fraud loss.
What does not shift:
For enterprise merchants processing meaningful CNP volume, the liability shift typically represents six- to seven-figure annual savings on chargeback losses. The shift is real, measurable, and one of the strongest financial cases for properly implementing 3DS2.
Most coverage of 3DS2 treats it as a single-PSP integration question: which 3DS server to use, how to configure the SDK, how to handle the response. For enterprise merchants running multi-PSP setups, the picture is more nuanced.
Three architectural patterns exist:
Pattern 1: PSP-managed 3DS. Each PSP handles its own 3DS authentication. The merchant integrates with each PSP’s 3DS server separately. Different PSPs may implement 3DS slightly differently, with different data field handling, different challenge UX, and different exemption application logic. The result is inconsistent authentication performance across providers and operational complexity scaling with each PSP added.
Pattern 2: Standalone 3DS server. The merchant uses a dedicated 3DS server provider (separate from any single PSP) and routes authentication through it before submitting authorization to whichever PSP processes the transaction. This decouples authentication from payment processing but adds another vendor relationship and integration point.
Pattern 3: Orchestration-managed 3DS. A payment orchestration platform handles 3DS authentication centrally, applying consistent data field handling, exemption logic, and challenge UX across every PSP it routes to. The merchant configures the 3DS rules once, and the platform applies them regardless of which acquirer processes the authorization.
The third pattern is the cleanest fit for multi-PSP merchants. Authentication performance becomes consistent. Exemption logic is applied uniformly. Data quality is controlled in one place rather than depending on each PSP’s integration. And critically, the 3DS authentication context can be carried forward through routing decisions, including failover and retry scenarios.
For more on how this works in practice, see Gr4vy’s guides on intelligent payment routing and how to increase payment approval rates in 2026.
When a transaction fails authentication or is declined after authentication, the retry logic that follows interacts with 3DS in important ways.
Soft declines after successful authentication. If 3DS2 authenticates the transaction but the subsequent authorization is soft-declined (insufficient funds, network timeout), the authentication context typically remains valid for a retry within a defined window (usually 24-72 hours). The merchant can retry without re-authenticating, preserving both the liability shift and the absence of friction.
Authentication failures. If 3DS2 authentication itself fails, retrying immediately rarely succeeds because the issuer’s risk decision will not change. The standard pattern is to either fall back to non-3DS processing where regulations permit, prompt the customer to update their card details, or escalate to customer outreach.
Exemption-based retries. A transaction that was challenged at the first attempt may be retried as an exempted transaction if the merchant’s acquirer supports TRA exemption and the transaction qualifies. This is one of the more sophisticated retry patterns and requires workflow logic to evaluate exemption eligibility before each retry.
For the full retry framework, see Gr4vy’s guide on subscription payment decline recovery.
A handful of patterns separate well-implemented 3DS2 setups from troubled ones:
Sending incomplete data. The single largest source of unnecessary challenges is missing or stale data fields. Issuers challenge transactions when they cannot confidently assess risk; incomplete data forces them into that position. Audit your 3DS data field coverage against the EMVCo specification and fix gaps before optimizing anything else.
Treating 3DS as a binary on/off. Some merchants enable 3DS for every transaction; others disable it entirely. Both extremes leave revenue on the table. The optimal pattern is rule-based application: 3DS applied where SCA requires it or where the liability shift is valuable, exempted via TRA where the risk profile permits, and bypassed where regulations allow and the fraud cost is acceptable.
Implementing 3DS at the PSP level rather than the workflow level. Each PSP applies 3DS slightly differently. Without a common orchestration layer, the same transaction can be authenticated frictionlessly by one PSP and challenged by another, producing inconsistent performance across the stack.
Missing the MIT-CIT linkage. For recurring billing, the SCA exemption on subsequent MITs depends on the original CIT having been properly authenticated. Implementations that skip SCA on the initial sign-up CIT find themselves unable to claim the MIT exemption on renewals, with every renewal then subject to authentication that cannot complete (the customer is not present).
Ignoring the mobile experience. 3DS2 on mobile through web views produces measurably worse results than native SDK implementation. Apps that rely on browser-based 3DS see higher abandonment than apps using the native iOS or Android SDKs.
Failing to monitor authentication performance. 3DS2 performance varies by issuer, geography, card type, and transaction context. Without segmented monitoring (frictionless rate by issuer, challenge completion rate by device, false decline rate by transaction value), problems hide in aggregate metrics and never get diagnosed.
Treating challenges as inherent friction rather than fixable. When challenges happen, the data the merchant sent was insufficient to convince the issuer otherwise. The challenge is a signal that something about the merchant’s data quality, fraud history, or exemption strategy is suboptimal. Treating challenges as a feedback loop rather than an inevitability is what separates high-authorization merchants from average ones.
3D Secure 2 (3DS2) is a real-time card authentication protocol that allows the issuing bank to verify a cardholder’s identity during a card-not-present transaction. It exchanges rich contextual data with the merchant’s payment infrastructure, and the issuer decides whether to approve the transaction frictionlessly, challenge the cardholder for additional verification, or decline. Successful 3DS2 authentication shifts chargeback liability for fraud disputes from the merchant to the issuing bank.
3DS1 (the original protocol from 1999) used static passwords and disruptive full-page redirects, exchanging only a handful of fields with the issuer. It produced high abandonment and poor mobile experience. 3DS2 (the current standard maintained by EMVCo) exchanges over 150 data elements per transaction, uses risk-based authentication, supports biometrics and native mobile SDKs, and approves most transactions frictionlessly without customer interaction. 3DS1 has been sunset by the major card networks; current implementations use EMV 3DS 2.2 or 2.3.x.
3DS2 is a technical protocol. SCA (Strong Customer Authentication) is a regulatory requirement. SCA mandates that electronic payments be authenticated using two of three factors (something you know, have, or are). 3DS2 is the dominant technical mechanism for satisfying SCA on card-not-present transactions, but it is not the only one. The two are often conflated but they describe different things: one is the regulation, the other is one of the technologies that complies with it.
No. 3DS2 is required where SCA regulations mandate it (currently Europe, UK, India, Japan, and increasingly Asia-Pacific markets) and is recommended where the liability shift on authenticated fraud is commercially valuable. Even in SCA-regulated markets, several exemptions allow specific transactions to bypass 3DS2 challenges while remaining compliant. In the US and other markets without SCA mandates, 3DS2 is used selectively for high-risk transactions rather than universally.
Frictionless authentication is the 3DS2 outcome where the issuer evaluates the transaction data, judges the risk acceptable, and approves the authentication without requiring any customer interaction. The customer notices nothing; the merchant gets the liability shift. Most modern 3DS2 transactions should resolve frictionlessly when the merchant sends complete, high-quality data. Frictionless rates of 90% or higher are achievable for well-implemented stacks.
A challenge happens when the issuer’s risk model judges that the transaction warrants additional verification before approval. Common triggers include: unusual transaction amounts, mismatches between billing and shipping addresses, unfamiliar devices, new customers without transaction history, transactions in high-risk merchant categories, and incomplete data sent by the merchant. Improving data quality typically reduces challenge rates significantly.
When a transaction is authenticated through 3DS2 (whether frictionless or challenge) and the cardholder subsequently disputes it as fraudulent, the chargeback liability transfers from the merchant to the issuing bank. The merchant is not responsible for the fraud loss. The shift applies only to fraud disputes; non-fraud chargebacks (item not received, billing errors, etc.) remain the merchant’s responsibility even on 3DS-authenticated transactions.
Transaction Risk Analysis (TRA) is an SCA exemption that allows the acquirer or issuer to bypass 3DS2 challenges on transactions judged to be low risk in real time. TRA eligibility is tied to the acquirer’s fraud rate: acquirers with cleaner fraud books can exempt transactions up to higher thresholds (€100, €250, or €500 depending on the fraud band). For most merchants, TRA is the most commercially valuable exemption available and the strongest reason to evaluate acquirer fraud performance during PSP selection.
Properly classified merchant-initiated transactions (MITs) are exempt from SCA, provided the original customer-initiated transaction (CIT) that established the stored-credential relationship underwent SCA authentication. This is the exemption that makes subscription billing, installments, and unscheduled credential-on-file payments work in SCA-regulated markets without re-authenticating the customer for every charge. The full framework is covered in Gr4vy’s guide on MIT vs CIT.
Yes. EMV 3DS2 provides native iOS and Android SDKs that allow authentication to happen directly inside the mobile app, avoiding the web-view friction that affected 3DS1 on mobile. Native SDK implementation typically produces higher frictionless rates and lower challenge abandonment than web-based 3DS on mobile. Mobile-first businesses should always use the native SDK rather than browser-based 3DS through a web view.
Implemented well, 3DS2 typically improves net authorization rates by reducing fraud-related declines and unlocking the liability shift on authenticated transactions. Implemented poorly (with incomplete data, unnecessary challenges, or missing exemption logic), it can reduce authorization rates by producing challenge abandonment and false declines. The difference between well-implemented and poorly-implemented 3DS2 can be 5-15 percentage points of authorization rate on the affected volume.
Properly implemented, 3DS2 should not meaningfully hurt conversion. Most transactions resolve frictionlessly with no customer-visible step. Challenge rates can be minimized through complete data integration and smart exemption use. Modern 3DS2 implementations with native mobile SDKs, biometric challenges, and TRA exemption strategies typically achieve conversion impacts under 1-2% on the affected volume, well below 3DS1’s typical 5-15% impact.
EMV 3DS 2.3 (released in 2023, with version 2.3.1 in 2024) adds improvements over 2.2 in several areas: stronger mobile-native authentication, support for decoupled authentication (where the customer authenticates asynchronously through a banking app), better handling of secure remote commerce integrations, and additional data fields. Most modern implementations use 2.2 or 2.3.x; 2.3 adoption is growing but is not yet universal across all issuers.
The Mastercard Transaction Link Identifier (TLID), which takes full effect in October 2026, is separate from 3DS2 authentication but interacts with it on stored-credential transactions. When the original CIT is authenticated through 3DS2 with SCA, the authentication context flows forward to subsequent MITs through the TLID and related fields, preserving both the SCA exemption and the chain-of-consent that issuers use to approve MIT renewals. For details on TLID specifically, see Gr4vy’s Mastercard TLID guide.
3DS2 is one of the highest-impact authentication optimizations available to any merchant with meaningful card-not-present volume. The merchants who treat it as a configurable workflow (rich data, exemption strategy, multi-PSP consistency, native mobile SDKs) consistently outperform those who treat it as a compliance checkbox.
For most enterprise merchants, the work falls into three categories: ensuring data field coverage is complete and current, applying SCA exemptions where regulations and acquirer fraud rates permit, and unifying 3DS implementation across PSPs so authentication performance is consistent regardless of routing decisions.
Gr4vy’s cloud-native payment orchestration platform handles 3DS2 implementation centrally across more than 400 connected PSPs and payment methods. Rich data fields are managed at the orchestration layer rather than per-PSP. Exemption logic is applied consistently. The authentication context flows forward through routing, retry, and failover decisions, preserving both the liability shift and the SCA exemption on related transactions.
If you’re evaluating your current 3DS2 setup or want to understand how authentication could be unified across your existing PSP relationships, contact our team for a stack review and integration plan tailored to your current architecture.
Much Better Adventures has chosen Gr4vy’s payment orchestration platform to improve performance, expand payment choice,…
For years, the Wikimedia Foundation's payment infrastructure was a constraint on its mission: expensive to…
PSD3 and the Payment Services Regulation (PSR) are the most significant overhaul of European payments…
Integration gives merchants direct access to global acquiring through orchestration, with control over routing, authentication,…
Every card transaction is classified by the card networks as either customer-initiated (CIT) or merchant-initiated…
Peak moments don’t break systems by accident. They expose the limits that were always there.…