{"id":2623,"date":"2026-02-16T13:26:57","date_gmt":"2026-02-16T03:26:57","guid":{"rendered":"https:\/\/www.gpayments.com\/blog\/?p=2623"},"modified":"2026-03-23T13:04:37","modified_gmt":"2026-03-23T03:04:37","slug":"emv-3ds-2-x-vs-3ds-1-0-what-changed-and-why-it-matters","status":"publish","type":"post","link":"https:\/\/www.gpayments.com\/blog\/article\/emv-3ds-2-x-vs-3ds-1-0-what-changed-and-why-it-matters\/","title":{"rendered":"EMV 3DS 2.x vs 3DS 1.0: What Changed and Why It Matters"},"content":{"rendered":"

March 2026\u00a0 |\u00a0 GPayments Insights\u00a0 |\u00a0 12 min read<\/span><\/em><\/span><\/p>\n

Overview<\/span><\/h2>\n

The most important thing to understand about EMV 3DS 2.x<\/a> 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.<\/span><\/p>\n

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.<\/span><\/p>\n

\"GPayments<\/p>\n

Why 3DS 1.0 Became a Problem<\/strong><\/span><\/h2>\n

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.<\/span><\/p>\n

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<\/a>.<\/span><\/p>\n\n\n\n
\n

\u26a0\ufe0f\u00a0 The Card Scheme Position on 3DS 1.0<\/strong><\/span><\/h3>\n

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.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/h2>\n

<\/h2>\n

<\/h2>\n

<\/h2>\n

The Core Differences: A Technical and Commercial Comparison<\/strong><\/span><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
Dimension<\/strong><\/span><\/td>\n3DS 1.0<\/strong><\/span><\/td>\nEMV 3DS 2.x<\/strong><\/span><\/td>\n<\/tr>\n
Authentication model<\/span><\/td>\nPassword-based. Customer enters a static credential at a redirected bank page.<\/span><\/td>\nRisk-based. ACS evaluates 100+ data elements. Customer interaction only when warranted.<\/span><\/td>\n<\/tr>\n
Data elements shared with issuer<\/span><\/td>\nFewer than 15 core fields. Limited context for the ACS decision.<\/span><\/td>\nOver 100 standardised data elements covering device, transaction, merchant, and behavioural context.<\/span><\/td>\n<\/tr>\n
Frictionless rate<\/span><\/td>\nNot available. All enrolled transactions required customer input.<\/span><\/td>\nTypically 90%+ of transactions approved silently with no customer interaction.<\/span><\/td>\n<\/tr>\n
Mobile support<\/span><\/td>\nBrowser redirect only. No native mobile app support.<\/span><\/td>\nNative 3DS SDK for iOS and Android. Designed for in-app payment environments.<\/span><\/td>\n<\/tr>\n
Specification governance<\/span><\/td>\nProprietary per card scheme. Visa’s Verified by Visa, Mastercard’s SecureCode.<\/span><\/td>\nStandardised EMVCo specification. Consistent across all participating card schemes.<\/span><\/td>\n<\/tr>\n
Regulatory compliance<\/span><\/td>\nNot aligned with PSD2 SCA requirements.<\/span><\/td>\nDesigned to meet PSD2 Strong Customer Authentication exemptions and requirements.<\/span><\/td>\n<\/tr>\n
Liability shift scope<\/span><\/td>\nAvailable on challenge-authenticated transactions.<\/span><\/td>\nApplies to both frictionless and challenge-authenticated transactions.<\/span><\/td>\n<\/tr>\n
Scheme support status<\/span><\/td>\nRetired by Visa (Oct 2022) and Mastercard.<\/span><\/td>\nCurrent standard. EMV 2.1, 2.2, and 2.3 all in active deployment.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/h3>\n

<\/h3>\n

The 100+ Data Element Advantage<\/strong><\/span><\/h3>\n

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<\/a> sends a comprehensive profile of the transaction context.<\/span><\/p>\n

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<\/a> 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.<\/span><\/p>\n\n\n\n
\n

\ud83d\udcca\u00a0 What This Means for Issuers<\/strong><\/span><\/h3>\n

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 \u2014 the issuer’s<\/a> 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.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/h2>\n

Native Mobile Support: Why It Matters<\/strong><\/span><\/h2>\n

3DS 1.0 was built for a browser world. Its authentication mechanism relied on an HTML redirect \u2014 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.<\/span><\/p>\n

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 \u2014 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.<\/span><\/p>\n

PSD2 SCA Compliance: The Regulatory Dimension<\/strong><\/span><\/h3>\n

In the European Union and United Kingdom<\/a>, the Payment Services Directive 2 (PSD2)<\/a> 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).<\/span><\/p>\n

3DS 1.0 \u2014 relying on a single static password \u2014 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 \u2014 typically the transaction risk analysis (TRA) exemption under EBA RTS Article 18.<\/span><\/p>\n

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.<\/span><\/p>\n

EMV 3DS Version Timeline: 2.1, 2.2, and 2.3<\/strong><\/span><\/h2>\n\n\n\n\n\n\n
Version<\/strong><\/span><\/td>\nKey Additions<\/strong><\/span><\/td>\nCurrent Status<\/strong><\/span><\/td>\n<\/tr>\n
EMV 3DS 2.1<\/span><\/strong><\/td>\nFirst full specification release. Frictionless and challenge flows. Browser and native SDK. Core data elements.<\/span><\/td>\nVisa retired support in September 2024. Mastercard migration requirements in progress.<\/span><\/td>\n<\/tr>\n
EMV 3DS 2.2<\/span><\/strong><\/td>\nDecoupled authentication support. Additional SCA exemption mechanisms. Enhanced RBA data. Improved merchant-initiated transaction handling.<\/span><\/td>\nCurrent deployment standard. Required by major card schemes.<\/span><\/td>\n<\/tr>\n
EMV 3DS 2.3<\/span><\/strong><\/td>\nImproved decoupled authentication flows. Enhanced biometric data elements. SDK improvements for app-based authentication. White-label challenge UX flexibility.<\/span><\/td>\nActively being adopted. Key for mobile-first and recurring payment environments.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What the Migration from 3DS 1.0 to EMV 3DS 2.x Involves<\/strong><\/span><\/h2>\n

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.<\/span><\/p>\n

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

    \ud83c\udfe2\u00a0 GPayments EMV 3DS Infrastructure<\/strong><\/span><\/h3>\n

    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.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    <\/h2>\n

    Frequently Asked Questions<\/strong><\/span><\/h2>\n\n\n\n\n\n\n\n\n
    Q: What is the main difference between 3DS 1.0 and 3DS 2.0?<\/strong><\/span><\/p>\n

    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.<\/span><\/td>\n<\/tr>\n

    Q: Is 3DS 1.0 still supported by Visa and Mastercard?<\/strong><\/span><\/p>\n

    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.<\/span><\/td>\n<\/tr>\n

    Q: What does EMV stand for in EMV 3DS?<\/strong><\/span><\/p>\n

    A: EMV stands for Europay, Mastercard, and Visa \u2014 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.<\/span><\/td>\n<\/tr>\n

    Q: What are the versions of EMV 3DS?<\/strong><\/span><\/p>\n

    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.<\/span><\/td>\n<\/tr>\n

    Q: Does EMV 3DS 2.x meet PSD2 SCA requirements?<\/strong><\/span><\/p>\n

    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.<\/span><\/td>\n<\/tr>\n

    Q: What is decoupled authentication in EMV 3DS?<\/strong><\/span><\/p>\n

    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 \u2014 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.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div><\/section>\n","protected":false},"excerpt":{"rendered":"

    EMV 3DS 2.x replaced 3DS 1.0 by shifting from static password authentication to risk-based authentication using more than 100 transaction data elements. The result is that over 90 percent of transactions are now approved frictionlessly without customer interaction.<\/p>\n","protected":false},"author":7,"featured_media":2456,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[2],"tags":[8,13,38,11],"class_list":["post-2623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-3d-secure-2-0","tag-3ds2","tag-access-control-server","tag-cnp-fraud"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/comments?post=2623"}],"version-history":[{"count":15,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2623\/revisions"}],"predecessor-version":[{"id":2650,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2623\/revisions\/2650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/2456"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=2623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=2623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=2623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}