pause-not-delete rule at day 14, pre-dunning expiry warnings, and the weekly recovery scorecard — with the worked math of why 20-40% of subscription churn is never a customer decision at all.">
HIVE80lab — Ops notes

Failed Payment Recovery (Dunning) Sequence for Subscriptions & Retainers

A card expires at midnight, a charge fails at 2 a.m., and by the time anyone looks, a paying customer has been silent for five weeks and gone. Nobody decided to churn. The card did. This is involuntary churn, and in healthy subscription businesses it is 20–40% of all churn — revenue lost to a recoverable payment event, not a product decision. The fix is embarrassingly mechanical: a dunning sequence, four pre-written touches over two weeks, triggered by a failed charge, run by one named owner, measured in one weekly number. Customers are happy to fix a failed payment — it protects their service. The only teams that lose this revenue are the teams that never asked, or asked once, angrily, three weeks late. (Voluntary churn — the customer deciding, not the card failing — has its own tool: the cancellation flow with save offers.)

1. The math first — why this is the cheapest revenue you will ever recover

Take a small, boring subscription: 200 customers at $29/month = $5,800 MRR. Card failure rates run 5–10% of charges per month (expiry, insufficient funds at that moment, reissued cards after fraud, bank declines). At 8%, sixteen charges fail every month — $464 of recurring revenue standing at a cliff edge. With no dunning sequence, roughly half of those customers quietly cancel and never come back: about $2,700 a year walking out the door for no product reason. With a four-touch sequence, small teams routinely recover 50–70% of failed charges — the difference is two hours of email writing, once, ever. Compare that to winning the same $2,700 from new sales at higher prices, which costs marketing, or from collections on invoices, which costs awkwardness. Failed payments are the only revenue leak where the customer wants you to collect — they bought the thing; they are waiting for a working link.

2. The sequence — four touches, fourteen days, tone falling not rising

Where invoice collection escalates (see the collection ladder), dunning de-escalates: every touch assumes the customer is fine and the card is not. The emails are service notices, not marketing — plain subject lines like "Your payment failed — update your card" outperform clever ones, because the customer is not deciding whether to open; they are deciding whether it is spam.

Touch 1 — Day 0, instantly, on the failure event. Speed is the whole game: recovery rates fall off a cliff after 48 hours because the failed charge leaves working memory. One short email: what failed, how much, and one button — "Update payment method" — that lands on a prefilled, logged-in card-update page. Never make a customer log in, find billing, and hunt; every extra click is a recovered customer lost. One attempt to re-charge the card can ride along, but the link is the star.

Touch 2 — Day 3, the expiry explanation. Second email, second automatic retry. This one names the likeliest cause: "Cards on file expire; if yours rolled over, the new expiry takes ten seconds to enter." Reassure: no service interruption yet, nothing owed, no penalty. The tone is a pharmacy refill reminder, not a collections letter.

Touch 3 — Day 7, the alternatives email. Third retry, plus the escape hatches: "If the card keeps declining, you can switch to PayPal, pay by bank transfer, or have us send a manual invoice." A meaningful share of unresponsive failures are simply a card the bank has blocked for recurring use — give those customers a door that is not the same card. This touch also adds gentle stakes: "your next billing date will pause if we can't collect."

Touch 4 — Day 12–14, the pause notice. The account pauses (read-only, downgrade to free, whatever fits the product), with the promise that makes re-entry frictionless: "nothing is deleted; update your card any time and everything comes back exactly as it was." What never happens on this schedule: silent deletion at day 14 with no notice, and angry demand emails with late fees. Pausing a customer who intends to stay is how you lose them to a competitor's onboarding flow.

3. Retry logic — when the machine tries the card again

Every touch above rides with a re-charge attempt, and when you retry matters as much as how often. Spread three or four retries across different times of day and different days — a card declined on the 1st for insufficient funds often succeeds on the 5th (payday) or at 8 a.m. rather than 2 a.m. Never retry more than about four times in the sequence: hammering a card triggers bank-side fraud flags that get your merchant account flagged, not just the charge declined. If your processor offers automatic card updater (Visa/Mastercard Account Updater) or smart retry timing, switch them on — they silently fix expiry and reissued-card failures before the customer ever sees an email. If you bill on a simple processor without those features, the manual schedule above is not a compromise; it is the product. And keep one hard rule from the payment outage playbook: when failures spike across many customers at once, it is your gateway, not their wallets — pause the sequence, fix the rail, then re-run.

4. Prevention — pre-dunning beats dunning

The best failed payment is the one that never happens. Expiry tracking: if you store card metadata, run a monthly query for cards expiring within 45 days and send one cheerful email — "your card on file expires next month; update it now and notice nothing" — that pre-empts the entire failure. Annual plans: every annual conversion removes eleven monthly billing events, and billing events are where revenue dies; a modest annual discount pays for itself in failures avoided. Billing-date hygiene: charge on the weekday morning your customer's bank is awake, not 2 a.m. Sunday. One-click fix everywhere: put the update-card link in the app's billing page, the footer of every receipt, and the signature of support replies — the customer who self-serves costs zero touches. This is the same prevention-over-collection philosophy as the deposit clause in the invoice ladder, pointed at cards instead of invoices.

5. The weekly scorecard — five numbers, one owner, fifteen minutes

Dunning dies as an unowned automation that silently stops working (a broken link, an expired email template, a processor webhook nobody re-tested). So it gets a weekly read, folded into the month-end close as its weekly conscience: (1) charges failed this week, count and dollars; (2) recovered this week, count and dollars, ideally split by which touch did it; (3) recovery rate, recovered ÷ failed, tracked as a trend — a falling rate with flat failure volume means the emails broke, not the cards; (4) days-to-recover, median — creeping upward means touch 1 is slow or landing in spam; (5) paused-not-deleted count — the customers sitting in grace who need exactly one more nudge or one human email. One person owns the read, the way one person owns the runway line. Both are fifteen-minute habits that decide whether quiet leaks become loud shortfalls.

A worked example: 90 retainers, nine failed charges, 78% recovered

A five-person studio bills 90 monthly retainers at $350 — $31,500 MRR, half by card, half by invoice. Their first failure month (visible only after they started the failed-charges pass at close): nine card failures, $3,150. Before dunning, their habit was one email, eventually, and about a third ever recovered. They built the four-touch sequence in one Tuesday afternoon — four emails, prefilled update links, retries on day 0/3/7/10, pause at day 14 with no deletion. Next month: nine failures again (it is always roughly the rate, not a crisis), but touch 1 alone recovered four within 24 hours; the expiry-explainer email caught two reissued cards; the alternatives email converted one stubborn decline to bank transfer; one went to the pause state and returned at day 19 with a new card. Seven of nine back — 78%, $2,450/month recovered, maybe six emails of work. The studio's decision-log entry: "we were losing a retainer a month and calling it normal." The other two failures? One was a customer who had quietly decided to leave and used the failed card as the exit — the pause notice got a real answer, which is worth knowing even when the answer is goodbye.

Related pages

  • Retainer Renewal Checklist — the chosen-side twin: dunning recovers the money the client meant to pay; the 60-day renewal runway catches the revenue the client was quietly deciding to stop paying — memo first, call second, signature-only week.

    • Failed payments are not churn; they are a customer asking you, silently, to make it easy to keep paying. Fire the instant email with a one-click update link, ride every touch with a spaced retry, offer a second rail by day 7, pause instead of delete at day 14, and read five numbers every week. Small teams that do this stop donating 20–40% of their churn to expired cards — and the fix was four emails, written once, on an afternoon.

    Dunning saves involuntary churn; the voluntary kind is prevented upstream, with the customer onboarding first-30-days checklist that gets new accounts to first value before they drift. And the funnel feeds dunning: the more trials you convert to cards on file, the more revenue rides on the retries working.

    This playbook is part of the Hive80 Lab ops kit line — field-tested, instantly downloadable: