Stripe Decline Code · Glossary
stolen_card is a permanent hard decline fired when the issuing bank has been notified that the card was stolen — every future charge attempt against that card number is blocked at the network level, forever.
What It Means
What It Means
stolen_card is a permanent hard decline fired when the issuing bank has been notified that the card was stolen — every future charge attempt against that card number is blocked at the network level, forever. Like lost_card, Stripe's official guidance is explicit: never reveal this specific reason to the customer — the person attempting the transaction may be the thief themselves, and disclosing the code enables social engineering and fraud escalation.
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
✕ Absolutely never disclose the stolen_card code to the user
This is Stripe's strongest official mandate across all decline codes. Display it as a generic payment failure only. If the person attempting the transaction is the thief, revealing the stolen_card status hands them critical intelligence — confirming the card is flagged, giving them time to pivot to a different stolen card before you can react.
✕ Don't retry — not once, not ever
stolen_card is among the hardest of hard declines. The card is permanently blocked at the card network level — no timing logic, no payday cycle, no smart retry algorithm changes this. Retrying wastes API calls, degrades your merchant health signal with card networks, and delivers a 0% success rate.
✕ Don't apply the same workflow as lost_card
While lost_card and stolen_card are siblings, stolen_card carries a meaningfully higher fraud signal — especially on new accounts. Your internal triage logic must treat stolen_card as fraud-first, customer-second, rather than the other way around. Applying an identical, customer-friendly outreach workflow to both codes without fraud screening first exposes your platform to abuse.
Retry Timing
Retry Timing
Zero retries. Zero retry scheduling. Full stop. Every second of your operational effort goes into two parallel tracks: internal fraud triage and (where appropriate) customer outreach to capture a new payment method.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate | 10–15% |
| Recovery from legitimate customers (card replaced) | 25–35% of the recoverable subset |
| Recovery via alternate payment method | +8–10% additional lift |
| Recovery with blind retries | ~0% |
| Non-recoverable (fraud / true theft) | ~65–75% of all occurrences |
| Median recovery window (legitimate customers) | 3–7 days |
A 12–15% overall recovery rate on stolen_card is the realistic ceiling. The majority of occurrences are non-recoverable — either fraud attempts or genuine theft where the card is gone for good. Your recovery lever is exclusively speed of neutral outreach to the legitimate customer segment — the faster you get them to add a replacement card or alternate method, the better your recoverable-subset conversion.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe stolen_card decline code mean?
The stolen_card decline code means the customer's issuing bank has flagged the card as reported stolen, permanently blocking all future charge attempts at the network level. Stripe requires merchants to never disclose this specific reason to the customer — it must be presented as a generic payment decline.
What are the most common causes of a stolen_card error in Stripe?
Common causes include the legitimate cardholder reporting the card stolen and receiving a replacement with new details, the bank proactively flagging the card after detecting a theft pattern, a fraudster testing stolen card data against your checkout, or an old stolen card number remaining on file in Stripe after the customer received a replacement card.
Should I tell my customer their card was reported stolen?
No. Stripe's official guidance is to never reveal the stolen_card reason to the person attempting the transaction. If the person is the thief, disclosing the code enables further fraud. Always present it as a generic payment failure and direct them to update their payment method.
Should I retry a payment after a Stripe stolen_card decline?
Never. stolen_card is a permanent hard decline with a 0% retry success rate. The card is blocked at the network level. Add this code to your retry engine blocklist immediately and focus all recovery effort on getting legitimate customers to add a new payment method or alternate payment option.
What is the recovery rate for Stripe stolen_card failures?
The overall recovery rate for stolen_card is 10–15%, one of the lowest of all Stripe decline codes. Among confirmed legitimate customers who simply need to update to their replacement card, 25–35% recovery is achievable. The majority of stolen_card occurrences involve fraud attempts or true card theft that are not recoverable.
What to do next
You are here
stolen_card
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 stolen_card 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.