Set up Stripe dunning without losing the customer
How Stripe dunning works: Smart Retries against a custom schedule, the emails Stripe sends for you, the grace period you own, and the recovery step the Dashboard never shows.
Stripe gives you the mechanics of dunning and leaves the policy to you. Retries, decline handling, and the recovery emails all exist. What Stripe cannot decide for you is how long a customer keeps access, and what you do when the card works but the customer does not come back.
This page is the setup order that avoids the common failure: a retry schedule tuned for the payment processor rather than for the person who has to notice the email and find a new card.
Pick the retry behaviour before the copy
A subscription invoice that fails goes through a retry process. Stripe can pick the timing with Smart Retries, which uses the signals it has about when a charge is likely to succeed, or you can define a fixed schedule.
The trade-off is honest either way: a longer window recovers more money and keeps more accounts in a broken state for longer. Decide this deliberately, because every later step — the email wording, the grace period, the downgrade — is written against whatever window you chose.
Decide what Stripe sends and what you send
Stripe can send its own failed-payment and card-update emails, and for most teams that is the right start: it is configured in the Dashboard, it links to a Stripe-hosted page where the customer can update the card, and it does not require you to build anything.
The reason to write your own message is context. If your product already tells a customer that their work is saved and waiting, the recovery email can say the same thing. If you take over the email, take over the whole job: send it yourself, on your own domain, and keep the update-card link working.
The grace period is your policy, not a default
Access during a failed payment is a product decision. Cut access immediately and you punish a customer whose bank declined a legitimate charge. Keep access forever and the subscription quietly becomes free.
Whatever you choose, state it in the email and in the app. A lockout that arrives without warning is the moment an involuntary churn turns into a voluntary one, and the customer's reason changes from a bank error to your product.
Measure recovery where the customer answers
A recovered invoice is a billing event, not a saved customer. To see which is which, ask at the moment it happens. The MorePaying widget runs on your own checkout and pricing pages, so the question "what stopped you from finishing payment?" lands while the failure is still on screen — and the answer is attached to the blocked amount, not to a support inbox.
That is also how the dunning loop closes: when you change the retry window or the email and ship it through the CLI with a release SHA, the paid result after that release is measured against the same baseline.
FAQ
Where do I configure Stripe dunning?
In the Stripe Dashboard under the billing settings for subscriptions and invoices, where the retry schedule and the recovery emails live. The exact menu names move between Dashboard versions, so follow the retry settings rather than a screenshot.
Does Stripe send dunning emails automatically?
Stripe can send failed-payment and card-update emails, and you can change or disable them. If you disable them, you own the notice and the card-update path.
Should dunning emails come from my domain?
If you want the reply, the deliverability, and the branding to be yours, yes. The Stripe-hosted version is the fastest correct option when you do not want to run email yourself.