Recover recurring payments without surprising the customer

Dunning is the process around an unpaid recurring invoice: deciding whether and when to retry, notifying the customer, offering a safe update path, changing service access, and eventually closing or writing off the balance. A good system tries to recover legitimate revenue without turning one decline into repeated unexplained attempts.

Start from the agreement

Store what the customer accepted: merchant identity, product or service, amount or calculation method, currency, billing timing and frequency, trial or promotion terms, cancellation and refund policy, contact route, and the credential used in truncated form. Preserve notices of later changes and cancellation requests. Visa’s current public rules contain network-specific stored-credential agreement, disclosure, retention, change, and cancellation requirements; merchants must also meet applicable law and their acquirer’s instructions (Visa rules).

The billing system should refuse a merchant-initiated charge after the recorded agreement ends or the merchant has processed a valid cancellation. A payment retry is not a way to override a customer-service decision. The consumer-facing subscription cancellation guide explains why ending service and stopping the payment authorization are related but distinct.

Classify before retrying

Record the provider and network response without exposing sensitive or manipulable details to the customer. Separate configuration errors, authentication or customer-action requirements, insufficient funds or temporary conditions, lost or closed credentials, and suspected fraud. Visa’s merchant advisory describes some “soft” declines as potentially retryable after a reasonable interval and says lost-or-stolen-card hard declines should not be reattempted; this is network guidance, not a portable decline-code table (Visa merchant guidance). Use the processor’s current decline guidance for the actual integration.

Set a finite retry policy by segment. A monthly consumer plan, an annual business invoice, and a usage-based bill need not share timing. Avoid rapid repeated attempts. Stop retries when the response is non-retryable, the customer cancels, the credential is removed, the invoice is paid another way, or the retry budget ends.

Make the notice useful and safe

Tell the customer which subscription or invoice needs attention, the amount, the next service or retry consequence, and where to review billing securely. Do not put full credentials or a login token in email. Link to the customer’s normal authenticated account rather than a page asking for card details solely because the message said payment failed.

Offer a grace period appropriate to the service. Avoid erasing data or essential work at the first failure. Define read-only, paused, and canceled states, including how access is restored after payment. Stripe’s automation recipes are one provider-specific example of segmenting retry policies, adding grace, notifying staff, canceling a subscription, and marking an invoice uncollectible (Stripe). They are product capabilities, not default settings or universal best timing.

Update credentials without hiding the event

Network or provider account-updater services may refresh eligible stored credentials. Treat an update as maintenance of an authorized relationship, not new customer consent or proof the invoice is valid. Keep the updater result and original agreement. Send appropriate advance notices for upcoming or changed subscription charges even when the credential is likely to work; Visa’s merchant guidance specifically connects advance notice with fewer surprises.

Reconcile the whole sequence

Give every invoice one ledger: original attempt, each retry, credential update, customer notice, manual payment, refund, dispute, service change, and final disposition. Use idempotency keys so a retry job cannot create duplicate attempts, and consume payment events through a duplicate-safe webhook handler. The API retry guide addresses the technical boundary. Tie recovered payments and fees to the processor payout; do not count a successful authorization as collected cash.

Monitor recovery by initial failure class, attempt number, customer complaints, cancellations after dunning, duplicate attempts, and time to resolution. The goal is not the highest possible number of retries. It is a legible policy that recovers retryable payments, stops when it should, and leaves the customer with a clear route to act.

Sources

• Visa Core Rules and Visa Product and Service Rules — network-specific
• Stripe, Automation use cases — provider-specific
• Visa, Helping to maximize merchant success — network guidance