SCA Exemptions for Recurring Payments: Why Your EU Renewals Break (and the MIT Fix)

The 30-second answer

Under Europe's SCA rules, subscription renewals are exempt from per-charge authentication IF they're processed as merchant-initiated transactions referencing the mandate the customer authenticated at signup. When your EU renewals randomly hang in 'requires action' or fail outright, it's usually because the mandate reference is missing or the customer's bank declined the exemption. You can't control the banks — but you can control the first part, and you need an email flow for the second.

I covered the basics of 3DS killing subscriptions in another post. This one is the next level down: the exemption system that's supposed to prevent that, and why it sometimes doesn't.

SCA in one paragraph (so the exemptions make sense)

Strong Customer Authentication is the EU/UK rule (from PSD2) that says online card payments need two-factor proof from the customer — the 3D Secure challenge you know and tolerate. It applies to payments where the customer is present and initiating. The entire subscription economy runs on payments where the customer is NOT present, so PSD2 carved out exemptions. The one that matters to you: merchant-initiated transactions, MIT.

MIT: the exemption your whole business runs on

The deal SCA strikes with subscriptions works like this. At signup, the customer is present, so that first payment (or a zero-auth setup) goes through 3DS and creates an authenticated agreement — a mandate. Every renewal after that is merchant-initiated: your system triggers it off-session, referencing the original mandate, and it's out of SCA scope. No challenge, no friction, customer barely notices.

When this works, it's beautiful. When it breaks, it breaks in two places:

• •Break 1 — the mandate reference never got set. If the initial setup didn't establish (or your integration didn't store) the mandate, every renewal goes out without the MIT reference. The bank sees an unauthenticated off-session charge with no history attached and treats it as suspicious. Authentication gets demanded from a customer who isn't around to provide it.
• •Break 2 — the bank declines the exemption. Here's the annoying truth: exemption means 'allowed to skip SCA,' not 'guaranteed to skip it.' Issuers can and do ignore MIT flags and demand authentication anyway, especially for larger amounts or after card reissues. Some banks are just aggressive about it.

Stripe handles break 1 for you if your subscriptions are set up normally — it stores and sends mandate data automatically on its Billing subscriptions. If you're hand-rolling off-session PaymentIntents, this reference is your job, and missing it is the classic self-inflicted SCA wound.

Grandfathered mandates and card reissues

Two wrinkles that bite established subscription businesses. First, grandfathering: mandates established before SCA enforcement can keep processing as MIT without ever having gone through 3DS. If your subscriptions predate the rules, those renewals may be running on legacy agreements — mostly fine, occasionally questioned by an issuer who decides the old mandate looks thin.

Second, card reissues. When the customer's bank replaces their card, the new details arrive via the card updater — but some issuers treat the reissued card as a fresh start for exemption purposes and demand re-authentication on the next MIT charge. From your side it looks random: a customer with two years of clean renewals suddenly hits requires_action out of nowhere. It's not random. It's the new card resetting the bank's trust state, and your authentication-request email is the fix.

How Stripe handles this (and where your job starts)

If you're on Stripe Billing with standard subscriptions, Stripe automatically flags renewals as merchant-initiated and includes the mandate reference — break 1 is handled for you. Where your job starts is break 2: the banks that demand authentication anyway. Stripe exposes these as payments stuck in requires_action and declines with the authentication_required code, and it can send its own authentication-request emails. Whether you use Stripe's emails or your own, someone must own this flow. The failure mode to avoid is the silent one: charges sitting in requires_action for days while nobody notices, revenue stuck in limbo, customer clueless. Put an alert on it. Even a dumb one — a daily email listing stuck payments beats discovering them in a churn report.

The other exemptions (and why you mostly can't use them)

• •Low-value: payments under €30 can be exempt — but only until cumulative limits kick in (several consecutive transactions or about €100 since the customer's last authentication). Fine for a €9/mo plan, useless the moment a bank decides the counter reset is due.
• •Low-risk (TRA): acquirers with very low fraud rates can exempt transactions at certain thresholds. Not something a small SaaS controls directly.
• •Corporate payments: B2B card payments through secure corporate processes can be exempt. Narrow lane, rarely applies to standard SaaS checkout.
• •MOTO, anonymous prepaid, one-leg-out: mail-order/telephone, gift cards, and transactions where one party is outside the EEA. If you're a US company charging EU customers, you may have noticed SCA applies inconsistently — that's the one-leg-out mess, and you should not build your billing reliability on it.

For a subscription business, the hierarchy is simple: MIT is the load-bearing exemption. Everything else is decoration.

What 'stripe sca delay' actually looks like in your dashboard

If you're here because renewals are hanging: the pattern is a payment stuck in requires_action. The bank demanded authentication, the customer isn't present, and the charge sits there waiting. Stripe can email the customer a hosted authentication link, which recovers some of these — but each one is a conversion leak dressed as a technicality. Every day a charge sits in requires_action is a day the customer's invoice is unpaid and their access is in limbo.

The playbook

• •Verify mandate flow end-to-end. Sign up a test subscription with an EU test card, let it renew, and confirm renewals process as MIT without challenges. Do this once and you'll sleep better.
• •Watch for authentication_required declines. That's the code for 'bank ignored your exemption.' It's not a dead card and not insufficient funds — it's a demand for the customer to show up.
• •Have an email for exactly this. 'Your bank needs you to confirm this payment — tap here, takes 20 seconds.' Short, specific, one link. This email recovers charges that no retry logic can touch, because the blocker is a human step only the customer can perform.
• •Don't hammer retries on requires_action. Retrying an authentication-blocked charge without the customer completing the challenge gets you nothing but repeated failures. Fix the auth, not the timing.

"SCA didn't break subscription billing — it added a door. MIT is the key you were given at signup. The failures happen when you lose the key or the bank pretends not to recognize it."

This is one of those areas where the difference between recovered and lost revenue is whether anyone noticed the specific failure mode. An authentication-required decline needs a completely different response than insufficient funds — and treating them the same is how EU revenue quietly evaporates. It's a big part of why StayPaid's recovery flows branch on the actual decline reason instead of blasting the same retry sequence at everything: a bank demanding 3DS gets the 20-second confirm link email, automatically, from your address. But tooling or not, go check your requires_action charges right now. I bet there's money sitting in there.