How to build a dunning process that recovers revenue

Most failed payments are accidental, which makes them recoverable. Here is how to build a dunning process that wins that revenue back.

Free and open-source under AGPLv3 — self-host today, or talk to us about cloud.

June 3, 2026 · 6 min read · The GetPaidHQ team

In a subscription business, a large share of cancellations are accidental — a card expired or a charge was declined, and nobody fixed it. That is involuntary churn, and because the customer still wants the product, it is some of the most recoverable revenue you have. The system that recovers it is dunning.

Start before the payment fails

The cheapest failed payment is the one that never happens. Pre-dunning warns customers ahead of time — most usefully when a card is about to expire — so they can update it before a charge is ever declined. A small amount of proactive messaging here removes a surprising share of failures downstream.

Retry intelligently, not on a fixed timer

When a charge does fail, *how* you retry matters more than *how often*. Blindly retrying on a fixed schedule wastes attempts and can irritate customers. Smart retries adapt to the decline reason and customer history: an "insufficient funds" decline is worth retrying around a likely payday; a "card expired" decline will keep failing until the customer acts, so the priority there is the reminder, not the retry. Retrying on a backup processor can also recover charges a single gateway keeps declining.

Send a reminder sequence that helps, not nags

Alongside the retries, a short sequence of messages prompts the customer to fix their payment method. Each dunning letter should state which payment failed and for what, why keeping the account active matters to them, and a single clear action. A typical sequence is three to four messages over one to three weeks, escalating gently in urgency before the subscription is paused.

Make fixing it frictionless

  • Use secure payment-update links that let a customer fix their card in seconds — no login, no support ticket.
  • Keep the message specific and human; most failures are accidents, not refusals.
  • Retry automatically after they update, so there is nothing else for them to do.

Measure what recovery is worth

Track recovery rate, revenue saved, and where customers drop off, then tune the levers — retry timing, message wording and cadence, and the friction of the update flow. Small improvements compound, because you are recovering revenue you have already earned.

Or let it run itself

You do not have to build all of this by hand. GetPaidHQ ships with built-in dunning — adaptive retries, pre-dunning, cross-processor retries, configurable reminder campaigns, and payment-update links — running on infrastructure you control.

Billing for the rest of us.

GetPaidHQ is open-source, self-hostable billing on any processor. Run it free, or talk to us about managed Cloud.

Free and open-source under AGPLv3 — self-host today, or talk to us about cloud.