Dunning

Dunning is the process of collecting a payment that failed before the customer's subscription lapses. The word comes from "dun", a verb that means to demand payment of a debt. In a subscription business, dunning means retrying the card, asking the customer to fix it, and setting a deadline after which you stop trying. Most failed renewals aren't customers refusing to pay. They are expired cards, low balances and issuer blocks, so a working dunning setup recovers revenue every month.

The dunning process in Stripe

Stripe Billing has no single "dunning" switch. Its revenue recovery settings together make up your dunning process:

• Retries. Smart Retries or a custom schedule tries the invoice again. Stripe's recommended default is 8 tries within 2 weeks.
• Customer emails. With "Send emails when card payments fail" turned on, Stripe emails the customer after each failed payment with a link to update their payment method. Expiring card emails go out a month before a saved default card expires.
• Automatic card updates. Card networks can send Stripe new card details when a card is reissued, which prevents some failures. Coverage is wide in the US and varies elsewhere.
• The end state. When retries run out, the subscription is canceled, marked unpaid or left past_due, depending on your settings.

The events follow the process. invoice.payment_failed fires on the first failure and on each failed retry, and the invoice's attempt_count goes up each time. customer.subscription.updated fires as the status moves to past_due. Then either invoice.paid fires when a retry works, or customer.subscription.deleted fires if the subscription is canceled.

A subscription's first payment works differently. If it fails, the subscription stays incomplete, and the customer has 23 hours to pay before it becomes incomplete_expired. That is a checkout problem more than a dunning one.

Why dunning matters

Every subscription that ends because a card failed is involuntary churn, revenue lost from a customer who never decided to leave. Dunning is all that stands between a routine decline and a cancellation, and your retry window sets the time you have. On Stripe's default policy, that is about two weeks from the first failure.

Automation has gaps. Stripe won't retry a hard decline such as lost_card or stolen_card until the customer adds a new payment method. An email sent to a billing inbox nobody reads recovers nothing. A failed renewal on your largest account deserves a person, not only a template.

A dunning playbook

1. Set up Stripe. Turn on Smart Retries, failed payment emails and expiring card emails, and choose the end state on purpose.
2. Name who follows up. Support usually handles small accounts, and the founder or account owner handles large ones.
3. Act on the decline reason. Soft declines such as insufficient_funds can wait for retries. Hard declines need a "please update your card" message right away.
4. Match access to status. Keep access during past_due if you want a grace period. Stripe advises revoking access once a subscription is unpaid, because payments were already retried while it was past due.
5. Update the right payment method. If the subscription has its own default payment method, Stripe retries that one. Updating only the customer's default leaves retries on the old card.
6. Close the case. Confirm the payment recovered, or record the loss so your churn numbers show it.

Dunning and ChargeBell

ChargeBell doesn't run dunning. Its Stripe access is read-only, so it can't retry charges or email customers. It makes sure your team knows when the dunning clock starts. The invoice payment failed alert posts a declined renewal to Slack with the amount, the customer and the decline reason. It is critical, so it skips quiet hours. A payment recovered alert follows when a retry succeeds, and a subscription canceled alert shows the ones that didn't. To decide which team sees which alert, read which Stripe alerts go to finance, support, and founders.