Failed payments: designing dunning that recovers revenue
When a subscription payment fails, the customer usually doesn't know. The card expired, the monthly limit hit, the bank flagged a charge as unusual. None of that is a cancellation; it's a card problem. Yet plenty of apps treat it as one: the payment fails at 04:00, a webhook downgrades the account by 04:01, and a paying customer opens their laptop to a locked-out workspace.
Most of that revenue comes back if the recovery flow is designed. This is the design, separate from the webhook plumbing: how the money state machine works is one article, what the customer experiences when a charge fails is this one.
Retries: a schedule, not a loop
Decide the retry plan up front. A common shape is three attempts over two weeks, for example day 0, day 3, and day 8, matching the pay cycles that most often fix a card problem by itself. Hammering a dead card daily adds fees on some providers and achieves nothing; trying once and giving up silently loses customers who would have fixed it by Friday.
If you're on Stripe, its smart retries already do a version of this. The part you still own is everything after the retries: what the user sees, and when access actually changes.
The grace period is a policy, not a mood
The single worst dunning pattern is "payment failed, account locked, email sent, figure it out". The customer may be on a boat for two weeks. Locking access the same day converts a recoverable card problem into a churned account with a bad story attached to it.
Instead, write the grace policy down and build it as explicit state:
- Full access until period end. The customer paid for the interval they're in. Cutting access inside a paid period is taking money without service.
- A defined past-due window after the period, typically two weeks, with the retries running inside it.
- A visible end state: downgrade to a free plan with data intact, or a flagged read-only mode. Data stays; cancellation is not deletion.
Every person answering support should be able to say in one sentence what happens seven days into a failed payment. If they can't, the policy isn't finished.
Dunning email and the in-app banner
The most effective channel is the one the user is already looking at: a banner in the app, on the account page at minimum, stating the card failed, the date access changes, and a link straight to the payment form. One click, no hunting through settings.
Email fills the rest:
- Subject lines carry the product name and the problem: "AcmeCRM: your payment failed, update your card". Vague "Action required" from a no-reply address goes to spam or to the mental equivalent.
- The body is three sentences: what happened, what happens next and when, one button to the billing page.
- Three or four messages across the grace window, then stop. Ten dunning emails read as harassment, and there is nothing in the ninth one that wasn't in the first.
- Send from a monitored address. People reply to these, some with questions, some with a new card number.
Recovery should be one click
When the customer does act, the flow matters. Log in, update the card, charge immediately, clear the flags, restore full access, confirm in email. If the subscription resumes silently or takes a day to propagate through your local state, you've just taught a paying customer to distrust your billing.
Also design the path you hope not to use: when the window ends with no card on file, downgrade deliberately. Keep the data, keep the audit trail, and leave the door open for a win-back email later. A lapsed free account with intact data comes back sometimes; a deleted workspace never does.
Watch the recovery rate
Track recovery per channel: how many failed subscriptions come back after the first retry, after email, after the banner, after none of those. Healthy dunning keeps involuntary churn to a small single-digit share of revenue. A sudden spike in failures is rarely customers changing their minds; it's usually a processor change, a card network pattern, or a bug you shipped.