SCA and 3D Secure Explained: Why European Card Payments Fail (2026)

Strong Customer Authentication (SCA) is the European Union’s PSD2 rule requiring that an electronic payment be verified with two independent factors — something the customer knows, has, and is — rather than a card number and CVC alone, and 3D Secure (specifically its current version, 3DS2) is the technical protocol banks and card networks actually use to run that verification at checkout. For a one-time purchase, this mostly shows up as a brief redirect to a bank app or a one-time code. For a subscription business, it is a much bigger problem: a renewal charge fires automatically, with nobody sitting at a keyboard to complete a challenge, and if the issuer decides this particular attempt needs fresh authentication, the charge simply fails with a decline code most subscription platforms are not built to handle — authentication_required. This is not a card problem, a funds problem, or a fraud problem; it is an authentication problem, and treating it like an ordinary decline is exactly why so many otherwise-healthy European subscriptions quietly lapse. This guide covers what PSD2 and SCA actually require, how 3D Secure implements that requirement technically, why recurring billing breaks the model in a way one-time checkout does not, what exemptions exist and how far they really reach, and what a subscription business should actually build — in its decline handling and its dunning sequence — to stop losing these customers.

We build recovery software that reads decline codes across five processors for a living, and authentication_required is one of the most consistently mishandled codes we see, because it looks, from a distance, like just another failed charge. It is not. Everything about how you retry it, email about it, and route the customer is different from a normal hard or soft decline, and most off-the-shelf dunning setups were never built with a fourth category in mind — they assume every failure is either “bad card” or “no funds.” For a subscription business with any meaningful share of European customers, that blind spot has a real, if hard-to-quantify, cost.

What Strong Customer Authentication (SCA) actually requires under PSD2

SCA requires that an electronic payment be authenticated using at least two independent factors drawn from three distinct categories, rather than relying on a single piece of card data. The three categories are: knowledge (something only the customer knows, like a PIN or banking password), possession (something only the customer has, like their phone receiving a push notification or a hardware token), and inherence (something the customer physically is, like a fingerprint or face scan on their device). A card number plus a CVC — the classic “card-not-present” checkout — is one factor at best (arguably not even a real “factor” in the SCA sense at all); it does not, on its own, satisfy the requirement.

This requirement comes from the EU’s revised Payment Services Directive, commonly called PSD2, with the specific technical detail of what counts as compliant authentication set out in regulatory technical standards written by the European Banking Authority (EBA). PSD2 governs payment service providers — banks, card issuers, acquirers — operating within the European Economic Area (EEA), which is the reason SCA is fundamentally a European rule rather than a global card-network standard. It rolled out across the EEA in stages over several years, with national regulators granting phased extensions to different sectors as issuers, acquirers, and merchants worked through the technical rollout, rather than flipping on for every transaction on a single fixed date.

It is worth being precise that SCA is a requirement on payments, not narrowly on cards — it applies to bank transfers, some wallet payments, and other electronic payment instruments within its scope too. For a subscription business, though, card payments are almost always where this shows up, because recurring billing is overwhelmingly card-based across Stripe, Paddle, Braintree, Chargebee, and Recurly alike.

What 3D Secure (3DS2) is, and how it implements SCA at checkout

3D Secure is the technical protocol card networks and issuers actually use to carry out authentication at the moment of a charge — it is the mechanism, where SCA is the requirement. The current version, 3DS2, is what most EEA-issuing banks now run to satisfy PSD2; an earlier version, 3DS1 (the flow most people picture as an ugly pop-up window asking for a static password under names like Verified by Visa or Mastercard SecureCode), predates PSD2 and was optional, clunky, and widely disliked by merchants and customers alike. 3DS2 was built specifically to be less disruptive, exchanging far more background data between merchant, issuer, and card network so that a much larger share of transactions can be approved without ever bothering the customer at all.

The 3DS2 flow, step by step

1. The customer submits card details at checkout, or a subscription renewal charge is initiated automatically on its billing date.
2. The merchant’s payment processor sends an authentication request through the card network to the card’s issuing bank, carrying whatever transaction and device data 3DS2 supports (amount, merchant identity, device fingerprint, and — critically for recurring billing — whether this transaction claims a recurring or low-value exemption).
3. The issuer’s Access Control Server (ACS) evaluates that data against its own risk model and decides between two paths: a frictionless approval or a challenge.
4. Frictionless path: the issuer approves the authentication silently in the background, using the risk data already exchanged — the customer sees nothing, and the charge proceeds straight to authorization.
5. Challenge path: the issuer decides the transaction needs active proof from the customer — a one-time code, a push notification approved inside the banking app, or a biometric prompt — which is the flow most people actually picture when they hear “3D Secure.”
6. The issuer returns an authentication result to the merchant’s processor, and — if successful — the underlying charge proceeds to normal authorization and settlement.
7. If the customer fails the challenge, never completes it, or (the case this article is about) is not present at all because the charge was an unattended subscription renewal, the charge is declined instead of completing — typically surfaced to the merchant as authentication_required.

Why recurring billing breaks the SCA model in a way one-time checkout does not

A one-time checkout and a subscription renewal look identical to most billing systems — both are “a charge against a saved card” — but they are fundamentally different from an authentication standpoint, and that difference is the entire reason this problem exists. At checkout, a customer is present, on a device, able to tap a push notification or enter a one-time code the instant the issuer asks for one. On a subscription renewal, the charge fires on a schedule, in the background, with nobody watching a screen — which is precisely the scenario 3DS2’s challenge flow was never designed to interrupt gracefully.

PSD2 anticipated this problem directly, which is why the merchant-initiated transaction (MIT) exemption exists at all: if the very first charge on a card — the one placed with the customer actively present at signup — completed SCA successfully, subsequent unattended renewals of the same fixed (or materially unchanged) amount can typically skip authentication going forward. This is the mechanism that keeps the overwhelming majority of subscription renewals working invisibly, month after month, without a repeat challenge. The exemption is not absolute, though, and several realistic situations can knock a renewal back into requiring a fresh challenge it has no way to complete on its own:

• A changed amount. A mid-cycle upgrade, a prorated charge, or a price increase can be treated by an issuer as different enough from the originally authenticated transaction to fall outside the MIT exemption.
• A new card on file. If the customer updated their card — even to a reissued card with the same number after a bank’s security event — the chain of “this specific card already completed SCA once” can break, depending on how the issuer and processor track it.
• Issuer-side risk scoring. Some issuers periodically re-challenge even a long-running recurring relationship if their own fraud model flags something unusual — a new device fingerprint associated with the account, an unusual time of month, or simply a conservative bank that re-authenticates more often than its exemption eligibility strictly requires.
• Conservative or inconsistent implementation. Not every issuer across every EEA country implements the recurring exemption identically — some apply it liberally, some narrowly, and the practical result is that a subscription business with customers across many European banks sees a genuinely mixed pattern rather than one uniform rule.

The net effect is that a subscription business processing European renewals should expect authentication_required to show up as a recurring category of decline — not a rare edge case, and not something that will go away by simply retrying the charge again on a different day the way a insufficient_funds decline might. For the full picture of how this decline code sits alongside other Stripe decline reasons, see our guide to Stripe decline codes explained.

SCA exemptions, and where each one actually applies

PSD2’s regulatory technical standards carve out several categories where SCA can be waived, and understanding the shape of each one — rather than the exact thresholds, which are set at the regulatory level and applied at issuer discretion — is what actually helps you reason about why a given renewal did or did not require a fresh challenge.

None of these exemptions is a switch a subscription business can simply flip on and forget. Each one is ultimately applied — or overridden — by the customer’s own issuing bank, based on that bank’s own risk assessment at the moment of the charge. What a merchant and processor can control is largely limited to signaling the right exemption category correctly (marking a renewal as a recurring MIT, for instance) and then handling gracefully the cases where the issuer challenges it anyway. Trying to design a billing system around “this will never require authentication” is the wrong mental model — the right one is “this will occasionally require authentication, and my dunning sequence needs to handle that gracefully when it does.”

What happens when a renewal gets declined authentication_required

When an issuer decides a renewal charge needs fresh authentication and no customer is present to provide it, the charge fails and the processor surfaces a decline reason that specifically means “authentication needed, not a bad card and not insufficient funds.” On Stripe, this shows up as authentication_required; other processors use their own equivalent language, but the underlying situation is the same across Paddle, Braintree, Chargebee, and Recurly alike — the charge is technically valid, the card is fine, and the only thing standing between the customer and a successful payment is completing a 3D Secure challenge that literally could not happen at the moment the renewal fired.

This is the single most important operational fact about this decline code: a normal retry — even a well-timed one like Stripe Smart Retries would schedule for a soft decline such as insufficient_funds — does nothing here. Smart Retries genuinely helps recover a meaningful share of ordinary failed charges by picking a statistically better day to try again; it has no mechanism to make a customer complete an authentication step they were never asked to complete in the first place. For the deeper mechanics of what Smart Retries does and does not cover, see our guide to Stripe Smart Retries.

In practice, the correct handling looks like this: on the very first authentication_required decline, skip straight to generating a secure, charge-specific link that walks the customer through a fresh 3D Secure challenge for that exact renewal — typically by creating a new payment attempt against the same subscription and having the customer complete authentication for it directly, rather than looping through the same automatic retry logic built for hard and soft declines.

Why SCA meaningfully changes the decline mix for European subscription bases

For a subscription business with customers spread across the EEA, this decline reason is not a rounding error — it is a structural part of the decline mix that simply does not exist for a purely US or non-EEA customer base. A business selling only to US customers will never see authentication_required at any meaningful volume, because PSD2 does not reach US-issued cards; the same product, sold with a meaningful share of EEA customers, will see it show up consistently, month after month, as one of the recurring reasons renewals fail alongside the usual insufficient_funds, expired_card, and do_not_honor categories.

We are deliberately not putting a precise percentage on how much higher EU decline rates run because of SCA — the honest answer is that it varies widely by issuer mix, transaction size, how well a given processor signals the recurring exemption, and how conservatively individual European banks apply their own risk scoring. What is safe to say, and useful operationally, is the qualitative shape of it: a subscription business billing across many different European banks should expect a meaningfully higher share of its EU renewal declines to be authentication-related than its US renewal declines, and that share is essentially unrelated to how healthy the underlying card or customer relationship actually is.

Why this decline needs its own dunning branch, not a generic "your card failed" email

The single biggest mistake we see subscription businesses make with this decline reason is folding it into the same email template used for every other failure. An SCA-related decline is not a card problem, and telling the customer to “update your payment method” when their card is perfectly valid creates real confusion — they log in, see a valid card already on file, have nothing to update, and give up. Worse, if they do re-enter the same card number out of confusion, the renewal often just fails the exact same way again, since re-entering identical card details does nothing to satisfy the authentication step the issuer is actually waiting on.

Notice the second version explicitly reassures the customer their card is fine, sets the correct expectation (a bank app prompt or a texted code, not a card form), and links into a charge-specific re-authentication step rather than a generic “update your billing” page. That combination — correct framing plus the correct link — is what actually recovers this decline reason; a technically accurate email that still points to the wrong page converts barely better than a fully generic one. For the fuller mechanics of building a decline-aware sequence like this across every category, not just this one, see our dunning email sequence setup guide and what is dunning.

Practical guidance: what a subscription business should actually build

Handling authentication_required well is less about a single big engineering project and more about a handful of specific, prioritized changes to how declines get routed and communicated. Some of these are quick wins; a couple are genuinely bigger undertakings.

• Separate the decline categories. At minimum, split declines into hard (bad card, needs a new number), soft (temporary, worth a smarter retry), and authentication (needs a fresh 3DS challenge, not a retry) — three genuinely different problems that a single retry-then-email workflow cannot serve well simultaneously.
• Do not burn retry attempts on authentication declines. A processor-level retry, however well-timed, cannot satisfy an authentication requirement — skip straight to the re-authentication path instead of waiting out a retry window that was never going to help.
• Write the email to match the actual problem. Reassure the customer their card is fine, explain the extra step in plain language, and link directly into the specific charge’s authentication flow rather than a generic billing-settings page.
• Confirm your processor is signaling the recurring exemption correctly. A misconfigured integration that fails to mark legitimate renewals as merchant-initiated transactions will trigger far more unnecessary challenges than the underlying regulation actually requires.
• Watch the category over time, not just once. Because exemption eligibility sits partly with each customer’s own issuing bank, the share of renewals hitting authentication_required can shift as your European customer base grows or as banks adjust their own risk models — worth checking periodically rather than assuming it is a solved, static problem.

Starter ($29/month) runs a 4-email AI sequence on Days 1, 3, 7, and 14, and its free Lost Revenue Finder scans your last 90 days of payment history so you can see how many failures fall into this category before committing to anything. Pro ($79/month) adds automatic hard/soft/authentication decline routing — so an SCA-related decline gets its own re-authentication branch by default, not a generic card-update email — writes the sequence in 8 languages, adds SMS recovery, an in-app cancel-flow with retention offers, win-back campaigns on Day 3, 14, and 30, a full 12-month historical scan, a weekly digest, and priority support. Both plans include a 14-day free trial with no credit card required and a 30-day money-back guarantee — full details on the Revova pricing page.

For a broader look at sizing failed-payment losses across every decline category, not just SCA-related ones, see how much revenue you are losing to failed payments.

For Stripe’s own documentation on Strong Customer Authentication and how it applies across Stripe products, see Stripe’s Strong Customer Authentication documentation, and for Stripe’s reference on how 3D Secure works technically, see Stripe’s documentation on 3D Secure.

Frequently asked questions