3D Secure and SCA: the failed payments dunning can't fix

Most failed-payment advice assumes the same story: the card expired, the balance was short, the bank declined. Retry sensibly, email the customer, recover some of it. That story covers the majority of failures and dunning handles it well.

There's a category it doesn't cover. Some renewals fail because the customer's bank wanted them to authenticate the payment, and on a subscription renewal there is nobody sitting at the checkout to do it. No card problem, no funding problem, just a request for a human that arrived when no human was present.

What SCA and 3D Secure actually are

Strong Customer Authentication is a requirement under European regulation (PSD2) that many electronic payments involving European cardholders be verified with two independent factors, typically something the customer knows and something they hold. 3D Secure is the protocol card networks use to carry out that check, the step where a bank app or a one-time code appears mid-checkout.

For a one-off purchase this is unremarkable. The customer is at the keyboard, the challenge appears, they approve it, the payment completes. For a recurring charge running on a schedule days or weeks later, there is no session, no browser, and no customer. If the bank issues a challenge at that moment, there is nothing to respond to it.

Why the exemption doesn't always hold

Recurring payments have a route around this. When a customer first subscribes, that initial payment can be authenticated and set up as a merchant-initiated transaction, which establishes a mandate letting subsequent charges run without a fresh challenge. Done properly, renewals are exempt and never see 3D Secure at all.

The exemption depends on things that quietly break. It relies on the original authentication having been captured and stored correctly, on the charges being flagged as merchant-initiated rather than customer-initiated, and on the issuing bank honoring the exemption, which they are not obliged to do in every case. A card replaced by the issuer, a subscription migrated between processors, a plan change that creates a new mandate, or a bank applying its own risk rules can all put a renewal back into challenge territory.

Why it looks like nothing in your dashboard

This is the part that makes it worth knowing about. An authentication failure does not present as a dramatic decline. It surfaces as a charge that requires action, or as a decline code that reads like a generic issuer refusal, and it lands in the same bucket as every other failed renewal.

So the standard response kicks in and does nothing useful. Retrying an authentication failure produces another authentication failure, because nothing about the situation has changed. A dunning email asking the customer to check their card is close to useless, since their card is fine. The customer, if they read it at all, sees a message that doesn't match their reality and ignores it. Meanwhile the retries burn down your schedule and the subscription eventually lapses.

Run a free 90-day audit of your failed payments

How to tell if this is happening to you

• Look for failures that repeat identically across every retry attempt, with no change in the response. A funding problem often clears on a later attempt; an authentication problem does not.
• Check whether your failures cluster among customers with European card issuers. SCA applies to European cardholders, so a UK or EU-heavy base has more exposure than a purely US one.
• Look at what your processor reports for the charge status. A charge sitting in a state that requires customer action is telling you directly that authentication is outstanding, not that money is missing.
• Check whether failures spiked after a migration, a pricing change, or a billing-logic rewrite. Those are the moments mandates get lost.

What actually helps

The fixes here are structural rather than tactical, which is why dunning alone doesn't reach them.

• Make sure the first payment authenticates and the mandate is stored. This is the single highest-leverage thing, because a correctly established mandate is what makes every later renewal exempt.
• Flag recurring charges as merchant-initiated. If renewals are submitted as though the customer is present, you are inviting a challenge nobody can answer.
• Preserve the mandate across changes. Plan upgrades, processor migrations, and card updates are all places the original authentication can be silently dropped.
• Send a different message for these customers. The useful email is not "your payment failed, please update your card" but "your bank needs you to confirm this payment," with a link that opens a session where the customer can actually complete the challenge.
• Stop retrying blind. If the failure needs authentication, additional automated attempts cannot succeed and only consume your retry window.

Where this sits in the bigger picture

Authentication failures are usually a minority of failed renewals. Expired cards and insufficient funds still dominate, and a well-run dunning sequence remains the highest-return thing most subscription businesses can set up.

But this slice is worth separating precisely because the standard playbook cannot touch it. Every retry is wasted, every generic email is ignored, and the customer never learns what was actually being asked of them. Recovering these renewals means recognising them as a different problem and responding differently, rather than pushing them through the same funnel and concluding the customer churned.

Recoupe exists to recover what Stripe leaves behind, and part of that is being honest about which failures are recoverable by better follow-up and which need a fix further upstream. Knowing the difference is what stops you emailing someone four times about a card that was never the problem.

See where your recoverable revenue is