3D Secure (3DS) is the authentication protocol that sits between your checkout page and the card issuer's approval system. When a customer completes a purchase online, 3DS is what determines whether they sail through without interruption or receive a prompt to verify their identity before the transaction is approved. It is, in short, the backbone of online card payment security and understanding how it works is no longer optional for anyone managing payment operations.
This guide covers everything a payment or finance team needs to know: how the protocol works, what changed with version 2, how SCA exemptions and liability shift interact, which markets now mandate it, and how to evaluate whether your current 3DS implementation is working as hard as it should.
The name refers to three domains that interact during every authenticated transaction.
These three parties exchange a structured set of data elements in real time whenever a card-not-present transaction triggers authentication. The quality and completeness of that data exchange is what determines the outcome for the cardholder, frictionless approval or a step-up challenge.
3DS was originally developed in 1999 by Celo Communications for Visa, and launched publicly in 2001 as Verified by Visa (VBV). Mastercard followed with SecureCode. In their original form, both programmes redirected cardholders to a separate bank-hosted page and asked them to enter a static password. The experience was widely disliked: it was slow, unfamiliar, and frequently caused transaction abandonment.
EMVCo, the joint body of Visa, Mastercard, Amex, Discover, JCB, and UnionPay, published the 3DS 2.0 specification in October 2016, with 2.1.0 in 2017 and 2.2.0 in 2018. Version 2.3 followed in 2022. The new protocol is now commonly called EMV 3DS to distinguish it from the legacy protocol. Mastercard deprecated 3DS 1.0 support in October 2022; Visa followed. Both schemes then deprecated EMV 3DS 2.1 in mid-2024, pushing all volumes to 2.2 as the current minimum.
Key milestone: As of September 2024, Visa deprecated EMV 3DS 2.1.0. All transactions must now run on 3DS 2.2.0 or above. If your integration or PSP has not migrated, you may be outside scheme compliance.
3D Secure delivers value across three dimensions: fraud reduction, liability protection, and regulatory compliance.
Beyond fraud, 3DS is the primary mechanism for meeting Strong Customer Authentication requirements under PSD2 in Europe and equivalent mandates in markets including the UK, Japan, and India. For any merchant operating in regulated markets, 3DS compliance is not optional. Implementing it correctly also has a measurable impact on authorisation rates: issuers are more likely to approve transactions that arrive with complete authentication data, because the data reduces their own risk exposure. Merchants who send high-quality 3DS data consistently see lower challenge rates and higher approval rates compared to those submitting incomplete data sets.
The gap between 3DS version 1 and version 2 is significant enough that they are effectively different products.
3DS 1, launched publicly in 2001 as Verified by Visa and Mastercard SecureCode, required cardholders to enter a static password on a separate bank-hosted page. The redirect was disruptive, the password was frequently forgotten, and the experience caused substantial transaction abandonment. The protocol also transmitted very limited data to the issuer, meaning most transactions were challenged regardless of actual risk.
EMV 3DS 2, published by EMVCo from 2016 onwards, replaced this model entirely. The challenge flow is now embedded within the merchant's checkout rather than redirecting to an external page. More importantly, the protocol transmits up to 150 data elements to the issuer's Access Control Server, enabling genuine risk-based authentication. This is what makes frictionless flow possible: when the data provides sufficient confidence that the real cardholder is present, the issuer approves the transaction without any visible challenge. The result is that approximately 80 to 85 percent of 3DS 2 transactions complete without the cardholder needing to do anything.
Both Mastercard and Visa have fully deprecated 3DS 1, with Visa completing its deprecation of EMV 3DS 2.1 in September 2024. The current minimum across all major schemes is 3DS 2.2.
The most persistent misconception is that 3DS harms conversion rates. This was true of 3DS 1, where the redirect and static password genuinely caused abandonment. It is not an accurate characterisation of a well-implemented 3DS 2 integration. When merchants send complete data and issuers process it correctly, the majority of transactions are authenticated without any visible friction. The conversion impact of 3DS 2 is largely determined by implementation quality, not by the protocol itself.
A second common misconception is that 3DS and SCA are the same thing. SCA is a regulatory requirement; 3DS is the technical mechanism most commonly used to meet it. They are related but distinct. It is possible to satisfy SCA through other means, and it is possible to run 3DS on transactions that are exempt from SCA.
A third misconception is that applying SCA exemptions is always the right approach. Exemptions reduce friction, but they also return fraud liability to the merchant or acquirer. The decision to apply an exemption is a deliberate tradeoff between conversion and liability protection, not a default optimisation. Teams that treat exemption application as a blanket conversion lever, without accounting for the associated liability exposure, tend to discover the cost in their chargeback reports.
3DS 2 is a substantial improvement on its predecessor, but it is not without real operational complexity. The first challenge is data quality. The protocol's frictionless flow depends on the merchant submitting complete, accurate data elements. Organisations without the infrastructure to collect and transmit device fingerprint data, account history fields, and address match indicators consistently will see higher challenge rates and lower frictionless approval rates than the protocol is capable of delivering.
Integration complexity is a second consideration. 3DS involves multiple parties: the merchant's payment gateway or 3DS Server, the card scheme's Directory Server, and the issuer's Access Control Server. Each scheme runs its own programme with specific certification requirements and response code handling. Merchants operating across multiple card schemes need a 3DS Server certified for each, and must handle scheme-specific authentication values correctly to preserve liability shift.
Scheme rule changes add ongoing maintenance overhead. The Mastercard AAV tightening in early 2025 is a recent example: merchants who had not adopted 3RI processing for recurring and installment flows began seeing 05E and 05I response codes that directly affected authorisation rates. Keeping pace with scheme programme updates requires either dedicated internal resource or a 3DS provider that absorbs that maintenance on your behalf.
Finally, the liability tradeoff inherent in SCA exemption management is a drawback that is easy to underestimate. Applying exemptions aggressively improves conversion in the short term but increases fraud exposure. There is no universal right answer; the correct balance depends on your fraud rate, your transaction mix, and your chargeback tolerance.
When a customer initiates a card payment on your website or app, the following sequence occurs behind the scenes.
The distinction between these two paths is central to understanding how 3DS affects your conversion rate and fraud exposure.
In frictionless flow, the issuer authenticates the transaction passively based on the data submitted. The cardholder experiences no interruption. Industry data suggests that approximately 80–85% of 3DS 2 transactions complete via frictionless flow when merchants send complete data.
In challenge flow, the issuer requires active cardholder participation. The quality of the challenge experience has improved substantially under 3DS 2, it is embedded within the checkout rather than a full-page redirect, but it still introduces friction that can cause abandonment.
The key lever you control as a merchant is the quality of the data you submit. Sending incomplete device fingerprint data, missing shipping-to-billing address match indicators, or omitting account history fields pushes more transactions into challenge flow unnecessarily.
In Europe, 3DS is the primary technical mechanism for meeting the Strong Customer Authentication (SCA) requirement introduced by PSD2. SCA mandates two-factor authentication for customer-initiated electronic payments, combining at least two of: something the customer knows, something they possess, and something they are.
3DS 2 satisfies this requirement by enabling dynamic linking (tying the authentication to a specific transaction amount and payee) and supporting biometric and possession-based factors. Not all transactions require SCA, however. PSD2 provides four categories of exemption.
Important: When an exemption is applied and accepted by the issuer, liability for fraud chargebacks remains with the merchant or acquirer, not the issuer. The liability shift that 3DS provides only applies when full authentication occurs. This tradeoff between friction reduction and liability protection is one of the most consequential decisions in payment operations.
One of the most commercially significant aspects of 3DS is the liability shift mechanism. Under standard card-not-present rules, the merchant bears the cost of fraud chargebacks. When a transaction is successfully authenticated via 3DS, the fraud chargeback liability transfers to the card issuer.
This shift applies specifically to fraud-coded chargebacks, the category where a genuine cardholder disputes a transaction they did not authorise. It does not apply to service disputes (non-delivery, quality issues), friendly fraud classified as service, or transactions processed outside the 3DS flow.
To secure the liability shift, your integration must pass back the ECI code and CAVV/AAV values returned from the authentication step into your authorisation request. Dropping these values, a common integration error, means you cannot prove authentication occurred, and the liability reverts to you.
EMV 3DS 2.2 is the current minimum required. Key capabilities introduced at 2.2 include:
3DS 2.3, published in 2022 by EMVCo, adds further UI enhancements, automated out-of-band authentication transitions, and improved data sharing. Scheme adoption is progressing; merchants should verify 2.3 support timelines with their PSP or 3DS Server provider.
3DS Requestor Initiated (3RI) is a 3DS 2.2 authentication mode that allows a merchant or payment service provider to initiate an authentication request without the cardholder being actively present in the transaction session. Unlike standard 3DS flows, 3RI requires no cardholder interaction, the merchant sends the authentication request to the Directory Server using the cardholder's previously stored credentials and the original network transaction ID from an earlier authenticated session.
3RI is designed for use cases including: subscription renewals where the cardholder is not present, installment payment sequences after the initial authenticated purchase, BNPL transaction chains, account verification flows, and card-on-file account updates triggered by scheme account updater services.
In early 2025, Mastercard issued a global operator notice tightening its AAV (Accountholder Authentication Value) Validation Service. The core requirement, Requirement 104 in Mastercard's IDC Programme Guide, is explicit: the same AAV and DS Transaction ID must not be reused across multiple authorisation messages.
In practice, this means any workflow where a merchant was submitting the same AAV from an earlier authentication against multiple authorisation attempts is now flagged. Mastercard's updated validation service identifies AAV reusage and returns an 05E (Merchant Format Error) or 05I response code. These codes signal fraud risk due to AAV reusage and give issuers the option to approve or decline based on their own risk tolerance, the merchant no longer gets the benefit of the doubt.
What this means operationally: If your authorisation decline reports show a spike in 05E or 05I response codes on Mastercard transactions, particularly on recurring charges, installment sequences, or retry flows, AAV reusage is the likely cause. The required fix is to adopt 3RI processing, Data Share Only, or Mastercard Identity Check Insights for transactions that require more than one AAV in the authorisation flow. Reusing the authentication values from an earlier transaction is no longer a valid approach.
Mastercard's notice also reminded operators that AAV leading indicators ('k', 'l', 'm', 'n' values under the SPA2 design approach) are currently active, and that new values will be announced for additional authentication approaches. The authoritative reference is Appendix K of the Mastercard IDC Programme Guide (Transaction Status, SLI, and Liability Mapping chart).
For a full technical treatment of 3RI, including how it differs from MIT processing, the correct implementation pattern for each use case, and the specific Mastercard AAV validation changes, see Article 11: 3DS Requestor Initiated (3RI): What It Is, When to Use It, and Why Mastercard Is Forcing the Issue Now.
While EMVCo manages the underlying protocol, each card scheme runs its own programme with specific naming and rules.
For merchants operating across multiple card schemes, your 3DS Server must be certified for each scheme's Directory Server and must correctly handle scheme-specific response codes and authentication values.
The decision of how to implement 3DS is as consequential as the decision to implement it. There are three primary approaches, each with different tradeoffs across cost, control, and ongoing maintenance.
The first is a hosted 3DS page provided by your payment gateway or PSP. This is the lowest-effort path: the provider handles the 3DS flow on your behalf, and you have minimal integration work. The tradeoff is limited control over the data submitted, which can constrain your frictionless rate, and limited visibility into authentication outcomes.
The second is an SDK integration, typically used for native mobile applications. The 3DS SDK handles the authentication flow within the app, supporting both frictionless and challenge flows natively. This approach gives more control over the cardholder experience but requires mobile development resource and ongoing SDK updates as scheme requirements evolve.
The third is a standalone 3DS Server, where you integrate directly with a dedicated authentication provider rather than relying on your payment gateway's built-in 3DS handling. This approach decouples authentication from authorisation, which is particularly valuable in multi-acquirer environments and for merchants who want to manage SCA exemption logic independently. It also provides the most complete data and reporting visibility.
For most payment teams evaluating their options, the standalone 3DS Server path delivers the best combination of control, frictionless rate optimisation, and scheme compliance, particularly for organisations processing across multiple acquirers or card schemes. For a full technical treatment of each approach, including integration architecture and the tradeoffs in detail, see Article 8: How to Implement 3D Secure: Hosted Page vs SDK vs 3DS Server.
PCI Proxy provides a standalone 3DS Server that handles authentication across all major card schemes, including JCB for the Japanese market, without requiring merchants to build or certify their own 3DS infrastructure. The integration supports frictionless and challenge flows, SCA exemption signalling, and decoupled authentication for recurring and subscription use cases.
For payment and finance teams evaluating their 3DS posture, the key questions are: Is your current integration on 3DS 2.2 or above? Are you passing complete data elements to maximise frictionless rates? Are you correctly handling ECI and CAVV values for liability shift? And are you applying SCA exemptions strategically, balancing conversion rate against fraud exposure?
Further reading: Each topic covered in this guide — SCA exemptions, liability shift, implementation approaches, recurring payments, and market-specific mandates — is explored in depth in the articles linked below.
.svg)
.png)
