Dunning is the process of recovering failed payments on active subscriptions. When a recurring charge fails, the billing system does not immediately cancel the subscription. Instead, it enters a dunning flow: retrying the payment over a period of days, notifying the customer, and giving them a chance to update their payment method before access is revoked. Done well, dunning recovers revenue that would otherwise be lost to involuntary churn.
Why payments fail
Payment failures are more common than most SaaS builders expect. Industry data suggests 5-10% of recurring charges fail on the first attempt. The reasons are mundane but varied.
Expired cards. The customer's credit card reached its expiration date and the bank declined the charge. This is the single most common failure reason.
Insufficient funds. The customer's account does not have enough balance to cover the charge at the moment it was attempted.
Bank-side fraud blocks. The issuing bank flagged the recurring charge as suspicious, especially common when the charge amount changes (due to usage overage or a plan upgrade) or when the customer recently reported fraud on a different transaction.
Network errors. Temporary connectivity issues between the payment processor and the issuing bank. These often succeed on retry without any customer action.
None of these failures mean the customer wants to cancel. They are mechanical problems with payment processing, and a good dunning system resolves most of them automatically.
The dunning timeline
When a payment fails, the subscription moves from active to past_due. This status change is the signal that dunning has begun.
Day 0: Initial failure. The payment is declined. The subscription is marked past_due. The customer receives a notification that their payment failed, with a link to update their payment method.
Days 1-14: Smart retries. The payment processor (Stripe, in Commet's case) retries the charge using machine learning to pick optimal retry times. Stripe's Smart Retries analyze patterns across millions of transactions to determine when a particular card is most likely to succeed. Retries happen automatically without any action from the customer or your team.
During the grace period: Customer retains access. This is a critical design decision. While the subscription is past_due, the customer continues to have full access to your product. They can log in, use features, and access their data. Cutting access immediately on a failed payment punishes customers for a problem they may not even be aware of yet.
After all retries exhaust: Cancellation. If the payment cannot be recovered after the retry window closes, the subscription is cancelled. At this point, the customer loses access. The exact number of days before cancellation depends on your configuration, but 14-21 days is a common grace period.
For configuration details on handling failures in your integration, see the handle failed payments documentation.
Why you should keep access during past_due
It is tempting to cut access the moment a payment fails. The logic seems sound: no payment, no service. But this approach destroys revenue.
Consider the math. A customer on a $99/month plan has a failed payment. If you cut access immediately, they might churn permanently. Even if they intended to stay, the friction of being locked out, needing to re-activate, and potentially losing configuration or data can push them to a competitor. You lose $1,188/year.
If you keep access during the grace period, the customer has a seamless experience. Their card gets retried, the payment goes through on day 3, and they never even noticed the blip. You keep the $1,188/year.
The numbers support this approach. Stripe reports that Smart Retries recover around 30% of failed payments automatically. Add customer-initiated payment method updates during the grace period, and recovery rates can reach 50-70% of initially failed charges.
Reducing involuntary churn
Dunning is your primary defense against involuntary churn, which accounts for 20-40% of total churn at many SaaS companies. Beyond retry logic, proactive steps reduce failures in the first place.
Card update prompts. When a card approaches its expiration date, notify the customer before the next charge. This prevents the most common failure type.
Backup payment methods. A secondary payment method gives the system a fallback when the primary fails.
Invoice previews. Sending upcoming invoice notifications a few days before the charge gives customers time to ensure sufficient funds.
Dunning communications
The emails sent during dunning matter as much as the retry logic. A good dunning email has three elements: what happened (your payment failed), what to do (update your card), and a direct link to do it (one click to the payment method update page).
Avoid threatening language. "We were unable to process your payment. Update your card to keep your subscription active" is direct and helpful. Send the first notification immediately on failure, a reminder on day 3 or 4, and a final notice 2-3 days before cancellation.
Related
- Recurring Billing: the automated payment collection process where dunning activates on failure
- Subscription Billing: the broader model that dunning protects from involuntary churn
- Billing Cycle: the period within which payment collection and dunning occur
- Handle Failed Payments: implementation guide for configuring dunning behavior