Subscription retry schedule best practices: how many retries, and when
Every subscription app ships with a retry schedule: when a renewal charge fails, try again N times, D days apart. It's the single dunning setting most merchants never touch — and one of the few levers that directly moves recovered revenue. This guide covers what a retry schedule can and cannot fix, the principles that separate a good schedule from the default, and the specific settings to review in your app this week.
First: what a retry can fix, and what it can't
A retry re-asks the customer's bank the same question later. That only helps when the answer might change. Failures split roughly three ways (our failure-reasons guide goes deeper):
- Soft declines — insufficient funds, temporary bank blocks, processing hiccups. The card is alive; the moment was wrong. Retries are the right tool, and timing decides how well they work.
- Hard declines — expired, cancelled, lost or stolen cards. The answer will never change. Every retry is wasted, and the only fix is a card-update request to the customer.
- Ambiguous declines — the catch-all codes banks send when they
won't say why (
do_not_honor, generic declines). Worth one or two well-spaced retries, then treat like a hard decline. See the companion guide on decline codes for how to read them.
This is the core reason a single fixed schedule underperforms: it applies one treatment to three different problems.
Principle 1 — space retries across days, not hours
The most common soft decline is insufficient funds, and balances change when money arrives: paydays, the 1st and 15th, benefits days. Three retries inside 48 hours ask the same empty account the same question three times. The same three attempts spread across a week — deliberately crossing a likely payday or month boundary — give each attempt a genuinely different chance of success.
Principle 2 — more retries isn't more recovery
Retry curves flatten fast: each additional attempt recovers less than the one before, and most recoveries that will happen, happen in the first handful of attempts. Past that point, extra retries mostly hit dead cards — and carry real costs: repeated declines can trigger issuer velocity checks, annoy customers with repeated “payment failed” emails, and in card-network terms look like exactly the kind of re-presentment behavior you don't want attached to your merchant account. Somewhere in the range of three to six well-spaced attempts is where most schedules should land; if the money hasn't cleared by then, the fix isn't attempt number nine — it's a different treatment.
Principle 3 — the exhaustion setting matters more than the count
What happens after the last failed retry is the highest-stakes dunning setting you have. Auto-cancel converts a recoverable failure into churn, silently. If your app supports it, prefer pause (or “keep as failed”) on exhaustion — a paused subscriber can be recovered next week; a cancelled one is a re-acquisition project. Our involuntary-churn guide covers why this one default quietly drives so much subscriber loss.
Principle 4 — pair the schedule with the card-update ask
For hard declines, the retry schedule is irrelevant — the card-update email is the whole game, and it should go out on day one, not after retries exhaust. A good setup runs both tracks in parallel: soft declines get patient, well-timed retries and minimal customer noise; hard declines skip straight to a clear, friendly update-your-card request while the customer still remembers wanting the product.
Principle 5 — coordinate layers, never double-retry
On Shopify, your subscription app (Appstle, Seal, and others) owns billing and runs its own retries. If you add recovery tooling on top, make sure exactly one layer owns the retry decision — two systems independently retrying the same failed charge is how customers get double-billed, which does more damage than the original failure. Any add-on should read your app's retry state and work with it, not race it.
What to check in your app this week
- Find the numbers: retry count, spacing, and the exhaustion action. In Appstle and Seal these live in the dunning/failed-payment settings — our Appstle and Seal guides point to where.
- Stretch the spacing so the schedule crosses at least one payday or month boundary.
- Change exhaustion from cancel to pause if your app allows it.
- Check the email cadence — one clear failure notice beats a notification per retry.
- Measure recovered dollars monthly. Failures cost $X, retries and card updates brought back $Y. If nobody sees that line, settings drift back to defaults. (Our loss calculator gives a first estimate.)
Where Moorly fits: Moorly connects to your existing subscription app and starts read-only: it watches every failed renewal, classifies the decline, and shows what your current schedule recovers versus leaves behind. When you switch actions on, it works each failure by its reason — patient retries for soft declines, immediate card-update asks for dead cards — coordinated with your app's own dunning, never against it. Join the early-access list →
Moorly is an independent product by Velun Labs and is not affiliated with Shopify, Appstle Inc., or Seal Subscriptions s.r.o. App feature details vary by plan and version — always confirm against your own admin.