Dunning, Cancellation & the End
Dunning is the designed recovery flow that starts when a recurring renewal payment fails, while cancellation and access removal are separate lifecycle decisions. It models retries, customer messages, billing status, and entitlements as related but independent state changes, so one failed charge does not automatically end the subscription or lock the user out.
Recurring payments fail for ordinary reasons: expired cards, bank declines, insufficient funds, network errors, or payment method rules. Treating that failure as the end of the customer relationship is usually too blunt. The system needs time to recover revenue, inform the customer, protect the business from unpaid use, and avoid surprising a legitimate user whose payment problem may be temporary.
A practical dunning design is a small state machine over time. A renewal invoice fails, the subscription moves to a past-due or grace state, retries are scheduled, and messages ask the customer to update payment details. In parallel, the product decides whether access stays active, becomes limited, pauses, or ends. Billing events feed the lifecycle, but they should not be direct commands to delete entitlements.
The trade-off is that leniency has cost. Keeping access open during grace can increase unpaid usage and fraud exposure, while aggressive restriction creates support tickets and churn from recoverable failures. Retry timing also depends on payment method behaviour, customer value, invoice size, and operational tolerance. There is no universally correct schedule; the honest answer is that it depends on the product and risk model.
Engineers meet this in subscription services, payment webhooks, entitlement checks, invoicing jobs, and customer messaging systems. The common misunderstanding is to collapse failed renewal, cancellation, expiry, and revocation into one boolean such as active. Better implementations store explicit states like active, past due, in grace, restricted, cancelled, expired, or written off, with clear transitions and idempotent handling of payment events.
Common questions
- Is dunning the same as cancelling a subscription?
- No. Dunning is the recovery process after a payment attempt fails. Cancellation is a decision to stop future billing, usually made by the customer or the business. A cancelled subscription may still have access until the paid period ends, while a past-due subscription may still be recoverable through retries and updated payment details.
- Should access be revoked as soon as renewal payment fails?
- Usually not automatically. Access is a product and risk decision, not just a payment gateway decision. Some products keep full access during a grace period, some restrict expensive features, and some pause immediately. The right choice depends on unpaid usage cost, customer value, fraud risk, contractual terms, and how painful mistaken lockouts are.
- How should engineers model this in code?
- Use explicit lifecycle states and transitions instead of one overloaded active flag. Payment failures, successful retries, customer cancellations, period expiry, and write-offs should be separate events that update billing state, communication state, and entitlement state deliberately. Webhooks should be treated as inputs to the state machine, with idempotency and recovery paths.