Every decline code needs a different response.
Not all of them are retryable. Some need customer action. Some need specific timing. Treating them the same is why flat retry schedules underperform.
Stripe sends a code every time a payment fails. Most billing teams look up the code, see "generic decline", and stop there. This tool tells you whether it's a soft decline (retryable) or hard decline (needs a new card), the exact retry window, and the right message to send the customer.
30+
Stripe decline codes with distinct recovery strategies — not one-size-fits-all
2 types
soft declines (retryable) vs hard declines (need new card) — the split matters
24hrs
optimal window to send first dunning email after any type of decline
How codes are classified
How codes are classified
Soft declines are temporary failures. The card is valid — the transaction failed due to a temporary condition like insufficient funds, a bank hold, or a transaction velocity flag. Retrying after the right interval often succeeds. Examples: insufficient_funds, do_not_honor, card_velocity_exceeded.
Hard declines are permanent failures. The card is invalid, lost, stolen, or the account is closed. Retrying without a new payment method will never succeed and may trigger fraud flags. Examples: lost_card, stolen_card, card_not_supported.
Retry windows are derived from card network behavior and issuer response patterns. Insufficient funds retries best at day 3–5 to align with paycheck cycles. Do-not-honor retries best at day 7–10 to allow the issuer risk system to reset. Retrying too early triggers additional hard blocks.
Decline codes, decoded
Decline codes, decoded
Every failed charge comes back from Stripe with a decline code — a short string like insufficient_funds or expired_card that tells you exactly why the bank or card network rejected the payment. Paddle and Razorpay return the same kind of detail in their own formats. The code is the difference between guessing why a renewal failed and knowing — which is what determines whether retrying makes sense, when to retry, or whether you should skip the retry entirely and ask the customer for a new card.
Soft declines — insufficient_funds, do_not_honor, temporary processor errors — are worth retrying because the underlying condition is often gone within days or even minutes. Hard declines — lost_card, stolen_card, card_not_supported — are not. Retrying a hard decline doesn't just fail again; on some issuers it raises a fraud flag that makes the next legitimate charge from your account harder to clear. Checking the code first is what keeps a retry strategy from doing more damage than the original failure.
A retry schedule that treats every failure the same wastes attempts on codes that will never clear and misses the window on codes that would. The pattern that holds up: route soft declines into a staggered retry sequence timed to the reason (insufficient funds clears fastest around payday, do-not-honor needs longer for the issuer's risk system to reset), route hard declines straight into a card-update flow instead of a retry queue, and route technical or processor errors into a near-immediate retry since those tend to resolve in minutes, not days. Lookup tools like this one are the fastest way to classify a code before deciding which lane it goes in.
insufficient_funds fires when the account balance is too low at the moment of the charge — the single most common reason subscriptions fail, and the most recoverable. do_not_honor is the bank's catch-all decline, often triggered by a fraud-risk score rather than an actual problem with the card. expired_card and card_velocity_exceeded show up most around renewal dates and high-volume billing runs. Search any of these — or paste in the exact code your processor returned — to see what it means, whether retrying helps, and when to try again.
Related free tools
Recovery Window Calculator
Find the optimal retry schedule for each failure code
Failed Payment Calculator
Calculate your monthly MRR at risk from billing failures
Payment Recovery ROI Calculator
See the ROI of improving your payment recovery rate
Dunning Email Templates
8 free templates — one per payment failure type
Common questions
Common questions
The fix depends on the decline code. For card_declined with insufficient_funds: retry in 3–5 days, send a dunning email on day 1. For do_not_honor: retry in 7–10 days, notify the customer. For expired_card or lost_card: skip the retry entirely — send a card-update link immediately, retrying will not work. Always check the decline_code sub-field on card_declined, not just the top-level error, as the sub-code determines the correct action.
Retryable codes: insufficient_funds (retry in 3–5 days), do_not_honor (retry in 7–10 days), generic card_declined with no sub-code (retry in 3–7 days). Require a new card: lost_card, stolen_card, fraudulent, card_not_supported, expired_card. Retrying a non-retryable code wastes the attempt and risks triggering fraud detection.
card_declined is a generic decline from the card issuer with no specific reason given. Always check the decline_code sub-field — codes like insufficient_funds are retryable after a few days, while do_not_honor needs a longer wait, and lost_card or stolen_card require a new payment method. The top-level card_declined alone is not enough to decide what action to take.
Retry the payment in 3–5 days to align with common paycheck cycles (bi-weekly or monthly). Send a dunning email on the day of failure, and a reminder before each retry. If the payment fails 3 times on insufficient_funds, prompt the customer to update their card or add a backup payment method — repeated insufficient_funds failures may indicate a card that won't clear regardless of timing.
do_not_honor is a catch-all decline from the bank triggered by risk systems, unusual patterns, or geographic blocks. It is a soft decline — retry in 7–10 days. If it fails twice more, ask the customer to call their bank or update their card. Do not retry more than 3 times — repeated attempts on do_not_honor can trigger fraud flags and get your account flagged by the issuer.
Every failure in your account needs this. Recurflux runs it automatically.
You just decoded one code. Recurflux classifies every failure across your account in real time — routes soft declines to the right retry window, hard declines to card-update flows, and fires the correct sequence for each. From $20/month.