March 2026  |  GPayments Insights  |  12 min read

Overview

The most important thing to understand about EMV 3DS 2.x is that it is not an update to 3DS 1.0, it is a replacement. The underlying logic, data architecture, and customer experience model are entirely different.

This matters for every financial institution, payment service provider, and enterprise merchant that still holds legacy 3DS 1.0 infrastructure or is evaluating a 3DS migration. The performance gap between the two protocols is not marginal. In authentication rates, mobile compatibility, regulatory alignment, and fraud detection accuracy, EMV 3DS 2.x operates on a fundamentally different level.

Why 3DS 1.0 Became a Problem

3D Secure 1.0 was effective as a fraud prevention tool but created a customer experience problem that became commercially significant as e-commerce scaled. The authentication step required a browser redirect to a bank-hosted page where the customer entered a static password or responded to a security question. This introduced visible friction into the checkout flow at precisely the moment conversion is most fragile.

Industry data consistently showed that 3DS 1.0 challenges contributed to cart abandonment rates. As a result merchants faced a direct trade-off between fraud protection and conversion. The protocol also predated the mobile era entirely and it relied on browser redirects in an environment where native apps and mobile web had become the primary commerce channel for many customer segments. And it provided no mechanism for compliance with the regulatory frameworks that would emerge, particularly PSD2 in Europe.

⚠️  The Card Scheme Position on 3DS 1.0 Visa retired support for 3DS 1.0 in October 2022. Mastercard followed with its own sunset timeline. Any organisation still operating on 3DS 1.0 infrastructure is running on an end-of-life protocol that no longer receives scheme support and does not meet current regulatory requirements in the EU and UK.

The Core Differences: A Technical and Commercial Comparison

Dimension	3DS 1.0	EMV 3DS 2.x
Authentication model	Password-based. Customer enters a static credential at a redirected bank page.	Risk-based. ACS evaluates 100+ data elements. Customer interaction only when warranted.
Data elements shared with issuer	Fewer than 15 core fields. Limited context for the ACS decision.	Over 100 standardised data elements covering device, transaction, merchant, and behavioural context.
Frictionless rate	Not available. All enrolled transactions required customer input.	Typically 90%+ of transactions approved silently with no customer interaction.
Mobile support	Browser redirect only. No native mobile app support.	Native 3DS SDK for iOS and Android. Designed for in-app payment environments.
Specification governance	Proprietary per card scheme. Visa’s Verified by Visa, Mastercard’s SecureCode.	Standardised EMVCo specification. Consistent across all participating card schemes.
Regulatory compliance	Not aligned with PSD2 SCA requirements.	Designed to meet PSD2 Strong Customer Authentication exemptions and requirements.
Liability shift scope	Available on challenge-authenticated transactions.	Applies to both frictionless and challenge-authenticated transactions.
Scheme support status	Retired by Visa (Oct 2022) and Mastercard.	Current standard. EMV 2.1, 2.2, and 2.3 all in active deployment.

The 100+ Data Element Advantage

The most important technical change in EMV 3DS 2.x is the volume and richness of contextual data passed to the issuer ACS with each authentication request. Where 3DS 1.0 gave issuers very little to work with, 3DS 2.x sends a comprehensive profile of the transaction context.

This data package includes device characteristics and fingerprinting data, browser environment details, cardholder transaction history with the merchant (where available), shipping and billing address comparison, merchant category and risk profile, transaction amount relative to historical norms, and IP geolocation signals. The ACS uses this package to build a confidence score for the transaction. The richer the data, the more often the ACS can make a confident frictionless approval.

📊  What This Means for Issuers For card-issuing banks, the shift from 3DS 1.0 to EMV 3DS 2.x is transformational. Instead of relying on a static password which the ACS cannot meaningfully score — the issuer’s fraud model receives a full contextual picture of the transaction. This is why frictionless rates above 90 percent are achievable. The ACS has enough signal to be confident without asking the customer to prove themselves.

Native Mobile Support: Why It Matters

3DS 1.0 was built for a browser world. Its authentication mechanism relied on an HTML redirect — a pattern that works acceptably in a desktop browser but produces a degraded experience in a mobile web view and is simply incompatible with native application environments.

EMV 3DS 2.x introduced a native SDK component that integrates directly into merchant iOS and Android applications. The SDK handles device data collection, authentication flow management, and the challenge interface natively within the app — no redirects, no external browser launches, no disrupted UX. For enterprise merchants with significant mobile transaction volumes, this is not a marginal improvement. It is the difference between 3DS being deployable and not.

PSD2 SCA Compliance: The Regulatory Dimension

In the European Union and United Kingdom, the Payment Services Directive 2 (PSD2) introduced Strong Customer Authentication (SCA) requirements for remote electronic payments. SCA requires that authentication uses at least two of three factors: something the customer knows (a PIN or password), something the customer has (a phone or hardware token), and something the customer is (a biometric).

3DS 1.0 — relying on a single static password — does not meet this definition. EMV 3DS 2.x was specifically designed to enable SCA compliance for card-not-present transactions. When an ACS presents a challenge using an OTP sent to the cardholder’s registered mobile device (possession) combined with a PIN (knowledge), or a biometric (inherence), this satisfies the SCA multi-factor requirement. Frictionless flows are permitted where the transaction falls under an SCA exemption — typically the transaction risk analysis (TRA) exemption under EBA RTS Article 18.

For any financial institution or payment service provider operating in the EU or UK, operating 3DS 1.0 infrastructure means operating outside regulatory requirements. The migration to EMV 3DS 2.x is not optional in these markets.

EMV 3DS Version Timeline: 2.1, 2.2, and 2.3

Version	Key Additions	Current Status
EMV 3DS 2.1	First full specification release. Frictionless and challenge flows. Browser and native SDK. Core data elements.	Visa retired support in September 2024. Mastercard migration requirements in progress.
EMV 3DS 2.2	Decoupled authentication support. Additional SCA exemption mechanisms. Enhanced RBA data. Improved merchant-initiated transaction handling.	Current deployment standard. Required by major card schemes.
EMV 3DS 2.3	Improved decoupled authentication flows. Enhanced biometric data elements. SDK improvements for app-based authentication. White-label challenge UX flexibility.	Actively being adopted. Key for mobile-first and recurring payment environments.

What the Migration from 3DS 1.0 to EMV 3DS 2.x Involves

For organisations with legacy 3DS 1.0 infrastructure, the migration to EMV 3DS 2.x is a platform replacement, not a configuration change. The key workstreams in a typical migration include the following.

• Replacing or upgrading the Access Control Server (ACS) to a certified EMV 3DS 2.x ACS that supports the full data element schema
• Deploying or replacing the 3DS Server component on the merchant or gateway side with an EMV 3DS 2.x certified server
• Integrating the native 3DS SDK into mobile applications if in-app authentication is required
• Updating fraud scoring models within the ACS to leverage the expanded 100+ element data package
• Testing across all targeted card scheme Directory Servers (Visa, Mastercard, Amex, JCB)
• Configuring SCA exemption logic for EU/UK deployments if applicable

🏢  GPayments EMV 3DS Infrastructure GPayments delivers certified ACS and 3DS Server components to financial institutions and payment processors across Australia, Asia-Pacific, and globally. Our implementations support EMV 3DS 2.1, 2.2, and 2.3 across Visa, Mastercard, Amex, and JCB schemes. We work with issuing banks, acquirers, payment platforms and organisations that need the full 3DS protocol stack, not just a merchant plugin.

Frequently Asked Questions

Q: What is the main difference between 3DS 1.0 and 3DS 2.0? A: 3DS 1.0 used a static password redirect that created friction on every transaction. EMV 3DS 2.0 (and 2.x) uses risk-based authentication with 100+ data elements, enabling frictionless approval for over 90 percent of transactions with no customer interaction, native mobile support, and PSD2 SCA compliance.

Q: Is 3DS 1.0 still supported by Visa and Mastercard? A: No. Visa retired support for 3DS 1.0 in October 2022. Mastercard has also mandated migration to EMV 3DS 2.x. Financial institutions and merchants still operating on 3DS 1.0 are running on an unsupported protocol that does not meet current regulatory or scheme requirements.

Q: What does EMV stand for in EMV 3DS? A: EMV stands for Europay, Mastercard, and Visa — the three founding organisations of EMVCo, the body that manages the EMV specifications including chip card standards and the 3DS authentication protocol. EMVCo now includes American Express, Discover, JCB, and UnionPay as co-governing members.

Q: What are the versions of EMV 3DS? A: The EMV 3DS specification versions in deployment are 2.1, 2.2, and 2.3. Version 2.1 support has been retired by Visa. Version 2.2 is the current required standard. Version 2.3 introduces improved decoupled authentication and enhanced mobile SDK capabilities and is being actively adopted.

Q: Does EMV 3DS 2.x meet PSD2 SCA requirements? A: Yes. EMV 3DS 2.x was designed to enable PSD2 Strong Customer Authentication compliance for remote card transactions. When an ACS presents a multi-factor challenge, this satisfies the SCA requirement. Frictionless flows can apply under SCA exemptions, including the transaction risk analysis (TRA) exemption under EBA RTS Article 18.

Q: What is decoupled authentication in EMV 3DS? A: Decoupled authentication is a feature introduced in EMV 3DS 2.2 that allows the authentication challenge to be presented and completed separately from the transaction flow — for example, via a banking app notification sent after the payment is initiated. It is particularly relevant for recurring payments and scenarios where the customer is not actively present at the point of transaction.