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 and the failed invoice is marked outstanding. The customer receives a notification that their payment failed, with a link to update their payment method.
Days 1, 3, and 5: Automatic retries. Commet retries the charge 3 times on a fixed schedule — day 1, day 3, and day 5 after the original failure. Retries run automatically, driven by Commet's own dunning job, 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 keeps access to your product — features, usage, and seats keep working (usage accrues as debt). Only purchases and plan changes are blocked. 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 charge cannot be recovered after the third retry fails, the subscription is cancelled and the outstanding invoice is marked uncollectible. At this point the customer loses access.
Customers can also self-recover during the grace window without waiting for a retry — by updating their payment method or paying a recovery link. A successful recovery returns the subscription to active and fires a payment.recovered webhook.
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.
Add customer-initiated payment method updates during the grace period and recovery rates climb further on charges that would otherwise be lost.
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 around the day 3 retry, and a final notice before the last retry.
Commet runs this entire recovery flow for you — start with the Commet docs.
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