foxhound
Sign in

Decline code

Insufficient Funds

`insufficient_funds` means the customer's available balance or credit limit was lower than the charge amount at the moment Stripe attempted it. The card is valid, the account is real, and the customer generally intends to pay. The problem is timing, not trust. This is a soft decline and one of the most reliably retryable codes in Stripe's list.

Back to decline codes
insufficient_fundsRetries automatically
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

For subscription businesses this code is almost always a scheduling mismatch rather than a genuine ability-to-pay problem. Recurring billing fires on a fixed calendar date set at signup. A customer's income, by contrast, arrives on its own schedule: many US employees on biweekly pay are paid on the 1st and 15th, or on Fridays, while employees paid monthly usually see a deposit around month end. If a subscription renewal date happens to land a day or two before payday, the charge can fail even though the money shows up in the account 48 hours later. The customer isn't refusing to pay. The bill just arrived at an awkward moment relative to their cash flow.

How to fix it

Yes, and it tends to resolve with nothing more than better timing. A charge that fails on the 3rd of the month because a paycheck hasn't landed yet often clears cleanly if retried on the 5th or after the next payday window. No customer contact is required to fix a timing problem, and reaching out immediately with a "your card was declined" email can create friction (and occasional churn) over an issue that would have resolved itself in a couple of days. Align retry timing with common payday patterns rather than retrying on a fixed short interval. A retry attempted the same day as the original failure is unlikely to succeed, since the underlying balance problem hasn't changed. A retry attempted a few days later, ideally around the 1st, the 15th, or a Friday, has meaningfully better odds. Avoid emailing the customer on the first failure. Reserve outreach for cases where retries genuinely can't recover the charge after giving payday timing a fair chance to work.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • Not usually. It typically means the charge landed before the customer's next deposit, not that they lack the ability or intent to pay.

  • Many customers get paid around the 1st, the 15th, or on a Friday. A retry timed a few days after the original failure often lands after the customer's balance has replenished.

  • It's usually unnecessary and can create friction over a problem that resolves itself. Retrying with better timing first avoids bothering a customer who was always going to pay.

  • Yes, because subscription billing dates are fixed in advance and don't move with the customer's actual pay schedule, while a one-time purchase is something the customer initiates when they already know they can afford it.

  • Only after its background retry schedule for the charge is exhausted. Before that point, retries happen silently and no email goes out.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit