Recovering failed subscription payments (dunning): how to keep customers whose card didn't go through

You have a customer who has paid you month after month, is happy, and has no intention of leaving. And yet, this month their subscription shows up as "cancelled." Not because they decided to quit, but because their card expired, they were short on funds for a day, or their bank blocked the recurring charge. This is called involuntary churn, and it's by far the most frustrating way to lose revenue: you lose people who actually wanted to stay.

The good news is that almost all of these payments can be recovered if you have a dunning system. It's not magic, and it doesn't mean spamming customers with emails. It means retrying the payment at the right moments, communicating clearly and politely, and making it dead simple to update a card. In this article I'll show you exactly how it works and what to ask your developer for.

Involuntary vs. voluntary churn: don't confuse the two

Before anything else, separate two completely different things.

Voluntary churn = the customer genuinely wants to leave: they hit "cancel," they no longer need the service. The fix here is your product and offer, not dunning.

Involuntary churn = the customer would have stayed, but the payment failed for technical reasons. This is where dunning belongs.

Typical reasons a recurring charge fails:

• expired card (the most common; cards get reissued every few years)
• insufficient funds on the billing day
• the bank flagged the transaction as suspicious and blocked it
• an online-transaction limit or a deactivated card
• SCA/3-D Secure authentication required and not completed

If you treat both the same way, you either annoy people who were leaving anyway, or you walk away from revenue that was perfectly recoverable. The first decision is to measure these two losses separately, otherwise you don't know what you're fixing.

Smart retries: when you retry matters more than how many times

The key to dunning isn't retrying ten times in a row; it's retrying at the moments when the payment is likely to go through.

Two principles that make the difference:

• Space attempts across days, not hours. If the reason is "insufficient funds," it makes sense to retry a few days later, once the customer has been paid, not ten minutes on.
• Distinguish soft declines from hard ones. A soft decline (insufficient funds, a temporary limit) is worth retrying. A hard decline (closed card, no such account, permanently blocked transaction) won't be fixed by a retry, only by asking for a new card.

Most serious platforms (Stripe, for example) offer automatic retries with logic based on the decline type. The point is not to leave the settings on "default" without knowing what they do: a four-attempt schedule stretched over two to three weeks best catches reissued cards and paychecks that landed in the meantime.

Card updater and SCA: recover payments without the customer lifting a finger

The most elegant recovery is the one where the customer never even learns there was a problem.

A card updater (account updater) is a service from the Visa/Mastercard networks: when a customer's card is reissued, the new number and expiry date reach your processor automatically. The payment goes through without anyone re-entering anything. It's worth turning on, because it silently solves the most common cause of failure: the expired card.

Then there's SCA / 3-D Secure. In the EU, recurring payments must be set up correctly so they don't require authentication on every charge. If the first payment is saved properly (with a mandate for future charges), the following charges usually go through without the bank asking for a code. When it's set up badly, the bank demands authentication every month, the customer doesn't even see the prompt, and the payment fails. It's a technical setting, but it's the difference between a stable subscription and one that "drops" at random.

The dunning sequence: emails and messages that actually recover

When automatic retries fail, communication with the customer kicks in. Tone matters enormously here: it's not a demand letter, it's a favor you're doing them.

A sequence that works:

• Day 0, on the first failure: a calm email, "we couldn't process your payment, this happens all the time, you can update your card here." One clear button to the payment page.
• On the second or third failed attempt: a short reminder, maybe also an SMS or WhatsApp if you have consent, since those get read faster than email.
• Before suspension: a message that says clearly what happens and when ("access stops on date X if the payment doesn't go through").

A few common-sense rules:

• Make updating the card take under a minute, with no complicated login.
• Don't blame the customer and don't use a debt-collection tone.
• Offer a grace period with active access, don't cut the service off immediately. A customer who keeps access resolves the payment far more often than one who's already locked out.

What to ask for when you build or outsource the system

Dunning isn't a plugin you tick on; it's a small system: retry logic, processor integration, message templates, a card-update page, and a dashboard where you see what got recovered.

A short checklist to ask from whoever builds your platform:

• automatic retries with soft/hard decline differentiation
• account updater enabled at the processor
• SCA correctly configured for recurring payments
• an email/SMS sequence with a human tone and a single call-to-action
• a simple, mobile-friendly card reactivation page
• a separate report for involuntary vs. voluntary churn

At MPO Web Studio we build exactly these flows for subscription websites and apps, we deliver remotely across the whole country, and we show you a pre-built demo first, so you can see how it looks before you pay for anything. If you have a subscription that's "losing" customers to failed payments, message us on WhatsApp and we'll look together at where the revenue is leaking and what can be recovered without rebuilding everything.