Reference · 2026
Every Stripe decline carries a code that tells you exactly why it failed, whether retrying will help, when to retry, and what to say to the customer. This is the complete 2026 encyclopedia: 30+ codes categorized, recovery rates benchmarked, and retry cadences specified for each one.
Quick answer
A Stripe decline code is a machine-readable string returned when a payment is refused — by the issuing bank, Stripe's risk engine, or the card network. Codes classify the failure: insufficient_funds is soft and retriable; do_not_honor is a hard decline and retry-unsafe. Retrying hard declines increases issuer blacklist risk. There are 34 distinct Stripe decline codes. Understanding each code's retry profile is the foundation of intelligent dunning logic.
The Signal
The Signal
Stripe's decline code system is the most information-rich signal your billing infrastructure generates. Each code tells you exactly why a payment failed, how severe the failure is, whether retrying will help, when to retry, and what to say to the customer.
Treating every decline the same way — retrying at fixed intervals, sending the same dunning email, giving up at the same threshold — is the single most expensive mistake in subscription billing.
Recovery with generic handling
30–40%
Recovery with code-specific logic
55–85%
Codes covered by Stripe native
~10
Codes covered by Recurflux
30+
The Most Important Concept
Soft declines are temporary. Hard declines are permanent. Retrying a hard decline on the same card is actively harmful — it can trigger issuer-side blocks affecting your entire Stripe account.
| Dimension | Soft Decline | Hard Decline |
|---|---|---|
| Card status | Valid and active | Unusable without customer action |
| Root cause | Temporary (funds, network, limits) | Permanent (expired, fraud, closed) |
| Retry appropriate? | Yes — recommended | No — harmful |
| Recovery strategy | Code-specific retry cadence | Dunning email → customer action |
| Recovery rate | 55–70% with optimized timing | 35–45% (customer must act) |
Part 1
Soft Declines
55–70% recovery opportunity
Part 1 — Soft Declines
Soft declines are temporary failures. The card is valid, the account is active, and something transient prevented authorization. The key word is code-specific — an insufficient_funds decline and a processing_error decline are both soft, but require completely different retry strategies.
insufficient_funds
20–40% of failures
55–70%
Most customers get paid on the 1st or 15th. An insufficient_funds decline on the 28th isn't a lost payment — it's a payment 3 days early.
Optimal cadence
24h → 72h → 7d/payday → 14d
do_not_honor
40–65% of failures
45–60%
The issuer declined without saying why. Behind this code lies a spectrum of transient causes — fraud resets, daily limits, system errors. Use a broad-spectrum escalating cadence.
Optimal cadence
24h → 72h → 7d → 14d
processing_error
1–3% of failures
70–85%
Not a customer issue at all — a transient network glitch. The charge would almost certainly succeed if retried immediately. Waiting 24 hours abandons 70%+ of recoverable revenue.
Optimal cadence
Immediate → 1h → 4h
Complete Soft Decline Reference
| Decline Code | % of Declines | Description | Optimal Retry Cadence | Recovery Rate |
|---|---|---|---|---|
| insufficient_funds | 20–40% | Insufficient balance | 24h → 72h → 7d/payday → 14d | 55–70% |
| do_not_honor | 40–65% | Generic issuer rejection | 24h → 72h → 7d → 14d | 45–60% |
| card_declined | 5–15% | Generic card decline | 24h → 72h → 7d | 40–55% |
| try_again_later | 2–5% | Temporary issuer issue | 24h | 50–65% |
| processing_error | 1–3% | Network/processor error | Immediate → 1h → 4h | 70–85% |
| issuer_not_available | 1–2% | Issuer system unreachable | Immediate → 2h | 65–80% |
| approve_with_id | 1–2% | Requires phone approval | Immediate | 30–50% |
| transaction_not_allowed | 1–2% | Transaction type restricted | 24h → 72h | 25–40% |
| card_velocity_exceeded | 2–5% | Frequency/amount limit hit | 24–48h | 35–50% |
| reenter_transaction | 0.5–1% | Issuer suggests retry | Immediate | 50–65% |
| authentication_required | 2–5% | 3DS/SCA auth needed | After 3DS flow completes | 60–80% |
| duplicate_transaction | 0.5–1% | Recent identical charge | After dedup window | N/A |
| new_account_information_available | 0.5–1% | Card updated by network | Via Card Account Updater | 80–90% |
| withdrawal_count_limit_exceeded | 1–2% | ATM/withdrawal limit hit | 24–48h | 30–45% |
Part 2
Hard Declines
Customer action required
Part 2 — Hard Declines
Hard declines are permanent failures. The moment a decline is classified as hard, stop all retry attempts and immediately activate the dunning sequence.
Cardinal Rule
Never retry a hard decline on the same card. Excessive retries signal velocity abuse to Stripe's risk systems and can trigger issuer-side blocks affecting all merchants in your Stripe account.
Complete Hard Decline Reference
| Decline Code | % of Failures | Description | Recovery Action | Recovery Rate |
|---|---|---|---|---|
| expired_card | 5–10% | Card expiration passed | Card Health Monitoring → Hosted Portal link | 35–55% (+ 80–90% prevention) |
| incorrect_cvc | 1–2% | CVC/security code mismatch | Immediate update request email + portal | 40–55% |
| incorrect_number | 0.5–1% | Invalid card number | Immediate update request email + portal | 35–50% |
| incorrect_zip | 0.5–1% | Postal code mismatch | Billing address update prompt | 35–50% |
| incorrect_address | 0.5–1% | AVS verification failed | Billing address update prompt | 35–50% |
| card_not_supported | 0.5–1% | Card type not accepted | Alternate payment method suggestion | 25–40% |
| fraud | 1–3% | Fraud detection triggered | No retry; generic decline + portal | 5–15% |
| stolen_card | 0.5–1% | Card reported stolen | No retry; generic decline + portal | 5–10% |
| lost_card | 0.5–1% | Card reported lost | No retry; generic decline + portal | 5–10% |
| invalid_account | 0.5–1% | Account closed/invalid | New payment method request | 15–25% |
| not_permitted | 0.5–1% | Transaction not permitted | Customer contact required | 15–25% |
| restricted_card | 0.5–1% | Card usage restricted | New payment method via portal | 20–30% |
| currency_not_supported | 0.5–1% | Currency not accepted | Currency/payment method change | 25–40% |
| pickup_card | 0.5–1% | Card flagged for pickup | No retry; customer contact required | 0–5% |
| pin_try_exceeded | 0.1–0.5% | PIN attempts exceeded | Different payment method required | 15–25% |
Part 3
Network Codes
The layer behind Stripe's labels
Part 3 — Network Codes
Stripe translates raw two-digit issuer response codes into human-readable decline codes. The original numeric code is available via the network_decline_code field — and it provides granularity that matters.
When Stripe returns card_declined with no further context, checking network_decline_code reveals whether the issuer code was 01 (soft, retry appropriate) or 85 (also soft, but with different recovery dynamics).
| Issuer Code | Meaning | Stripe Mapping | Type |
|---|---|---|---|
| 01 | Refer to issuer | card_declined | Soft |
| 05 | Do not honor | do_not_honor | Soft |
| 06 | General error | processing_error | Soft |
| 12 | Invalid transaction | transaction_not_allowed | Soft |
| 13 | Invalid amount | invalid_amount | Hard |
| 14 | Invalid card number | incorrect_number | Hard |
| 30 | Format error | incorrect_number | Hard |
| 34 | Suspected fraud | fraud | Hard |
| 41 | Lost card | lost_card | Hard |
| 43 | Stolen card | stolen_card | Hard |
| 51 | Insufficient funds | insufficient_funds | Soft |
| 54 | Expired card | expired_card | Hard |
| 55 | Incorrect PIN | incorrect_pin | Hard |
| 57 | Transaction not permitted | transaction_not_allowed | Soft |
| 61 | Exceeds withdrawal limit | withdrawal_count_limit_exceeded | Soft |
| 65 | Exceeds frequency limit | card_velocity_exceeded | Soft |
| 85 | No reason to decline | card_declined | Soft |
| 91 | Issuer inoperative | issuer_not_available | Soft |
| N7 | CVV2 mismatch | incorrect_cvc | Hard |
| R1 | Stop recurring payment | revocation_of_authorization | Hard |
Part 4
ACH Return Codes
Bank debit failures
Part 4 — ACH Return Codes
ACH direct debit payments face a separate taxonomy with a critical operational difference: ACH returns can be initiated up to 60 days after the original transaction. This makes dispute risk management significantly more complex than card payments.
ACH Warning
R05 (unauthorized debit) and R10 (customer advised not authorized) carry chargeback implications that can impact your dispute ratio — even though they appear as ACH returns, not card disputes.
| ACH Code | Description | Type | Recovery Action |
|---|---|---|---|
| R01 | Insufficient funds | Soft | Retry after 3–5 business days |
| R02 | Account closed | Hard | Dunning → new bank account request |
| R03 | Account not found | Hard | Verify account details with customer |
| R04 | Invalid account number | Hard | Immediate update request |
| R05 | Unauthorized debit | Hard | Verify authorization; re-authorization required |
| R06 | Returned per ODFI request | Varies | Investigate with Stripe support |
| R07 | Authorization revoked | Hard | Customer must re-authorize |
| R08 | Stop payment order | Hard | Customer must re-authorize |
| R09 | Uncollected funds | Soft | Retry after funds clear (3–5 days) |
| R10 | Customer advised not authorized | Hard | Customer dispute process |
| R16 | Account frozen | Soft | Customer must contact bank; retry after 5–7 days |
| R20 | Non-transaction account | Hard | Customer must use checking account |
| R29 | Corporate customer not authorized | Hard | Verify corporate authorization documentation |
Part 5
Test Cards
Simulate every decline
Part 5 — Test Cards
Building a payment recovery system without testing every decline scenario is the engineering equivalent of skipping QA. Use these Stripe test card numbers to validate your retry logic, dunning triggers, and portal flows before going live.
| Card Number | Decline Type | Stripe Code | What to Test |
|---|---|---|---|
| 4000 0000 0000 0002 | Generic decline | card_declined | Standard retry cadence |
| 4000 0000 0000 9995 | Insufficient funds | insufficient_funds | Payday-aligned retry logic |
| 4000 0000 0000 9987 | Lost card | lost_card | No-retry + dunning activation |
| 4000 0000 0000 9960 | Stolen card | stolen_card | No-retry + generic decline messaging |
| 4000 0000 0000 0069 | Expired card | expired_card | Card Health Monitoring + portal link |
| 4000 0000 0000 0127 | Incorrect CVC | incorrect_cvc | Immediate update email |
| 4000 0000 0000 0119 | Processing error | processing_error | Immediate → 1h → 4h sequence |
| 4242 4242 4242 4241 | Wrong card number | incorrect_number | Update portal flow |
| 4100 0000 0000 0019 | Velocity exceeded | card_velocity_exceeded | Frequency cap + delayed retry |
| 4000 0000 0000 0341 | Charge fails after attach | card_declined | Webhook-triggered retry |
Part 6
Classification
Recurflux's 4-bucket system
Part 6 — Classification
Recurflux's Smart Retry engine classifies every incoming decline into one of four recovery buckets in real time — the moment the Stripe webhook fires. This classification drives everything: retry timing, dunning channel, escalation logic, and final disposition.
Immediate Retry
70–85%
Retry within minutes
Scheduled Retry
45–65%
Code-specific cadence
Customer Action
35–55%
Dunning email + Hosted Portal
No Recovery
0–5%
Generic decline notice only
Coverage Comparison
| Tool | Decline Codes Covered | Generic Fallback | Recovery Ceiling |
|---|---|---|---|
| Stripe Smart Retries | ~10 core codes | Yes (most codes) | 30–40% |
| Stunning / Churn Buster | 10–15 codes | Yes | 45–55% |
| Churnkey | 15–20 codes | Yes | 50–60% |
| Recurflux $20 (Founder) | 30+ codes | No | 50–65% |
| Recurflux $59 (Rise) | 30+ codes | No | 55–70% |
| Recurflux $159 (Surge) | 30+ codes + fraud det. | No | 60–75% |
FAQ
FAQ
What are Stripe decline codes?
Stripe decline codes are standardized string identifiers returned when a payment fails, identifying the specific reason — such as insufficient_funds, expired_card, or do_not_honor. Each code appears in the decline_code field of a Stripe Charge or PaymentIntent object and determines the optimal recovery strategy.
What is the difference between a soft decline and a hard decline in Stripe?
A soft decline is a temporary failure where the card is valid but the authorization failed for a transient reason (insufficient funds, network error). Retrying is recommended and recovers 55–70% of cases. A hard decline is permanent — the card is expired, lost, stolen, or blocked — and retrying is actively harmful. Recovery requires customer action via dunning emails.
What does do_not_honor mean on Stripe?
do_not_honor is the issuer's generic catch-all rejection — the bank declined the transaction without providing a specific reason. It accounts for 40–65% of all Stripe declines and is best handled with an escalating retry schedule at 24h, 72h, 7d, and 14d intervals, covering the most likely transient causes including fraud detection resets and daily spending limit cycles.
Why should I never retry a hard decline?
Retrying a hard decline — a card that's expired, stolen, or permanently blocked — signals velocity abuse to Stripe's risk systems and the issuing bank. Excessive retries on a permanently declined card can trigger issuer-side blocks that affect all merchants processing through the same Stripe account.
What is a network_decline_code and how does it differ from decline_code?
The decline_code is Stripe's human-readable translation of the raw issuer response. The network_decline_code is the original two-digit numeric code from the card network — it provides granularity that Stripe's mapping obscures. For example, card_declined could be issuer code 01 (soft, retry appropriate) or 85 (no reason given, also soft but with different recovery dynamics).
How does Recurflux handle 30+ decline codes differently from Stripe Smart Retries?
Stripe Smart Retries uses a single ML model applied broadly across codes. Recurflux classifies every incoming decline into one of four buckets in real time and applies individually optimized retry cadences for 30+ codes — including edge cases like card_velocity_exceeded, authentication_required, and approve_with_id that generic cadences handle poorly.
Related Features
Related Features
Smart payment retry →
Code-specific retry cadences for 30+ decline codes — not generic Stripe retries.
Dunning email sequences →
Adaptive 5-step sequences that vary by decline code, tier, and subscription value.
Card health monitoring →
Pre-expiry scanning at 30/15/7 days to stop failures before they start.
Run the Numbers
Run the Numbers
Wrong retry timing on a single soft decline destroys recovery probability. See what the right window is — and what the failures are costing you.
Retry Timing
insufficient_funds has a different optimal retry window than do_not_honor. One algorithm for both leaves money behind.
Get the exact retry schedule for each decline code type — not a single generic cadence for all 30.
Find my window →Revenue at Risk
How much have your decline codes cost you this month?
Enter your MRR and failure rate. Get the exact monthly revenue that failed — before any recovery attempt.
Calculate →ROI Calculator
30 codes. Most teams handle them all the same way. The ones that don't recover 25–35% more.
See what code-specific handling is worth at your MRR and failure rate — before you decide if it's worth building.
See the ROI →Put It Into Practice
Recurflux's Smart Retry engine handles all 30+ decline codes with individually optimized strategies — payday-aligned retries for insufficient_funds, immediate retries for processing_error, and zero retries for fraud codes. From $20/month (Founder, up to $10K MRR).