How Many Times Should You Retry a Failed Payment? (Timing Beats Count)

How many times should you retry a failed payment?

There is no magic number, but there is a rhythm: aim for roughly three to five attempts spread across one to two weeks, spaced further apart over time, rather than firing one attempt after another in a single day. Count gets you spammed cards and annoyed banks. Timing gets you paid.

The question most founders actually want answered is simple: how many times do I retry before I give up? The honest answer is that the count matters far less than when each retry lands. A failed payment is a bank saying "no" to one specific attempt, not a permanent verdict on the card. The same card will say yes later in the right conditions.

Why timing beats count

Most subscription failures are transient. The classic one is insufficient funds. A customer's account is short at billing time, but the money lands on payday — which is usually days, not hours, later. If you retry five times in 24 hours, you're spamming a card that's still empty. You've spent five attempts before the money ever arrived.

This is why the same failure behaves differently depending on when you try it. A card declined at midnight on the 1st might succeed cleanly on the 3rd after a paycheck. The more attempts you burn before the money shows up, the less room you have left — and network rules cap how aggressively you can re-submit a charge in the first place.

Think about the arithmetic of a recovery. Say you're willing to make five retry attempts on a failed renewal. If you fire all five in one day, and the card is an insufficient-funds case, there's a good chance zero of them land because the money isn't there yet. If you spread those same five attempts across ten days, timed loosely to the customer's likely pay period, you dramatically raise the odds that at least one lands when the account has money.

The cadence I default to

A concrete, defensible starting point looks like this — day 1 after the initial failure, then day 3, then day 7, then day 10, then day 14 at most. Five attempts across two weeks. Each gap is longer than the last, which does two things: it gives transient problems time to clear, and it stops the pattern from looking like spam.

• •Day 1:
• •a quick first retry soon after the original attempt, in case it was a momentary blip.
• •Day 3:
• •a second attempt, letting a short-term hold or overdraft situation settle.
• •Day 7:
• •a third attempt, now clear of most weekly pay cycles.
• •Day 10:
• •a fourth attempt, spaced out to respect retry pressure.
• •Day 14:
• •a final attempt, then stop the machine and let a human take over.

Whether you use Stripe's automated Smart Retries or roll your own scheduling, the principle is the same: spread, space, and stop. Smart Retries already does a version of this — Stripe uses machine learning to pick retry timing based on the decline code and network data, which is usually smarter than a fixed schedule. If you rely on it, the levers you control are when the sequence ends and what happens then.

How Stripe Smart Retries fits

If you're on Stripe, you likely don't need to hand-build the retry scheduler — Smart Retries does the spacing for you. Stripe's system looks at bank and network patterns and picks its own moments to retry, often up to dozens of times over days for the failures it thinks can recover. The strength is that it's adaptive: it learns which decline codes respond to another attempt and which ones never will.

But here's the gap a typical founder runs into. Smart Retries will keep a payment alive for a while, but it eventually gives up. When it does, that's it — the subscription goes past_due and there's no automatic email in your voice, no personal follow-up, no alert telling you a real customer is about to slip away. The retry machine is excellent at the timing. It's silent about the thing that needs a human.

So think of Smart Retries as the timing engine and your recovery emails as the closer. They're not competitors — I've covered the full comparison elsewhere — they're two halves of the same sequence. Let the machine handle when to try again. Keep the human touch for what to say when the machine stops trying.

The network rules nobody reads

One reason the count question is fraught is that you can't just retry forever. Card networks and issuing banks impose limits on how often a merchant can re-submit the same transaction, and they watch for patterns that look abusive. A burst of rapid retries can get a charge flagged, which is bad for that payment and worse for your account's standing.

This is part of why spacing matters beyond politeness. A retry cadence that spreads attempts across days stays comfortably inside normal merchant behavior. A fan that hammers a card eight times an hour reads as a brute-force attempt. The network doesn't distinguish between an enthusiastic retry loop and a fraud pattern — it sees the same signal.

The honest takeaway is hedged: excessive retries can look bad and could draw scrutiny, so treat restraint as a feature, not a limitation. If a card has come back declined on soft codes several times with no sign of clearing, that's not a signal to retry faster. It's a signal to stop and email the customer.

Soft declines retry, hard declines don't

Not every failure deserves the same retry treatment. The decline code the bank returns tells you whether to keep trying or stop immediately. An insufficient-funds decline is soft — retrying pays off because the problem can clear on its own. An expired card or a reported-lost card is hard — no amount of retrying revives it, because the card itself is dead.

The decision rule is simple: retry the soft, email the hard. Hard-decline cards need a new card number, which only the customer can provide. Retrying a lost card is pure noise that burns network goodwill. Getting this split right is the difference between a smart recovery sequence and a system that annoys banks while leaving customers stranded.

I go deeper on reading each code and what to do with it in my breakdown of soft versus hard Stripe declines. The short version: spend your retries on the cards that can recover, and reach for a personal email the moment a card can't.

Retries alone recover less than retries plus email

Here's the thing nobody in the retry-limit debate tells you: a retry can only fix what a retry can fix. No automated attempt can update a card with a new number, call a customer who owes money, or convince someone whose card keeps failing to log in and fix their billing. There are failures that no retry, at any count, will ever recover.

That's the case for pairing retries with a real recovery email. While the automation tries a few well-timed times, a short personal message reaches the customer — ideally from a real person's address, not no-reply@ — and gives them one click to update their card. The customer fixes what the retry never could. Retries buy time; the email does the recovering.

In practice, this is where most of my recovered revenue comes from. The retries are background noise that quietly catches the easy wins. The emails are where the hard cases get saved. If you've got your cadence right and pairing it with a human touch, you're doing the part that actually moves your recovery rate.