3DS1 hurt conversion. 3DS2 doesn't have to — and when implemented correctly, it often improves it. The merchants still avoiding 3D Secure to protect their conversion rates are making a decision based on a protocol that was retired years ago.

Where the Myth Came From
The myth is not baseless — it just refers to the wrong protocol. 3DS1, the original version of 3D Secure, genuinely did damage conversion. It redirected customers to a separate bank-hosted page mid-checkout, often an unbranded, slow-loading form optimized for desktop rather than mobile. Authentication took 45 to 60 seconds on average. Cart abandonment on 3DS1-enrolled checkout flows ran between 15% and 25%. For merchants who experienced it, the association between 3D Secure and conversion damage was entirely rational.
3DS1 was retired by all major card brands in October 2022. 3DS2 is a fundamentally different protocol — architecturally, commercially, and in terms of what it does to the customer experience when implemented correctly. The merchants still citing 3DS as a conversion killer in 2026 are describing a product that no longer exists.

What Good 3DS2 Implementation Actually Looks Like
The central feature of 3DS2 is risk-based authentication. Rather than challenging every transaction, 3DS2 sends over 100 data elements — device fingerprint, transaction history, behavioral signals, location, merchant information — to the issuing bank in real time. The issuer uses this data to assess risk. If the transaction is low-risk, authentication happens entirely in the background without any customer interaction. The cardholder sees nothing. The transaction proceeds.
This is the frictionless flow — and in a well-configured 3DS2 setup, it handles between 85% and 95% of legitimate transactions. The challenge flow, which requires the customer to authenticate through a one-time password, biometric, or banking app push notification, is reserved for transactions that genuinely warrant additional verification. The challenge occurs within the merchant's checkout environment — not as a redirect — and authentication time has dropped from 45–60 seconds under 3DS1 to under 5 seconds.
The conversion numbers reflect this. A Visa case study documented a 70% decrease in cart abandonment with 3DS2 compared to 3DS1. Japan's April 2025 mandate — where every major merchant was required to implement 3DS — showed that 60% of transactions routed through the frictionless pathway, with an average 93% conversion rate across enrolled merchants. In France, frictionless authentication flows increased 40% in the first half of 2024 as French issuers approved more SCA exemption requests when transactions arrived with richer data. Well-configured 3DS2 with frictionless authentication improves authorization rates by 2–4%, according to Stripe's payment optimization benchmarks.

Where Poor Implementation Still Damages Conversion
The conversion myth persists because poorly implemented 3DS2 genuinely does damage conversion — the myth is directionally correct but points to implementation failure rather than the protocol itself. The distinction matters, because one is fixable and the other is not.
The most common implementation failure is insufficient data enrichment. The frictionless flow depends entirely on the quality of the data sent to the issuer. Merchants sending the minimum required fields — rather than the full range of available signals — give the issuer's risk model less to work with. The result is more transactions unnecessarily flagged for challenge. Challenge flows reduce conversion by 10–18% on average. Every unnecessary challenge is a conversion loss that is directly attributable to implementation quality, not protocol design.
The second failure is mobile. Over half of all online transactions now occur on mobile devices, yet approximately 40% of new 3DS implementations still use browser-based authentication rather than native mobile SDKs. Browser-based authentication on mobile produces poor load times, improperly sized iframes, and redirections out of native apps — all of which cause abandonment. A native mobile SDK implementation with biometric or push-based authentication eliminates these failure points entirely.
European merchants see a 2–3.5% conversion downturn when 3DS is poorly applied. US merchants, where implementation quality has historically been lower, may experience losses up to 15%. These are not inherent costs of 3DS2 — they are the cost of misconfiguration. And around 40% of new implementations contain configuration errors that cause unnecessary challenge flows for low-risk transactions.

The Commercial Case Beyond Conversion
Even if 3DS2 were conversion-neutral — which a well-implemented version effectively is — there are two strong commercial reasons for high-risk merchants to prioritize it.
Liability shift. When a transaction is authenticated through 3DS2 and a fraud chargeback is subsequently filed, the liability shifts from the merchant to the issuing bank. For high-risk merchants where fraud chargebacks are a structural feature of operations, this is commercially significant. It does not eliminate fraud — but it changes who bears the cost of it. The liability shift applies to fraud chargebacks specifically; service-related chargebacks remain the merchant's responsibility regardless of authentication.
VAMP exposure. Under Visa's VAMP framework, TC40 fraud alerts count toward the merchant's combined ratio regardless of whether they result in a formal chargeback. A merchant who is not using 3DS2 effectively — and is therefore accumulating fraud alerts that would otherwise be blocked or shifted — faces a higher VAMP ratio contribution than a merchant whose authentication setup intercepts fraud before it escalates. 3DS2 is not just a compliance mechanism. It is part of the fraud management infrastructure that determines VAMP ratio exposure.
The framing of 3DS2 as a pure compliance cost is therefore doubly wrong: it is wrong about the conversion impact (when implemented correctly), and it is wrong about the commercial value (liability shift and VAMP exposure reduction). The merchants who have rebuilt their thinking around 3DS2 as a conversion and risk management tool, rather than a compliance obstacle, are systematically outperforming those who haven't on both metrics.

What to Check in Your Own Setup
What is your frictionless flow rate? Ask your payment provider for the percentage of transactions going through frictionless versus challenge. A well-configured setup should push the large majority of legitimate transactions through frictionless. If the rate is significantly lower than expected, the data enrichment configuration is the first place to look.
Are you using native mobile SDKs? If your 3DS implementation is browser-based and mobile is a significant share of your transaction volume, this is likely the largest single source of avoidable abandonment in your checkout. Native SDK implementation with biometric or push authentication is the standard for any mobile-significant merchant in 2026.
Are SCA exemptions being applied correctly? Low-value transactions, merchant-initiated transactions, and qualifying transaction risk analysis exemptions should all be applied automatically. If they are not, authentication friction is being added to transactions that do not legally require it.
Is soft decline handling working? When SCA is missing and an issuer returns a soft decline, the checkout should automatically retry with 3DS2 authentication. If your implementation fails silently on soft declines, transactions are being lost rather than recovered.

3D Secure stopped being a conversion problem when 3DS1 was retired. What remains is an implementation problem — and implementation problems are solvable. The merchants who treat 3DS2 as a tool to be optimized, rather than a tax to be minimized, are the ones getting both the conversion and the commercial benefits it is designed to deliver.
MMG provides specialist acquiring for high-risk merchants across EU markets. If you want to talk through your 3DS2 setup, your authentication configuration, or how it connects to your VAMP exposure, we're glad to help.