Strong Customer Authentication: Why European Subscribers Fail Payments a Different Way

Most involuntary churn playbooks — ours included — assume the same failure shape everywhere: a card expires, a bank blocks the charge, funds are short, retry on a better day. That model holds up fine for US subscribers. It breaks down the moment a meaningful share of your base is billing from an EEA or UK card, because those payments run through a second gate that has nothing to do with the card itself: Strong Customer Authentication. A card can be valid, funded, and un-flagged for fraud, and still fail a renewal for a reason your dunning stack was never built to catch.

That study is a pre-rollout forecast, not a live number — it's worth citing because it's the reason Stripe and every other processor built exemption logic in the first place, not because friction still costs Europe €57 billion a year today. The exemptions worked, mostly. The problem for subscription businesses is narrower and more specific: they work reliably for renewals that look exactly like what was authorized, and less reliably the moment a subscription event changes the shape of the charge.

What SCA actually requires, mechanically

PSD2 requires two-factor authentication on card-not-present transactions where the card was issued in the EEA or UK. In a Stripe integration, this surfaces as a 3D Secure challenge — the customer gets bounced to their bank's app or sent an SMS code before the charge completes. Miss that step and the PaymentIntent sits in requires_action instead of moving to succeeded. If nobody completes the challenge, it eventually fails outright.

That's a manageable, even useful, piece of friction at checkout — the customer is there, their banking app is one tap away, and the added step measurably cuts fraud. The regulatory data backs that up: the joint EBA-ECB reporting on payment fraud found card-not-present fraud fell after SCA's introduction, and issuer-reported fraudulent transaction volume dropped by roughly half in the months immediately following the rollout.

None of that is the part that causes involuntary churn, though. The checkout-time challenge is a one-time cost a customer pays once, consciously, while they're sitting in front of the screen. The churn problem lives entirely off-session, on the renewals nobody's watching.

Why renewals mostly sail through — until they don't

Regulators anticipated that requiring a fresh two-factor check on every subscription renewal would be unworkable, so the rules carve out an exemption for merchant-initiated transactions (MIT). Once a customer completes one properly-authenticated payment — a customer-initiated transaction, or CIT — the mandate for that relationship is established. Every subsequent charge that Stripe initiates on your behalf, on the agreed schedule and for a consistent amount, can skip the authentication step entirely and just run.

This is why the overwhelming majority of EEA and UK subscription renewals process silently, exactly like a US card. It's also why most SaaS teams running Stripe in Europe never think about SCA past their checkout page — the exemption does its job invisibly on renewal after renewal.

The exemption depends on the new charge resembling the one that was originally authorized closely enough that an issuer will honor it without asking questions. Push a charge outside that resemblance and some issuers fall back to requesting authentication — and since the charge is off-session, there's no customer present to provide it. The charge fails with requires_action or the decline reason authentication_required, which most teams lump in with generic card_declined failures and route into the same retry queue that works for insufficient funds. It won't work here. Retrying an authentication-required charge without a way for the customer to authenticate produces the identical failure every time, no matter how many times or how cleverly you time it.

We've written before about the mechanics of card account updater fixing the "card itself is stale" category before a charge ever fires, and about dunning and retry logic for the "temporarily can't collect" category. Authentication failures sit in a third category those tools don't touch, because the card is fine — the problem is that nobody's phone is in reach of the bank's push notification.

The specific moments where the exemption breaks

Four subscription events are the recurring culprits, because each one changes the shape of the off-session charge in a way that can trip an issuer's risk model:

• Trial-to-paid conversion. The card was authorized during signup for a $0 or token verification charge, then the real charge fires days or weeks later at a completely different amount. Some issuers treat that gap as enough of a mismatch to ask for fresh authentication — right at the exact moment there's no customer present, because they signed up for a trial and forgot about it.
• Mid-cycle plan upgrades and price increases. A charge that jumps meaningfully above the customer's usual amount looks less like a routine MIT and more like a new transaction to some risk models, even though it was entirely merchant-initiated.
• Subscriptions resuming after a pause. A long enough gap since the last successful charge can push a resumed subscription outside the pattern an issuer expects from an ongoing MIT relationship.
• The first charge after a failed-payment recovery window closes. If dunning retries span several weeks, the eventual successful charge can land far enough from the original billing date that it no longer reads as routine.

Every one of these is a moment your trial-to-paid conversion funnel or your involuntary churn recovery sequence is already touching for other reasons — which is exactly why an authentication failure buried inside those flows is easy to misdiagnose as a normal decline and route into a fix that can't work.

Getting exemptions to actually stick

Stripe requests exemptions automatically through its own risk engine and passes low-value and transaction-risk-analysis (TRA) exemptions to issuers where eligible — you don't have to build exemption logic yourself. The EU's regulatory technical standards set the TRA ceiling on a sliding scale tied to the payment service provider's own fraud rate: a provider with a fraud rate under 0.13% can get exemptions up to €100, under 0.06% up to €250, and under 0.01% up to €500. Separately, a flat low-value exemption covers individual charges under €30, capped at five consecutive exempted transactions or €100 cumulative before a fresh authentication is required. None of this is something you configure per-charge — it's the mechanism running underneath Stripe's default handling — but it explains why a €19/month plan sails through cleanly while a €450 annual renewal is far more likely to hit a challenge.

The one thing worth doing on your end: make sure the card is captured correctly for future off-session use in the first place. When you create the initial SetupIntent or PaymentIntent for a new EEA or UK subscriber, set usage: 'off_session' explicitly, even if the first charge is $0 for a trial. That tells Stripe to run 3D Secure at setup and record a proper mandate, which is what gives every later MIT charge the best possible shot at the exemption. Skipping this step and treating the initial charge as a normal on-session payment is the single most common reason teams see authentication failures show up disproportionately on their trial cohorts months later.

For the failures that do need a fresh authentication despite all that, the fix is a targeted recovery email or in-app prompt linking to Stripe's hosted invoice page or customer portal — somewhere the customer can complete a 3DS challenge in one click — rather than the generic "update your payment method" copy your dunning sequence sends for a plain card decline. Sending an authentication-required customer to a card-update form asks them to solve a problem they don't have.

Segmenting your involuntary churn by geography

If EEA or UK subscribers make up a meaningful share of your base, it's worth pulling authentication_required as its own line in your failed-payment reporting rather than folding it into a blended involuntary churn number. A US-heavy SaaS business and a Europe-heavy one will have involuntary churn rates that look similar on the surface and are driven by almost entirely different mechanisms underneath — one needs better card-expiry coverage, the other needs a correctly-configured off-session mandate and a recovery flow that actually matches the failure.

This sits upstream of anything a cancellation flow can fix. A subscriber who hits an SCA failure on renewal didn't decide to leave — they may not even know their access lapsed until they try to log in, at which point they land somewhere between a churn event and a support ticket, confused about whether they cancelled at all. Getting the authentication mechanics right so that renewal doesn't fail in the first place is worth more than any save offer CancelFlow could show them afterward, because there's no cancellation decision to intervene on — just a payment that needed a tap on a phone nobody handed them. You can model how much a percentage point of recovered involuntary churn is worth to your business with our churn calculator, using your EEA/UK subscriber count as the segment to isolate.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.