Stripe Decline Code · Glossary
card_declined is Stripe's master catch-all decline code — it fires when the issuing bank refuses a transaction but doesn't pass back a more specific reason like insufficient_funds or do_not_honor.
What It Means
What It Means
card_declined is Stripe's master catch-all decline code — it fires when the issuing bank refuses a transaction but doesn't pass back a more specific reason like insufficient_funds or do_not_honor. Think of it as the parent code that sits above all other decline types: when Stripe can't map the bank's refusal to a named code, everything falls here by default.
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 treat it like insufficient_funds and blindly retry on a payment cycle schedule
card_declined has a completely different recovery path from funds-related failures. Scheduling Day 3, Day 7, Day 14 retries without diagnosing which sub-reason caused the decline is the most common mistake — and leads to retry waste, issuer flags, and zero recovery on hard-decline sub-types.
✕ Don't send a single generic dunning email and wait
Because card_declined can mean everything from a wrong CVV to a stolen card, a one-size-fits-all "your payment failed" email performs poorly. Your communication has to branch: different message for new customers (higher fraud signal) vs. long-tenure subscribers (more likely a card restriction or data issue).
✕ Don't skip the Stripe Radar check
If the card_declined came from Radar — not the bank — retrying will keep failing regardless of timing. Always inspect outcome.type and outcome.reason in the Stripe charge object before triggering any retry logic.
Retry Timing
Retry Timing
| Attempt | Timing | Rationale |
|---|---|---|
| Radar block | Do NOT retry — investigate rule trigger | Pause; fix Radar rule first |
| Issuer decline (generic) | 1 retry after 24 hrs, then customer action | Day 1, then Day 5 |
| Incorrect card data suspected | Prompt card update immediately | Day 0 — card update CTA |
| Lost/stolen signal | Hard stop — request new payment method | Day 0 — no retry |
| Long-tenure customer, first-time decline | 2 retries then bank-contact email | Day 2, Day 7 |
Global caps for card_declined: Never exceed 3 retry attempts total. This code has a higher hard-decline probability than insufficient_funds, and excessive retries damage your merchant standing with card networks.
card_declined requires a triage-first approach — the retry timing completely depends on the sub-signal you extract from the charge object.
Smart signal: Check outcome.network_status in the Stripe charge object — if it reads declined_by_network, the bank declined it. If it reads not_sent_to_network, Radar blocked it. This single field splits your recovery path into two completely separate workflows.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate (all sub-types) | 25–45% |
| Radar block sub-type recovery | 5–10% (requires rule fix) |
| Issuer generic decline recovery | 30–40% with proper retry + email |
| Recovery via alternate payment method | +18–25% lift on top of retries |
| Recovery without any triage (blind retry) | ~10–15% |
| Share of all Stripe declines | Largest single category |
A 40%+ overall recovery rate on card_declined is achievable only if you split your workflow by sub-signal. Teams that treat card_declined as a monolithic code and run uniform retry logic rarely exceed 20–25% recovery.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe card_declined error mean?
card_declined is Stripe's generic catch-all decline code, returned when the issuing bank refuses a transaction without providing a specific reason, or when Stripe Radar blocks the payment before it reaches the bank. It is the parent code for all card refusals that cannot be mapped to a more specific decline type.
What are the most common causes of a card_declined error in Stripe?
Common causes include bank fraud detection triggering a generic block, a lost or stolen card being silently declined, incorrect card details like a wrong CVV or expiry date, Stripe Radar blocking the transaction internally, card type restrictions for subscriptions or international merchants, and daily spending or velocity limits set by the bank.
Is card_declined a soft or hard decline in Stripe?
card_declined can be either a soft or hard decline depending on the underlying sub-reason. You can determine this by checking the outcome.type and outcome.network_status fields in the Stripe charge object. If Radar blocked it, treat it as a hard decline. If it was a generic issuer decline, it may be retried carefully.
Should I ask customers to update their card when Stripe returns card_declined?
It depends on the sub-reason. For new customers where incorrect card details are suspected, an immediate card update prompt is the right response. For long-tenure customers where a bank restriction is more likely, a bank-contact email is more appropriate. Sending a blanket card-update request for all card_declined failures reduces email performance and adds unnecessary friction.
How many times should I retry a Stripe card_declined failure?
Never exceed 3 retry attempts for card_declined. First check the Stripe charge object's outcome fields to determine if the block came from Radar or the bank. If Radar blocked it, do not retry at all until the rule is reviewed. For issuer declines, retry at Day 1 and Day 5, then pivot to an alternate payment method offer.
What to do next
You are here
card_declined
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 card_declined 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.