The email is optimizing the wrong variable
Nearly every piece of dunning advice available focuses on the email: subject line urgency, send cadence, how many attempts before giving up. That's optimizing a variable that doesn't determine the outcome. Whether a failed payment is recoverable is decided the moment the card network returns a decline code — before a single email has been drafted, let alone sent.
A soft decline — insufficient funds, a temporary processing error, a bank flagging the transaction for manual review — describes a payment method that's still fundamentally valid and likely to succeed on retry, especially timed near when the customer's account typically has funds. A hard decline — a stolen or reported card, a closed account, an invalid card number — describes a payment method that is not coming back, and no amount of persuasive copy changes that.
Treating both categories identically, which is what most billing systems and dunning tools do by default, means wasting email sends and customer goodwill on unrecoverable hard declines while under-optimizing the timing that actually matters for soft ones.
Retry timing matched to decline type
The lever that's actually available is retry timing, and it should differ by decline category rather than following one fixed schedule.
Soft declines: retry near billing cycles, not on a fixed daily schedule
Insufficient-funds declines recover at meaningfully higher rates when the retry lands 3-5 days out, closer to typical payroll or billing cycles, rather than the next day when the same underlying cash-flow issue is still present.
Hard declines: skip retries, go straight to a manual ask
Retrying a closed account or a card reported stolen wastes a retry attempt (which processors rate-limit and sometimes penalize for excessive retries) on a transaction that structurally cannot succeed. The correct response is an immediate, direct request for updated payment information, not another automated attempt.
Processing-error declines deserve an immediate retry
Unlike insufficient funds, a processing error is often transient — an immediate or near-immediate retry frequently succeeds, and waiting days for this category specifically just delays an easy recovery.
The recovery mechanism nobody emails about
The highest-leverage part of failed-payment recovery isn't an email at all. Visa's Account Updater and Mastercard's Automatic Billing Updater are services that card issuers and networks run specifically to keep merchants' stored card data current — when a customer's card expires or is reissued with a new number, these services can silently update the stored payment method on file, with no email, no customer action, and no interruption to the subscription.
Why this beats even well-timed email
An email asks the customer to take an action, which has a response rate below 100% no matter how well it's written. An account-updater refresh requires nothing from the customer at all — it's the only failed-payment recovery mechanism that doesn't depend on customer behavior.
It doesn't cover every case
Account updaters work for expired or reissued cards with the same underlying account — they don't help with insufficient funds, closed accounts, or a customer who switched banks entirely. It's a real lever, not a complete replacement for retry logic and dunning emails.
Enrollment isn't automatic for every payment processor or billing platform — check specifically whether your subscription billing system is enrolled in card network account-updater services before assuming failed-card churn is being addressed at all.
What this changes about measuring dunning performance
Most dunning reporting tracks one blended recovery rate across every failed payment, which hides exactly the distinction that matters. A business that's recovering 90% of soft declines but 0% of hard declines and a business recovering 45% of both can show an identical blended number while having completely different problems and completely different available fixes.
Segmenting recovery rate by decline type — and separately tracking what account-updater services are recovering silently, with no email involved at all — gives a far more honest picture of where the actual leak is, and stops a team from endlessly A/B testing email copy against a category of decline that copy was never going to fix.
The broader point connects to the same instinct that runs through good measurement generally: the metric you're optimizing needs to actually correspond to the mechanism producing the outcome. Optimizing dunning emails while ignoring decline codes is optimizing the visible, editable part of a process while ignoring the part that actually decides it.
Terms used in this piece
We do this for a living
If you'd rather not build this yourself, these are the services where it lives.