Resources

When to Retry a Failed Payment: Timing Rules

Retry too soon and you charge an empty account again. Retry too late and the customer has mentally cancelled. Retry the wrong decline and you burn fees — and issuer goodwill — on a charge that was never going to succeed. "When should you retry a failed payment?" sounds like a settings question. It is actually four different questions, one per decline family, each with its own clock. This is the practical timing playbook: the rules for insufficient funds, generic soft declines, expired and replaced cards, and hard declines, plus the caps and spacing that keep a retry schedule effective instead of expensive. For the mechanism underneath — how retry engines read declines and sequence attempts — pair this with our explainer on payment retry logic.

Rule zero: the decline sets the clock

Every failed charge returns a decline reason from the issuer. That reason, not your billing date and not a platform default, determines when — or whether — to retry. The scale of the timing problem is worth stating plainly: across 5.4M failed payments, insufficient funds is the largest decline category at 40.6%, according to Churnkey's published analysis of Stripe data. The single most common failure is a customer whose card is fine and whose account is temporarily empty. For that customer, timing is not a detail. Timing is the entire fix.

The baseline you are improving on is already decent. According to the same Churnkey analysis of Stripe data, Stripe Smart Retries alone recover roughly 51% of failed payments, and layered precision retries reach roughly 55%. The points between those numbers — and beyond them, with outreach layered in — are won almost entirely on timing and routing decisions like the ones below.

Insufficient funds: align to the pay cycle

An insufficient-funds decline means the money was not there at the moment of the charge. It says nothing about tomorrow, next week, or the customer's intent. The retry rules:

  • Wait for money, not for a fixed interval. Most wages land on predictable rhythms — the 1st and 15th of the month, alternate Fridays, the last business day. A retry that lands the morning after a common payday converts; the same retry landing the day before payday fails again and spends one of your limited attempts.
  • Space attempts in days, not hours. Accounts do not refill hourly. A second attempt a few hours after an insufficient-funds decline almost always meets the same empty account. Give each attempt a genuinely different funding moment to land in.
  • Expect the first retry to fail sometimes. If the initial charge failed on the 28th and payday is the 1st, the winning attempt may be the second or third. Plan the schedule so attempts survive until at least one full pay cycle has passed — roughly two weeks covers the great majority of wage patterns.
  • Tell the customer a retry is coming. A short notice — your payment did not go through, we will try again on this date, or update your card here — lets customers move money or swap to a funded card. It also prevents the successful retry from reading as a surprise charge.

Generic soft declines: spaced, patient, finite

Generic soft declines — do-not-honor responses, issuer risk flags, velocity limits, temporary processing refusals — come with no specific explanation and no specific clock. The discipline here is spacing and restraint:

  • First retry after a short gap. Many generic declines are momentary: a fraud screen that trips once, a limit that resets daily. A retry after a day or two clears a large share of them.
  • Then widen the gaps. If the second attempt also fails generically, stretch the spacing. Consecutive failures on the same card lower your odds and, repeated aggressively, can train issuers to distrust your charges.
  • Change one variable when you can. Retrying the identical charge at the identical time of day repeats the identical experiment. Shifting the time of day, and trying after the customer has been contacted, gives the retry a different environment to succeed in.
  • Run outreach alongside. Soft declines the customer can explain — a card frozen after travel, a bank that blocked the transaction — resolve fastest when the customer acts. Retries alone guess; retries plus a clear email give the customer the chance to fix the cause.

If you are comparing engines that automate this, our roundup of the best smart retry tools compares how the main systems handle scheduling and decline routing.

Expired and replaced cards: do not retry — route

An expired card decline is not a timing problem. The details on file are dead, and every retry against them returns the same answer. The same applies when a card has been replaced and the old number no longer works. The correct sequence is:

  1. Stop the retry clock. Do not spend attempts re-charging details that cannot succeed.
  2. Check for updated details first. Account updater services can refresh expired and reissued cards automatically in the background. If refreshed details arrive, a single retry against the new card is the right move.
  3. Otherwise, ask — immediately and specifically. The message should name the problem (your card on file has expired), link to a secure update page, and say what happens and when if the card is not updated. Speed matters: the customer still expects the service, and the subscription is easiest to save before the first missed delivery or access gap.
  4. Retry once, promptly, when new details land. The moment the customer updates their card, charge it. Waiting for the next scheduled attempt wastes the goodwill the customer just spent updating it.

Hard declines: the retry that should never fire

Hard declines — closed accounts, cards reported lost or stolen, blocked cards, fraud stops — carry a permanent answer for the details on file. The rule is absolute: hard declines are never retried. Retrying cannot succeed, it costs a processing attempt, it can generate chargeback-adjacent noise, and repeated attempts against known-dead cards damage your standing with issuers and networks, which quietly lowers approval rates for your good charges too.

The only play for a hard decline is outreach: a prompt, plain message that the payment method cannot be used and a secure link to replace it. If the customer does not replace it within your dunning window, the subscription ends — correctly. That is not a recovery failure; that is the system working.

Attempt caps and total window: how many, how long

Timing rules need boundaries, or schedules drift into harassment of the customer's bank account. The boundaries we run and recommend:

Decline family First retry Spacing Cap
Insufficient funds Aligned to next likely payday Days apart, across at least one pay cycle Within overall cap below
Generic soft decline After 1–2 days Widening gaps between attempts Within overall cap below
Expired / replaced card Only on refreshed or new details Immediately when details arrive One prompt attempt per update
Hard decline Never Not applicable Zero attempts
  • Overall cap: up to 6 attempts over roughly 16 days. That window is long enough to cross a full pay cycle and short enough that you are not still retrying when the next renewal arrives and compounds the failure. Beyond it, additional attempts add cost and issuer friction faster than they add recoveries.
  • Stop conditions beat the schedule. A successful charge, a card update, a hard decline on a later attempt, or a customer cancellation all end the sequence immediately — the schedule never outranks new information.
  • Track failure rate, not just recoveries. Knowing your overall payment failure rate tells you whether timing gains are real or whether the mix of declines shifted under you.

The retry schedule matrix maps these families against attempt timing in one view if you are building or auditing a schedule for your own billing stack.

The mistakes that quietly kill recovery

  • Retrying everything immediately. A same-hour retry storm meets the same empty account, the same fraud flag, the same dead card — and spends your attempts before conditions change.
  • Retrying on a fixed calendar for every decline. Fixed schedules ignore the one piece of information that predicts success: why the charge failed.
  • Going silent while retrying. Retries fix timing problems. They cannot fix expired cards, frozen cards, or customers who do not recognize the charge. Every silent schedule abandons those customers.
  • Never stopping. Schedules without a cap convert a recoverable customer into an annoyed one, and a dead card into an issuer-relations problem.

The bottom line

Ask "when should I retry?" per decline, not per account. Insufficient funds waits for the pay cycle. Generic soft declines get spaced, finite attempts with outreach alongside. Expired and replaced cards leave the retry track and go to the update flow. Hard declines never fire again. Cap the whole effort at up to 6 attempts over roughly 16 days, stop the moment anything changes, and you have the timing core of a professional recovery system — the same rules Swipe Again runs across the nine platforms it supports, at $179/mo flat with no percentage of recovered revenue.

Frequently asked questions

How long should I wait before retrying a failed payment?

It depends on the decline. For insufficient funds, wait until after the next likely payday — often a few days, aligned to common pay cycles like the 1st, the 15th, or Fridays. For a generic soft decline, a first retry after one to two days is reasonable, with wider gaps after that. For expired cards and hard declines, do not wait and retry at all — route them to a card update instead.

How many times should a failed payment be retried?

A practical ceiling is up to 6 attempts over roughly 16 days for retriable soft declines. That window crosses at least one full pay cycle for most customers. More attempts than that add processing costs and issuer friction faster than they add recoveries, and the sequence should stop earlier whenever the charge succeeds, the card is updated, or a hard decline appears.

Why is retrying a hard decline harmful?

A hard decline means the card on file can never be charged successfully — the account is closed or the card is reported lost, stolen, or blocked. Retrying wastes fees on an impossible charge and repeated attempts against known-dead cards can damage your standing with issuers, which may lower approval rates across your other charges. The only correct response is to ask the customer for new payment details.

Should I tell customers before I retry their card?

Yes. A brief notice that the payment failed, when the next attempt will happen, and how to update the card instead prevents surprise-charge disputes and gives the customer a chance to fix the underlying problem — moving money, unfreezing a card, or supplying new details — before the retry fires.

What recovery rate should I expect from good retry timing?

As a baseline, Stripe Smart Retries alone recover roughly 51 percent of failed payments, and layered precision retries reach roughly 55 percent, according to Churnkey's published analysis of Stripe data. Your results depend on your decline mix and pricing, but most of the improvement over a naive schedule comes from pay-cycle timing for insufficient-funds declines and correct routing of expired and hard declines.

Related reading: How long should dunning run

Stop losing subscribers who never meant to leave.

Connect in 2 minutes. Free 14-day trial — Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days. Recovered revenue means every failed payment collected while Swipe Again is active, from any recovery source, as defined in Section 3 of our Terms. How we count: https://swipeagain.com/pages/how-we-count

Start trial
Start today

Stop losing subscribers
who never meant to leave.

Every billing cycle without recovery is revenue you earned and never collected. Connect in 2 minutes — see your first wins inside the trial.

Start trial

Free 14-day trial · No code · Cancel anytime