3D Secure 2.0 vs. 3D Secure 1.0: What's Changing for Merchants
A detailed comparative analysis between 3DS1 and 3DS2 for developers and CTOs. Discover the impact on UX, conversion, SCA exemptions, and migration.
10 min read

Table of contents
- Payment Security Meets the User Experience Challenge
- Overall Comparison Table: 3DS1 vs. 3DS2
- Detailed Analysis: 3D Secure 1.0, the Aging Precursor
- Detailed Analysis: 3D Secure 2.0, the Era of Invisible Authentication
- Recommended Use Cases: Which Solution for Which Profile?
- Final Verdict: Why Migrating to 3DS2 is Both Inevitable and Beneficial
Payment Security Meets the User Experience Challenge
In the online payment ecosystem, balancing fraud prevention with a seamless customer journey is a constant challenge. Merchants, especially in high-risk sectors, are continually juggling the need to build trust with the risk of a customer abandoning their cart due to an overly restrictive verification step. The 3D Secure (3DS) protocol was born out of this context.
Launched in the early 2000s, its first version (3DS1) laid the groundwork for strong cardholder authentication, aiming to reduce "Card Not Present" (CNP) fraud. The principle was simple: redirect the buyer to their bank's page to enter a password. While this method proved somewhat effective by transferring fraud liability to the issuing bank (the liability shift), it quickly revealed its limitations: high abandonment rates, a degraded user experience (the infamous pop-up or redirect), and near-incompatibility with the m-commerce explosion.
With the implementation of the second Payment Services Directive (PSD2) in Europe, a simple update was not enough. A complete overhaul was needed. Thus, 3D Secure 2.0 (3DS2) was born, designed to meet Strong Customer Authentication (SCA) requirements while making the purchasing journey as transparent as possible.
For developers, CTOs, and technical architects, understanding the nuances between these two versions is not just an academic exercise; it's a strategic imperative that directly impacts conversion rates, regulatory compliance, and the overall performance of a payment platform. This article aims to provide a detailed technical comparison to guide you through this crucial transition.
Overall Comparison Table: 3DS1 vs. 3DS2
| Technical Criterion | 3D Secure 1.0 | 3D Secure 2.0 |
|---|---|---|
| User Experience (UX) | Always Creates Friction (redirection/iframe) | Primarily frictionless (no visible friction) |
| Authentication Flow | Systematic Challenge | Risk-Based (Risk-Based Authentication) |
| Data Exchanged | Minimal (approx. 10 data points) | Enriched (over 150 potential data points) |
| Mobile Integration | Non-native (via WebView) | Native (via dedicated mobile SDKs) |
| SCA Exemption Handling | Non-existent | Built-in (TRA, low-value transactions, etc.) |
| Authentication Methods (Challenge) | Mainly static password | Biometrics, OTP, in-app validation |
| Estimated Impact on Conversion | Negative (up to a 25% drop in conversion) | Positive (up to a 70% reduction in abandonment) |
| PSD2 Compliance | Not Compliant | The reference standard |
Detailed Analysis: 3D Secure 1.0, the Aging Precursor
How It Works
The 3DS1 architecture is based on a three-domain model (hence the name "3D"): the acquirer domain (merchant's bank), the issuer domain (customer's bank), and the interoperability domain that connects them. In practice, when a customer finalizes a purchase, the merchant's plugin queries the 3DS server.
If the card is enrolled, the user is redirected to an authentication page from their own bank (the ACS - Access Control Server), often in a pop-up or iframe. They must then prove their identity, most often with a static password or a code received via SMS. Once this step is validated, they are redirected back to the merchant's site.
Strengths (in its historical context)
It's important to recognize that 3DS1 was a major step forward in its time. Its main advantage, still relevant today, is the liability shift. In the event of a fraudulent transaction validated by 3DS1, it is the issuing bank that assumes the financial loss, not the merchant. For many merchants, this guarantee was enough to justify the degraded UX.
Weaknesses and Technical Limitations
The shortcomings of 3DS1 have become major obstacles to conversion:
- Invasive User Experience: The redirect creates a sharp break in the shopping journey. Pop-ups are often blocked by browsers, creating confusion and frustration. The design of the authentication pages, which is not controlled by the merchant, is rarely optimized.
A study by the MRC (Merchant Risk Council) estimated that friction-filled authentication processes like 3DS1 could lead to cart abandonment rates ranging from 10% to 25% depending on the industry.
- Not Adapted for Mobile: 3DS1 was designed for the desktop web. On mobile, integration is done via WebViews, which offer a poor, non-native, and often poorly formatted experience. This is especially problematic as m-commerce now accounts for over 50% of online sales.
- Lack of Contextual Data: The 3DS1 protocol transmits only a minimum of transactional information. The decision to authenticate is based on simplistic rules, without a complete view of the purchase context.
- Systematic Challenge: The lack of data forces a near-systematic challenge. Almost every transaction becomes a potential obstacle, even for the most loyal customers.
Detailed Analysis: 3D Secure 2.0, the Era of Invisible Authentication
The Evolution Driven by Data and Experience
3D Secure 2.0 is not just an update; it's a philosophical overhaul. Its goal is to make strong authentication not only more secure but also invisible for the vast majority of legitimate transactions. The secret? The massive exchange of contextual data between the merchant and the cardholder's bank.
Strengths and Major Innovations
The advantages of 3DS2 directly address the shortcomings of its predecessor:
-
The "Frictionless" Flow: This is the revolution of 3DS2. By transmitting over 150 data points (compared to about ten for 3DS1), the issuing bank's ACS can perform a real-time risk analysis (Risk-Based Authentication). If the risk score is low (known customer, trusted device, consistent amount, etc.), the transaction is passively validated, with no action required from the user. It's estimated that over 90% of transactions can go through this frictionless flow.
The data transmitted includes:
- Device information (Device ID, IP, language)
- Transactional data (amount, currency, transaction type)
- Customer history (account age, purchase history)
- Billing and shipping addresses
- Native and Mobile Experience: 3DS2 was designed to be "mobile-first". Specific SDKs for iOS and Android allow the authentication process (including the challenge, if necessary) to be integrated directly within the application. No more WebViews: the experience is fluid, secure, and consistent with the app's design.
- Smart SCA Exemption Management: PSD2 provides for cases where strong authentication is not mandatory. 3DS2 allows these to be managed natively. The merchant can flag a transaction as potentially exempt (e.g., low-value transaction < €30, Transaction Risk Analysis - TRA, trusted beneficiaries, etc.). This is a major lever for optimizing conversion on eligible payments.
- Modern Challenge Methods: If a challenge is unavoidable (the "challenge flow"), 3DS2 supports methods that are much smoother and more secure than a simple password. The user can authenticate directly in their banking app via biometrics (fingerprint, facial recognition) or a push notification, making the step quick and intuitive.
Technical Considerations
The main "challenge" of 3DS2 lies in its initial integration complexity. Correctly collecting and transmitting all the recommended data points to maximize the chances of a frictionless flow requires a careful implementation. The quality of the data sent is directly correlated with the protocol's performance. A poor integration can nullify the benefits of 3DS2. This is precisely where choosing a payment gateway like Bridge Pay, which abstracts this complexity, becomes a strategic move.
Recommended Use Cases: Which Solution for Which Profile?
When (and Why) to Use 3D Secure 1.0?
Let's be clear: for any business targeting the European Economic Area, 3D Secure 1.0 is obsolete. It does not comply with PSD2 requirements, and using it will result in a very high declinal rate from issuing banks. Its only residual use case might be for very specific non-EU markets where 3DS2 is not yet fully deployed and where the liability shift remains the sole decision criterion, at the expense of conversion. For a modern business, this is no longer a viable option.
The Default Standard: 3D Secure 2.0
3DS2 is the universal solution to adopt for any merchant processing online card payments. Its application is particularly critical for:
- High-volume e-commerce merchants: The frictionless flow and exemption management are direct growth levers, allowing thousands of transactions to be secured daily without impacting the customer experience.
- High-risk industries: For businesses in gaming, travel, or digital services, the rich data of 3DS2 is an invaluable asset. It helps justify a transaction's legitimacy to acquiring and issuing banks, drastically reducing false positives (legitimate payments being declined) and reinforcing ecosystem trust. A good 3DS2 implementation is a strong signal of professionalism.
- Subscription models (SaaS, VOD...): 3DS2 facilitates the management of recurring payments through initial authentication mechanisms that then allow for Merchant-Initiated Transactions (MITs) without systematic SCA.
- Mobile applications: For any native app selling goods or services, the 3DS2 SDKs are the only way to offer an integrated and secure payment experience without redirecting users out of the app.
Final Verdict: Why Migrating to 3DS2 is Both Inevitable and Beneficial
The comparison is stark: 3D Secure 1.0 belongs to the past. It will be remembered as the protocol that introduced strong authentication, but its technical limitations now make it an obstacle to conversion. 3D Secure 2.0 is not just a regulatory obligation dictated by PSD2; it is a major strategic opportunity for merchants. It finally reconciles enhanced security with an exceptional user experience.
Adopting 3DS2, via the frictionless flow, turns a regulatory constraint into a competitive advantage by reducing cart abandonment and increasing the trust of customers and banks. The challenge for technical teams is no longer "should we migrate?" but "how do we migrate effectively?". The key to success lies in the ability to collect and transmit a maximum amount of high-quality data to maximize the passive approval of transactions.
At Bridge Pay, we understand that the integration complexity of 3DS2 can be a barrier, especially for companies in high-risk sectors where every transaction counts. That's why our payment gateway was designed to simplify this process. Our API and mobile SDKs handle the collection and formatting of the required data, allowing you to enjoy all the benefits of 3DS2 without having to manage all the underlying complexity. We actively optimize authentication requests to maximize acceptance rates and frictionless flows.
The transition to 3D Secure 2.0 is a full-fledged technical project, but its benefits in terms of conversion, security, and compliance are considerable. It is a direct investment in your business's performance.
To discover how our 3D Secure 2.0 implementation can simplify your compliance and boost your performance, consult our technical documentation or contact our experts for a personalized demo.


