Subscription Dunning Strategy: Timing, Messages, and Stop Rules

A subscription dunning strategy is the coordinated policy for failed-payment retries, customer messages, access grace, and the final stop, cancellation, or downgrade action. Build it by decline type and gateway ownership, give customers one clear payment-fix path, cap attempts, and measure recovery after closed observation windows alongside complaints, refunds, support, and duplicate-charge risk.

Key takeaways

• Dunning joins collection ownership, failure routing, messages, access, and outcomes.
• No retry schedule is universally best.
• Manual, local Stripe, PayPal, and Paddle flows need different policies.
• Every message should add an action or a new consequence.
• Stop rules and guardrail metrics matter as much as recovered value.

Build the five-layer policy

1. Ownership: who creates invoices and controls attempts?
2. Failure route: retryable, customer action, hard stop, or unknown?
3. Timing: when can another attempt or lifecycle change occur?
4. Message/access: what does the customer do and what service continues?
5. Stop/outcome: paid, on-hold, cancelled, downgraded, or escalated?

Current ArraySubs defaults—three-day reminder, six-hour invoice lead, three active-grace days, seven on-hold days, and up to three local Stripe retries at 24-hour intervals—are a baseline, not an industry recommendation.

Step 1: assign ownership

manual/offline → customer action pays the ArraySubs order
Stripe → ArraySubs owns local invoice, charge, and retry
PayPal → PayPal owns remote schedule and recovery
Paddle → Paddle owns remote schedule and recovery

Do not run two charge engines. Local messages and access rules can complement a remote provider, but reconcile remote state before any manual attempt. Stripe Billing Smart Retries do not control current ArraySubs PaymentIntent renewals.

Step 2: route by remedy

Gateway advice overrides a copied timetable. Excessive retries can create network, fraud, complaint, and duplicate-charge risk.

Step 3: design the message ladder

Every message should answer: what failed, what amount/plan is affected, what the customer should do, whether another attempt is planned, what happens to access/shipment, and how to get help.

Use a calm tone, local date/timezone, customer-safe reason, one primary CTA, accessible link text, and a support fallback. Stop the failure sequence after recovery.

Step 4: choose timing from constraints

Consider gateway/network rules, failure remedy, cadence and amount, service/fulfillment cost during grace, customer action time, remote recovery window, support capacity, and legal/contract review.

retry i = prior failed attempt + chosen delay
on-hold threshold = due time + active grace
cancel threshold = due time + active grace + on-hold grace

For remote billing, decide whether local service ends before, with, or after the gateway’s final recovery window. An accidental mismatch is a defect.

Planning timeline only; no universal cadence is recommended.

Current ArraySubs default third Stripe retry and on-hold threshold both sit near day three. Test real Action Scheduler ordering as one system.

Step 5: define access and fulfillment

Low-cost digital access may tolerate short active grace. Expensive service can need graduated limits. Physical fulfillment may need to hold a shipment immediately even while account access remains active. Regulated or essential services need qualified review.

An eligible ArraySubs auto-downgrade can cancel the stale unpaid order, detach old automatic context, move/reuse a fallback plan, return it to active, and send lifecycle communication. It is optional and must be tested end to end.

Stop rules

Stop attempts when paid, authorization is withdrawn, gateway says stop, new credentials/authentication are required, context is invalid, the limit is reached, status is ineligible, amount/schedule is wrong, remote recovery owns the charge, or risk review is needed.

Stop or change communication when recovered, delivery repeatedly fails, support takes over, final disposition occurs, or the next message adds no useful action.

Measurement and experiments

customer recovery = recovered customers ÷ eligible failures with closed windows
value recovery = recovered amount ÷ failed amount with closed windows
involuntary cancellation = payment-failure cancellations ÷ closed failed-renewal cohort
incremental recovery at attempt N = first recoveries at N ÷ cases eligible immediately before N

Track duplicate charges, complaints, refunds, chargebacks, support, access/shipment mistakes, update completion, reconciliation mismatch, and email delivery. Test one material variable at a time—message, timing, or grace—not all three.

For implementation detail and a recovery runbook, read Failed Subscription Payment Recovery.

Final recommendation

Write the dunning policy as a governed state machine with owners, messages, stop conditions, and evidence. Optimize only within gateway rules and customer-safe guardrails. Compare ArraySubs plans.

Frequently asked questions

What is subscription dunning?

Dunning is the coordinated process after a payment problem: retries, messages, payment-method correction, grace/access policy, escalation, and final cancellation, on-hold, or downgrade.

What is the best retry schedule?

There is no universal best schedule. Use gateway advice, decline type, product economics, customer action time, and first-party results. Current ArraySubs Stripe behavior is a product baseline, not a benchmark.

Should every failed-payment email threaten cancellation?

No. First explain the issue, amount, action, and planned timing. State access or cancellation consequences only when accurate, specific, and paired with a usable recovery path.

Should PayPal or Paddle also use local retries?

Not as a second uncoordinated charge engine. Those gateways own remote schedules. Reconcile them and align local lifecycle/messages without creating duplicate attempts.

When should dunning stop?

Stop on payment, withdrawal of authorization, gateway stop advice, required new credentials/authentication, retry exhaustion, ineligible status, incorrect amount/schedule, or conflict with remote recovery.

Disclosure, verification, and update log

• July 2026: Verified against current ArraySubs recovery and gateway ownership plus official processor guidance. No retry cadence or recovery benchmark is prescribed.