Involuntary churn occurs when a customer loses access because payment failed rather than because the customer chose to cancel. Dunning is the coordinated process of retrying collection, informing the customer, updating payment details, preserving service appropriately, and closing the account when recovery fails. Good recovery protects revenue without confusing, pressuring, or repeatedly charging customers without clear rules.
Image disclosure: The hero is an AI-generated editorial illustration and does not show real customer or payment data. The lifecycle diagram is an original ChoiceRidge schematic.
Short answer
Prevent avoidable failures, classify decline types, retry only when another attempt is appropriate, provide a secure self-service update path, communicate service consequences clearly, and measure recovery by cohort and method. Separate temporary failures from hard declines, track the complete subscription state through webhooks or equivalent events, and test cancellation, grace-period, tax, entitlement, and accounting behavior end to end.
Understand the recovery lifecycle
Payment failure is an event, not a final state. The business must decide whether the invoice remains open, access continues during a grace period, another method can be used, tax or accounting records change, and when the subscription becomes past due, unpaid, paused, or canceled.
Stripe's current Billing documentation provides a useful implementation example: recovery may combine analytics, automatic retries, customer emails, card updates, and custom automations. It also notes that some hard declines are not eligible for ordinary retries without a new payment method. Exact behavior varies by processor and payment rail.
Prevent before recovering
Reduce failure opportunities with validated payment details, accurate billing descriptors, advance renewal reminders where appropriate, card account-updater support, multiple permitted payment methods, clear trial conversion terms, and a customer portal. Monitor integration errors separately from issuer declines; retrying cannot fix a broken webhook or incorrect subscription state.
Keep customer contact details current and ensure messages authenticate the business without placing sensitive payment information in email. The secure update link should expire appropriately, preserve the correct customer and invoice context, and work on mobile and assistive technology.
Design a retry policy
Retries should reflect decline reason, payment method, geography, amount, billing cadence, customer value, and network or processor rules. Avoid a single aggressive schedule for every failure.
| Failure class | Typical response |
|---|---|
| Temporary issuer or funds issue | Timed retry within an explicit window |
| Expired or replaced credential | Request an updated method; use account updater where available |
| Authentication required | Send the customer through the required authentication path |
| Hard decline or invalid details | Stop blind retries and request correction |
| Integration or state error | Repair the system; do not treat as customer delinquency |
Record the maximum attempts and duration. Prevent duplicate charges with idempotent operations and reconcile late success, chargeback, refund, and manual payment. A retry engine must not race with a customer who has already updated, canceled, or paid through another route.
Communicate as a service recovery
Messages should identify the subscription, explain that payment was unsuccessful, provide a secure update route, state the next attempt or deadline when known, and describe service impact without false urgency. Do not expose full card data or ask a customer to reply with credentials.
Coordinate email, in-app notifications, SMS, and customer-success outreach so the customer does not receive contradictory messages. Suppress recovery messages immediately after successful payment, cancellation, dispute, or support resolution.
Entitlement and grace-period rules
Map billing state to access explicitly. Instant termination may create disproportionate harm for a recoverable failure; unlimited grace can create revenue and abuse risk. Consider plan, data portability, service criticality, contractual terms, and whether read-only access or export remains available.
Define what happens to scheduled work, stored data, user seats, usage charges, discounts, and downstream licenses during each state. Test reactivation after recovery: the customer should regain the correct entitlement without duplicate subscription or lost configuration.
Measure what was actually recovered
Track initial payment failure rate, amount entering recovery, recovered amount and accounts, time to recovery, recovery method, customer update completion, support contacts, cancellation after recovery, and final write-off. Segment by issuer response, payment method, country, plan, tenure, and billing cadence where privacy and sample size allow.
Stripe distinguishes recovered, not recovered, and still-in-recovery volume, which avoids declaring a recent cohort unsuccessful before its retry window closes. Compare cohorts on a mature basis. Attribute recovery carefully when retries, emails, in-app prompts, and manual outreach overlap.
End-to-end test cases
- temporary decline followed by successful retry;
- hard decline requiring a new method;
- customer updates the method before the next retry;
- authentication is required;
- webhook arrives twice or out of order;
- payment succeeds after cancellation was requested;
- invoice remains open while entitlement changes;
- annual high-value customer enters manual review;
- customer cannot access email or the portal;
- recovery fails and data/export policy begins.
Operating checklist
- Billing, invoice, subscription, and entitlement states mapped
- Retry policy uses failure class and processor rules
- Secure mobile-accessible payment update path tested
- Messages are coordinated, accurate, and suppressed after resolution
- Idempotency and out-of-order event handling verified
- Grace, pause, cancellation, and reactivation behavior documented
- Recovery metrics use mature cohorts and full operating cost
- Support, finance, accounting, and engineering ownership assigned
- Exit and data-retention rules are clear to customers
This topic fills the subscriptions and retention scope of the Customer Experience Software hub. For platform-level subscription capabilities, use the existing ecommerce platforms for subscriptions guide without treating platform support as proof of a complete recovery operation.
Method and limitations
This is a processor-neutral operating framework illustrated with public Stripe documentation. Payment-network rules, consumer requirements, taxes, accounting, and cancellation laws vary. Verify current provider behavior and obtain qualified advice for applicable markets.