Subscription Dunning: Recover Failed Payments Without Damaging Trust

September 3, 2026 · 4 min read

Dunning is the controlled recovery of a failed recurring payment: classify the outcome, retry where useful, ask the customer to act when necessary, and change service status predictably. Its goal is to recover involuntary revenue loss without duplicate charges, coercive messaging, or hidden cancellation barriers.

A sound process distinguishes temporary and hard declines, never relies solely on a browser return, and ties every attempt to one invoice, subscription, and service period.

At a glance

• preserve subscription, invoice, and payment-attempt IDs;
• process verified webhooks idempotently;
• do not retry hard declines without a relevant change;
• use a limited retry policy;
• provide a secure payment-method update page;
• define grace-period and final access states;
• communicate amount, service, and safe next step;
• reconcile recovered cash, service access, and complaints.

Separate object states

Object	Example states
Invoice	Draft, open, paid, uncollectible, void
Payment	Requires action, processing, succeeded, failed
Subscription	Active, past due, restricted, cancelled
Entitlement	Full, grace, limited, closed

Do not drive access from one unverified HTTP response. Map provider states to product states through an approved transition table.

Classify failure

• temporary: insufficient funds, transient limit, or network condition;
• customer action: additional authentication or mandate update;
• stale credential: expired or replaced payment method;
• hard decline: stolen instrument, revoked authority, or prohibited transaction;
• technical: integration, signature, currency, or amount defect;
• unknown: evidence is insufficient for a safe conclusion.

Retries are not useful for every class. Indefinite attempts increase complaints and operational risk.

Recovery flow

1. Receive and verify the failure event.
2. Persist cause and the next permitted action.
3. Schedule limited attempts for a recoverable failure.
4. Send a secure management link when customer action is required.
5. Show the state in the customer's account.
6. Apply the documented grace period.
7. Transition predictably after the final attempt.
8. Reconcile invoice, payment, entitlement, and communication.

Never ask for complete payment credentials by email or support message.

Customer communication

A first notice should be service-led:

We could not confirm the payment of [amount] for [service/period]. We will never request your payment details by email. Check the status or update the method through your secure account: [link]. Your current access remains [condition].

State whether another attempt is planned. Stop the sequence immediately after recovery or cancellation, and make legitimate cancellation manageable.

Dunning scorecard

Metric	Purpose
Initial failure rate	Size and composition of the issue
Invoice recovery rate	Successfully recovered invoices
Recovered contribution	Commercial value, not gross claim
Time to recovery	Exposure duration
Duplicate attempts	Idempotency and event defects
Involuntary churn	Loss caused by payment failure
Complaints	Customer cost of the process

Segment by provider, payment method, failure cause, market, and plan. Compare policies only after controlling for the underlying failure mix.

Test suite

• successful renewal;
• representative test decline types;
• customer action required;
• delayed and duplicate webhook;
• payment method changed between attempts;
• cancellation during grace;
• refund after recovery;
• unavailable payment-management page;
• plan change and prorated amount;
• entitlement restored exactly once.

Common mistakes

• retrying every failure identically;
• confusing invoice and payment attempt;
• restricting service before status is verified;
• continuing notices after recovery;
• providing long-lived overpowered links;
• recognising recovery before settlement evidence;
• failing to reconcile entitlement;
• obscuring cancellation terms.

FAQ

How many times should payment be retried?

No universal count works. Use provider capabilities and your own failure data, limit the period, and consider decline type, value, risk, and customer expectation.

Is a grace period necessary?

It often prevents temporary payment problems from becoming customer loss, but duration should reflect service cost, abuse risk, and the contract.

Can a subscription be cancelled automatically?

Yes, when the final state is defined in advance, consistent with the agreement and applicable law, and accompanied by clear account status and communication.

Sources

• Stripe: Revenue Recovery
• Stripe: Smart Retries and custom retry schedules
• Stripe: subscription webhooks

Reviewed: 3 September 2026.

Continue with transactional-message deliverability, payment reconciliation, and payment-method coverage.

Pingvera can monitor billing-management pages and supporting endpoints so recovery messages do not send customers into a broken flow.

Read next: Transactional Message Deliverability · Marketplace and Store Reconciliation.