Stripe Decline Code · Glossary
When Stripe returns insufficient_funds, the customer's bank declined the charge because their account or card doesn't have enough available balance to cover the transaction amount.
What It Means
What It Means
When Stripe returns insufficient_funds, the customer's bank declined the charge because their account or card doesn't have enough available balance to cover the transaction amount. This is a soft decline — meaning the card itself is valid, the customer is real, and the payment can succeed once funds are available.
Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →
Why It Happens
Why It Happens
What NOT to Do
What NOT to Do
✕ Don't retry immediately (within the same hour)
The single most common mistake is triggering an automatic retry within minutes. The funds aren't there — retrying instantly just racks up failed attempt fees at the issuing bank, increases the chance of the card being flagged, and burns your retry attempts with no upside. Some issuers will soft-block a merchant after 3+ rapid failed attempts on the same card.
✕ Don't send a generic "payment failed" email
Blasting a cold "your payment didn't go through, update your card" email for an insufficient_funds code is wrong messaging — the card is fine. Asking them to update their card creates friction and confusion when all they need is a few days.
Retry Timing
Retry Timing
| Attempt | Timing | Rationale |
|---|---|---|
| Retry 1 | 3 days after failure | Covers weekly paid customers who top up quickly |
| Retry 2 | 7 days after failure | Catches bi-weekly paycheck cycles |
| Retry 3 | 14–15 days after failure | Hits the mid-month or end-of-month salary deposit window |
| Retry 4 (final) | 21–28 days after failure | Last catch before dunning escalation |
Best practice: If you know your customer's billing country, align Retry 3 specifically to local payday norms:
insufficient_funds follows a paycheck cycle logic, not a random window.
* 🇮🇳 India — End of month (25th–1st)
* 🇺🇸 USA — 1st and 15th (bi-weekly common)
* 🇬🇧 UK — Last working day of month
Smart signal: If a customer has historically paid successfully, weight your retry more aggressively. A long-tenure customer hitting insufficient_funds once has a 70%+ chance of self-resolving within 7 days.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate | 60–75% with smart retries |
| Recovery within 7 days | ~45–50% |
| Recovery within 30 days | ~65–72% |
| Recovery with dunning email | +8–12% lift on top of retries |
| Recovery rate without any retry logic | ~20–25% (passive) |
A well-tuned dunning system (smart retry timing + personalized email sequence) should recover 65%+ of insufficient_funds failures. If you're below 50%, your retry timing is likely off or your email copy is asking customers to update a card that doesn't need updating.
At Scale
At Scale
Automated
Manual Escalation
What to do next
You are here
insufficient_funds
Decline code reference
Check recoverability
Stripe Failure Lookup
See what's recoverable — and what isn't →
Then
Sign up for Recurflux
Automate recovery for every decline code →
Before you retry
Before you retry
Most insufficient_funds failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.
Stop leaving revenue on the table
Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.