What breaks when merchants rely on outdated 3D Secure for Strong Customer Authentication?

Why This Matters for Security Teams

When merchants keep older 3D Secure implementations in place, the problem is not just a weaker authentication screen. The payment flow often becomes harder to complete, harder to optimise, and harder to govern because the protocol cannot support the data exchange and decisioning that modern strong customer authentication expects. That creates friction at the point of conversion and reduces the merchant’s ability to steer customers into the most seamless path.

For security and payments teams, the practical impact is that SCA turns from a managed control into an unpredictable user hurdle. Older flows tend to expose more browser dependency, more inconsistent issuer behaviour, and less reliable use of exemption logic. That matters because merchants then lose both conversion and control, while issuers and acquirers get less context to make risk-based decisions. The result is often a control that exists on paper but performs poorly in production.

Modern SCA is supposed to balance security and customer experience, not force a choice between them. Outdated 3D Secure breaks that balance by increasing friction where the checkout is already most sensitive. In practice, many security teams only discover the business impact after abandonment rates rise and support teams start seeing authentication complaints.

How It Works in Practice

3D Secure has evolved from a browser-centric challenge flow into a more flexible authentication layer that can support richer transaction data, better mobile experiences, and issuer decisions that are less dependent on a hard challenge. When merchants stay on an older version, several things tend to break at once: the challenge flow becomes more intrusive, device and transaction data are thinner, and the system has fewer ways to apply exemptions cleanly.

That has direct operational consequences. A merchant may still “have 3DS,” but the implementation may fail to support the behaviours that make SCA usable at scale, such as frictionless approvals where risk is low and step-up only when required. In older deployments, authentication is often too browser-bound for modern app journeys, too rigid for asynchronous payment experiences, and too limited to handle soft declines gracefully. The user then gets pushed into a retry or redirect path that feels like a failure rather than a trust step.

• Older 3DS versions often rely on redirect-heavy browser journeys that perform poorly on mobile and embedded checkout flows.
• Less transaction context reaches the issuer, which can reduce the chance of a frictionless approval.
• Exemption handling becomes harder to operationalise, so merchants either over-challenge customers or underuse legitimate exemptions.
• Soft declines can become operationally messy if the merchant platform cannot recover into a supported step-up flow.

Merchants also need to think about payment orchestration, because the issue is not only the authentication protocol itself but how it interacts with gateways, issuers, and checkout UX. If the implementation is fragmented across markets or acquired through older PSP integrations, the checkout may behave differently by region or device. These controls tend to break down when merchants mix legacy acquirer integrations with modern app and wallet journeys, because the authentication path no longer matches the customer journey.

Common Variations and Edge Cases

Tighter SCA enforcement often increases checkout friction, so merchants have to balance conversion against the security and liability benefits of stronger authentication. The right answer is not always “challenge more,” because that can harm legitimate sales, especially in low-risk, repeat, or mobile-heavy transactions.

One important variation is whether the merchant operates in a card-not-present environment with strong recurring or subscription patterns. In those cases, outdated 3D Secure can be especially damaging because the initial enrolment flow may work, but subsequent transactions may not support the exemption and data-handling model needed to keep renewal payments smooth. Another edge case is multi-market commerce, where issuer expectations and regional SCA rules differ enough that a one-size-fits-all implementation produces inconsistent results.

There is also a distinction between technical support and practical support. A platform may claim 3DS compatibility while still failing on modern mobile SDKs, challenge rendering, soft-decline handling, or telemetry needed for fraud decisioning. That gap is common in older PSP stacks and in merchants that have not revisited their payment journey since SCA became operationally mandatory. The answer breaks down further when merchants treat 3DS as a compliance checkbox instead of a checkout control that must be tuned to transaction risk, channel, and customer context.

Practitioner Guidance

What to prioritise: Treat checkout abandonment, issuer challenge rates, and soft-decline recovery as the core indicators of whether the 3DS implementation is still fit for SCA. If those metrics are worsening, the issue is usually not “customer resistance,” but a flow design problem.

What to verify: Confirm that the payment stack supports modern app and browser journeys, rich transaction data, and reliable exemption handling across your main markets. Also verify that the merchant can recover cleanly from soft declines without forcing customers into repeated authentication loops.

Decision rule: If the current 3DS version forces a redirect-heavy or browser-only path for a meaningful share of transactions, prioritise upgrade work over small UX tweaks. Cosmetic checkout changes rarely fix an authentication flow that is structurally outdated.

Practitioner takeaway: The real test is not whether 3D Secure is enabled, but whether it supports SCA with enough context and flexibility to reduce fraud without turning authentication into a conversion penalty.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on authentication to secure access?
• What breaks when merchants rely only on authentication to approve orders?
• What breaks when merchants rely only on CVV and two-factor authentication to stop friendly fraud?
• What breaks when banks rely only on strong authentication for fraud prevention?