Updated July 2026 · Sourced from Stripe docs

Stripe insufficient_funds: when to retry, when to email

Q: What does insufficient_funds mean in Stripe?

insufficient_funds (issuer response code 51) means the card is valid, but the account did not have enough balance or available credit to cover the charge at the exact moment it ran. There is nothing wrong with the card, the account, or the customer, it was simply a timing problem, often a charge that hit a day or two before payday. That is why it behaves completely differently from a decline like expired_card: the card still works, so a well-timed retry usually succeeds. In fact, insufficient_funds is the single most recoverable decline you will see, because the intent to pay is there and the fix is just waiting a few days for the balance to top up. The wrong move is to treat it like a broken card and demand a new one.

Q: How long should you wait to retry insufficient funds?

The sweet spot is 2 to 7 days, and the smartest version times the retry to a likely payday. Retrying in the first few hours is pointless, the balance has not changed. A retry on day 2 or 3 catches accounts that top up quickly; a retry around day 5 to 7 catches weekly and bi-weekly paydays, which usually land on a Friday; and a retry around day 10 to 14 catches monthly paydays near the 1st or 15th. Beyond about two weeks, recovery odds fall off and you risk the issuer treating repeated attempts as suspicious. So a practical schedule is roughly three spaced retries across two weeks, aligned to paydays, then stop. Stripe recommends a maximum of eight retries, and Smart Retries handles the timing automatically if you use Stripe Billing.

Q: Should you tell customers to update their card for insufficient funds?

No, and this is the most common mistake. When the decline is insufficient_funds, the card is completely fine, so telling the customer to "update your card" is confusing and slightly alarming: it implies something is broken when nothing is. It also creates friction for no reason, they go hunting for a new card they do not need. The right message, if you email at all, is reassurance: let them know the payment did not go through this time, that their card and account are fine, and that you will automatically try again in a few days. Optionally offer a one-click pay-now link for anyone who wants to clear it immediately. Save the "update your card" language for the declines where the card actually is the problem, like an expired or incorrect card.

Q: What should an insufficient-funds email say?

It should reassure, not alarm. The template on this page names the reason plainly (the payment did not go through because of insufficient funds, a timing issue), states clearly that the card and account are fine and still active, and tells the customer you will automatically retry in a few days so they usually need to do nothing. It offers an optional one-click pay-now link for anyone who wants to resolve it immediately, and it promises you will stop the moment the payment succeeds. What it deliberately avoids is any language that blames the card or demands an update, because the card is not the problem. The tone is a light heads-up from a helpful vendor, not a red-alert dunning notice, which fits the fact that most insufficient-funds declines simply clear themselves on the next retry.

Q: How much of failed-payment revenue is recoverable from insufficient funds?

A large share, because insufficient_funds is the most recoverable decline there is. The card works and the customer intends to pay, so the only obstacle is a temporary balance, which resolves on payday. Recurly finds that the most common decline messages, including insufficient funds, recover at over 45% with the right retry strategy, and insufficient funds specifically sits at the top of the recovery table. That is why the return on getting the retry timing right is so high: a payday-aware schedule turns a big chunk of these failures back into successful charges with zero customer effort. The remaining cases, customers who are genuinely out of funds for a while, are where an optional pay-now nudge or a card-update option helps, but most insufficient-funds declines simply need patience and good timing.

Q: Can you recover insufficient-funds declines automatically?

Yes, and it is largely a timing problem a tool solves well. Stripe Smart Retries automatically re-attempts the charge at machine-chosen times, which handles the bulk of insufficient-funds recovery with no work from you. Layered on top, a reassurance email at the right moment catches the customers who want to act. SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code. For insufficient funds it pairs payday-aware retries with a reassurance email that does not blame the card, and it stops the sequence the instant the payment succeeds, so the customer never gets a needless nudge.

Q: What's the difference between insufficient_funds and card_declined?

insufficient_funds tells you exactly why the charge failed, the account was short, whereas card_declined or generic_decline is the issuer refusing without a stated reason. Both are soft declines that a retry can recover, but insufficient funds is the more predictable of the two: you know the fix is time, so a payday-aware retry schedule is ideal. A generic card_declined or do_not_honor is more opaque, the bank did not say why, so a couple of retries clear many, and when they do not, the customer may need to call their bank or try a different card. In messaging, both deserve a light touch rather than a card-update demand, but insufficient funds specifically warrants the most patient, timing-based approach, because you know the balance will likely be there in a few days.

This is the one decline where the card is fine, so retrying is the whole game. Time it to payday and most of these recover themselves. If you do email, reassure, never tell them to update a card that works.

By Daniel Borodin, founder of SubRevivalLast updated July 2026 · 10 min read

Retry timing, aimed at payday

Best window 2-7 days, timed to payday. Source: Recurly, docs.stripe.com.

The short answer

insufficient_funds is a soft decline, the card is fine, the account was just short at that moment. So retry it: a well-timed retry (2-7 days, ideally around payday) is the primary fix, and it is the highest-recovery decline of all. Do nottell the customer to "update your card", nothing is wrong with it. If you email, reassure them and offer an optional one-click pay-now. Cap retries at Stripe's recommended maximum of eight so the issuer does not flag them.

On this page

01The short answer 02insufficient_funds vs expired_card 03The insufficient_funds code 04The payday-aware retry table 05What to email (and what not to say)06FAQ 07Recover it automatically

The mindset

Treat this decline as a timing problem, not a card problem

Of all the ways a Stripe charge can fail, insufficient_funds is the one to be least worried about. The card is valid. The customer wants to pay. The account was just a little short at the exact moment the charge ran, usually a renewal that landed a day or two before payday. Wait a few days, retry, and the money is usually there.

That is why this decline is the single most recoverable one you will see. It is also the one most teams handle wrong, by treating it like a broken card and firing off an alarming "update your payment method" email. That message is confusing (their card is fine), it adds friction, and it can push a perfectly good customer to second-guess their subscription. The right instinct is patience plus a reassuring tone. This is one of the six causes in our why Stripe payments fail hub, and it sits at the opposite end from an expired card, where retrying is useless and updating is the only fix.

The two things that actually recover insufficient-funds declines are timing and tone: a payday-aware retry schedule, and, if you communicate at all, an email that reassures rather than alarms. This page gives you both, the retry table and a copy-paste template, plus the row-level detail on the code itself.

Soft

decline, the card is fine, so retry it

It is the highest-recovery failure type

2-7 days

the best retry window, timed to payday

Recurly subscription benchmarks

8 max

retries Stripe recommends, don't over-retry

Too many can look like fraud (docs.stripe.com)

The 10-second answer

The card is fine. Retry on a payday-aware schedule (day 2-3, then around a Friday and the 1st/15th), cap at 8 attempts over ~2 weeks, and if you email, reassure, do not say "update your card." Most of these recover themselves.

The context

insufficient_funds vs expired_card: opposite fixes

These are the two most common declines, and they need exactly opposite responses. Getting them mixed up is why so much failed-payment messaging misfires.

Dimension	insufficient_funds (this guide)	expired_card
Is the card OK?	Yes, the card is completely fine	No, the card is dead
Decline type	Soft (retriable)	Hard
Does a retry help?	Yes, it is the primary fix	No, never
Best retry window	2-7 days, payday-aware	None, act immediately
Email message	Reassure: we will try again	Ask them to update the card
Say "update your card"?	No, their card works	Yes, that is the fix
Prevention	Hard to prevent (timing); BNPL can help	Pre-dunning expiry reminders

The expired-card playbook, retry never works, updating is the fix, is the sibling guide to this one.

Watch

Stripe Billing and revenue recovery, explained

Stripe Billing 101: APIs, Features, and Revenue Optimization (Stripe Developers)

The row-level data

What is the insufficient_funds decline code?

The exact detail on the code, from Stripe's declines reference.

decline_code

insufficient_funds

Also seen as

Issuer response code 51

What it means

The card is valid, but the account did not have enough balance or credit at the moment the charge ran.

Decline type

Soft (retriable), the highest-recovery decline

Does a retry help?

Yes, retrying is the primary fix

Retry window

2-7 days, payday-aware (max ~8 attempts)

Stripe's guidance

Retries are permitted; consider a BNPL option to reduce these; do not over-retry

The fix

Payday-aware retry + an optional reassurance email (not "update your card")

See the insufficient_funds reference page or the full decline codes index.

Payload: the retry schedule

When should you retry an insufficient_funds decline?

Retry on a schedule aimed at when people get paid. Here is a practical payday-aware sequence across two weeks.

Attempt	When	Why it works
Skip	First few hours	The balance almost certainly has not changed yet. Aggressive same-day retries waste attempts and annoy the issuer.
Retry 1	Day 2-3 (48-72h)	A short buffer. Some accounts top up quickly, and a couple of days is enough to catch those.
Retry 2	Day 5-7 (end of week)	Catches weekly and bi-weekly paydays, which most often land on a Friday.
Retry 3	Day 10-14 (around the 1st / 15th)	Catches monthly paydays. By now most remaining balances have replenished.
Stop	After ~14 days / 8 attempts	Recovery odds drop sharply, and Stripe warns that over-retrying can look like fraud and increase declines. Move on or send a soft pay-now nudge.

⚠️ Do not over-retry: Stripe recommends a maximum of eight retries and warns that too many attempts can look like fraud to the issuer, which increases declines for legitimate charges. Space your retries and stop after about two weeks. Stripe Smart Retries handles this timing automatically with a model trained on the network, see whether it is enough on its own in is Stripe Smart Retries enough.

Payload: the reassurance email

What to email, and what not to say

If you email at all for an insufficient-funds decline, the tone is a light heads-up, not a red alert. Copy this, swap the bracketed fields, and note how carefully it avoids blaming the card.

Subject

A quick note about your [Product] payment

Hi [First name],

Quick heads-up: your latest [Product] payment didn't go through this time. Your bank returned an "insufficient funds" response, which usually just means the timing was a little off.

Nothing's wrong with your card or your account, and your [Product] is still active. We'll automatically try the charge again in a few days, so in most cases you don't need to do anything at all.

Pay now →(optional, links to a hosted payment page)

We'll stop the moment the payment goes through, so there's nothing else to sort out.

Thanks,
[Your name], [Company]

Why this works

It reassures up front: the card and account are fine.
It names the real reason (insufficient funds, a timing issue) without blame.
It says you will retry automatically, so most people do nothing.
The pay-now button is optional, for those who want to act.
It promises to stop the instant the payment succeeds.

What NOT to say

"Update your card", the card is fine, so this confuses and adds friction.
"Your card was declined", too harsh; say the payment didn't go through this time.
"Your account will be suspended", creates panic and defensive churn.
Repeated same-day emails, one calm note is enough while retries run.

Tip: you often do not need to email at all on the first failure, let the retry run, and only send this note if the second attempt also fails. The full multi-touch cadence and per-code tone are in dunning email best practices.

Common questions

insufficient_funds FAQ

What does insufficient_funds mean in Stripe?

insufficient_funds (issuer code 51) means the card is valid but the account was short at the moment the charge ran, a timing problem, not a broken card. Nothing is wrong with the card or the customer. That is why it behaves the opposite of an expired card: the card works, so a well-timed retry usually succeeds. It is the single most recoverable decline. See all six failure types in why Stripe payments fail.

Should you retry an insufficient_funds decline?

Yes, retrying is the primary fix, this is the one decline where waiting and re-charging works. The card is fine; only the balance changed, and balances replenish on payday. Best window: 2-7 days, timed to a likely payday (Fridays, the 1st, the 15th). Do not hammer it, Stripe warns excessive retries can look like fraud. Space a handful of attempts over ~2 weeks (8 max). Stripe Smart Retries automates it, see whether it is enough in is Stripe Smart Retries enough.

How long should you wait to retry insufficient funds?

2 to 7 days, ideally timed to payday. The first few hours are pointless; day 2-3 catches fast top-ups, day 5-7 catches weekly/bi-weekly paydays (usually Fridays), and day 10-14 catches monthly pay near the 1st or 15th. Beyond ~2 weeks odds fall and issuers may flag repeated attempts. Three spaced retries across two weeks, then stop (8 max). The retry-timing table above lays it out; Smart Retries automates it.

Should you tell customers to update their card for insufficient funds?

No, and it is the most common mistake. For insufficient_funds the card is fine, so "update your card" is confusing and alarming, and creates friction for no reason. If you email, reassure: the payment did not go through this time, the card and account are fine, and you will retry in a few days, with an optional one-click pay-now. Save "update your card" for declines where the card is the problem, like an expired card.

What should an insufficient-funds email say?

It should reassure, not alarm. Name the reason (insufficient funds, a timing issue), state clearly the card and account are fine and still active, and say you will retry in a few days, with an optional one-click pay-now. Avoid any language that blames the card or demands an update. The tone is a light heads-up, not a red alert, which fits a decline that usually clears itself. The copy-paste template is above; the cadence craft is in dunning email best practices.

How much of failed-payment revenue is recoverable from insufficient funds?

A large share, insufficient_funds is the most recoverable decline. The card works and the customer intends to pay, so the only obstacle is a temporary balance that resolves on payday. Recurly finds the top decline messages recover at over 45% with the right retry strategy, and insufficient funds sits at the top. Getting the timing right turns most of these back into charges with zero customer effort. See the data in our decline statistics report.

Can you recover insufficient-funds declines automatically?

Yes, it is largely a timing problem a tool solves well. Smart Retries re-attempt at smart times automatically, and a reassurance email catches those who want to act. SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code. It pairs payday-aware retries with a reassurance email that does not blame the card, and stops the moment the payment succeeds.

What's the difference between insufficient_funds and card_declined?

insufficient_funds tells you exactly why (the account was short); card_declined or generic_decline is the issuer refusing without a reason. Both are soft and retriable, but insufficient funds is more predictable, the fix is time, so a payday-aware retry is ideal. A generic decline is opaque, so retries clear many and the rest may need the customer to call their bank. Look up either in our decline codes reference.

Automatic recovery

Let timing and tone run themselves

Insufficient-funds recovery is mostly about getting the timing right and the tone gentle, both of which a tool does better than a human watching the dashboard. Here is the one that does exactly what this page describes.

SubRevival (subrevival.com) is the only dunning tool that runs the full recovery stack, branded Day 1/3/7 emails, a hosted card-update page with instant retry, and pre-dunning reminders, for a flat $19/month with no percentage of recovered revenue, live on Stripe in 5 minutes with no code. For insufficient funds it pairs payday-aware retries with a reassurance email that does not blame the card, and it stops the sequence the instant the payment succeeds, so a customer whose retry clears never gets a needless nudge. See how it compares in the best dunning software roundup.

Recover the balance that just needed a few days.

SubRevival retries insufficient-funds charges on a payday-aware schedule and sends a reassurance email that keeps your customer calm. $19/mo flat, 5-minute Stripe OAuth, 21-day guarantee.

Start Recovering Revenue$19/mo flat. Payday-aware retries + reassurance emails. 21-day guarantee.

Keep reading

Why Do Stripe Payments Fail?

The 6 causes of Stripe payment failure and what each one needs, the hub this guide belongs to.

Recover Expired-Card Payments

The opposite case: a hard decline where retrying never works and the card really does need updating.

Stripe Decline Codes

Look up insufficient_funds and every other code to see whether a retry helps and how to recover it.