What is dunning, and why does it decide your churn?
Dunning is the whole path after a failed payment: retries, notices, grace periods, and what happens to access. Here is what to configure, and the part it still misses.
Dunning is the sequence a subscription business runs after a payment fails. It is not one email and it is not a setting you switch on once. It is the retry schedule, the notices, the grace period, the access decision, and the final state the account ends up in.
Almost every dunning setup is judged by a single number: recovered revenue. That number is real, but it hides the interesting part. A card can be recharged successfully and the customer can still be gone next month, because the reason the card failed was never the reason they were leaving.
What dunning actually includes
Teams usually mean one of four things when they say dunning, and the four are configured in different places.
- Retry logic — when a failed charge is attempted again, how many times, and on what schedule.
- Customer notices — the email or in-app message that says the payment did not go through and what to do about it.
- Grace period — how long access continues while the payment is unresolved.
- Terminal state — what happens to the account when recovery fails: downgrade, pause, or deletion.
Why failed payments leak money quietly
Failed payments are boring, which is exactly why they leak. Nobody files a bug for a declined card, and the customer rarely tells you either. They meant to keep paying, so the loss never appears as a cancellation reason in your own reporting.
A card that expires is the common case. A card that gets declined because of a bank rule is the frustrating one, because the customer did nothing wrong and often does not know anything happened. Both end in the same place if the retry schedule and the card-update path are weak.
The part most dunning configuration misses
Dunning answers one question: did we get the money? It does not answer the question underneath it: was the payment the reason this customer was about to leave anyway? A recovered charge and a saved customer are two different outcomes, and only one of them shows up in your billing dashboard.
That is the gap MorePaying is built for. Instead of guessing why a person left, the one-question card asks at the pricing exit and at the moment a payment fails, then joins the answer to the amount that was blocked. Dunning tells you the money came back. The answer tells you whether the next failed payment will recover the same customer.
A dunning checklist for a Stripe subscription
Most of this is configuration rather than code, and the order matters: the retry schedule buys time, the notice is what the customer acts on, and the grace period decides whether they still care by the time the card works again.
- Turn on automatic retries and pick a schedule that spans the length of a normal pay cycle.
- Make the failed-payment email carry one clear action: update the card. Not a status report.
- Keep access during the grace window, and say when it ends. Surprise lockouts convert a recoverable payment into a cancellation.
- Track recovery separately from new signups, or a good dunning month will look like a good growth month.
- Record why the customer said they were leaving at that moment, not only whether the retry cleared.
FAQ
Is dunning only for subscriptions?
Any recurring charge has a dunning path, which includes invoices and annual renewals. One-off payments have a failed-payment problem but no subscription to protect.
How many retries should a dunning schedule use?
Enough to cover the window in which a customer would notice and fix a card, and no more. Very long schedules recover marginally more money and annoy the customers who were going to leave anyway.
What is the difference between dunning and collections?
Dunning tries to keep the customer. Collections tries to collect the debt. If a subscription business starts describing its retry emails as collections, the customer has usually already left.