Stripe Decline Code · Glossary
fraudulent is Stripe's most severe decline code — it fires when either Stripe Radar's machine learning engine or the issuing bank has determined with high confidence that the transaction is fraudulent and must be blocked.
What It Means
What It Means
fraudulent is Stripe's most severe decline code — it fires when either Stripe Radar's machine learning engine or the issuing bank has determined with high confidence that the transaction is fraudulent and must be blocked. Unlike do_not_honor (ambiguous) or stolen_card (card-level flag), fraudulent is a platform-level hard decline that can permanently affect your merchant standing if it appears repeatedly in your charge history. This is not a recoverable payment — it is a security event.
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 — under any circumstances
fraudulent is the hardest hard decline in Stripe's taxonomy. Retrying a fraudulent-blocked charge doesn't just fail — it actively worsens your merchant risk profile with both Stripe and the card networks. Accumulating fraudulent charges in your retry history is a direct path to Stripe account review or termination. Zero retries, zero exceptions.
✕ Don't ignore Radar as the potential source
The single most expensive mistake SaaS founders make with fraudulent is assuming it always means an actual bad actor. A significant percentage — especially for B2B SaaS with international customers — are Radar false positives from overly aggressive rules. Before cancelling a customer or flagging an account, always check outcome.type in the charge object: if it's blocked rather than issuer_declined, the problem is your Radar configuration, not the customer.
✕ Don't display fraudulent to the end user
Like stolen_card and lost_card, never expose this specific code to the customer-facing layer. Surface only a generic decline message. Showing fraudulent to a legitimate customer who triggered a false positive is both confusing and deeply damaging to trust — it tells a real customer you think they're a criminal.
Retry Timing
Retry Timing
No retry timing exists for fraudulent. This code splits into two completely separate operational tracks — and neither involves retrying:
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate | 5–15% |
| Radar false positive recovery (after rule fix) | 60–75% of the false-positive subset |
| Genuine fraud / card testing recovery | ~0% (and should not be attempted) |
| Recovery via manual Radar whitelist | +20–30% lift on legitimate international customers |
| Recovery with blind retries | ~0% |
| False positive rate in Stripe Radar (aggressive rules) | 15–30% of all fraudulent blocks |
Your primary KPI for fraudulent is not recovery rate — it's false positive rate. A well-tuned Radar configuration should have a false positive rate below 10%. If you're seeing fraudulent blocks on known customers, long-tenure subscribers, or customers from specific countries, your Radar rules are too aggressive and you're leaving recoverable MRR on the table.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe fraudulent decline code mean?
The fraudulent decline code means Stripe Radar or the issuing bank has identified the transaction as high-confidence fraud and permanently blocked it. It is the hardest decline code in Stripe's taxonomy — no retry will succeed — and it should never be shown to the end user as-is. Always check whether the block came from Radar or the issuer before deciding on next steps.
What are the most common causes of a fraudulent decline in Stripe?
Common causes include Stripe Radar's ML model scoring the transaction above your block threshold, the issuing bank independently identifying fraud based on spending patterns, an active card testing or carding attack on your checkout, a legitimate customer triggering false positives via VPN or international payment, or elevated chargeback rates causing Radar to tighten its thresholds on your account.
Can a fraudulent Stripe decline be a false positive?
Yes. A significant percentage of fraudulent blocks — particularly on B2B SaaS platforms with international customers — are Radar false positives triggered by overly aggressive rules. Check outcome.type in the Stripe charge object: if it shows blocked rather than issuer_declined, the block came from your Radar configuration, not the bank, and the customer may be entirely legitimate.
Should I retry a payment after a Stripe fraudulent decline?
Never. Retrying a fraudulent-blocked charge does not succeed and actively harms your merchant risk profile with Stripe and the card networks. Add fraudulent to your no-retry blocklist at the automation layer. For Radar false positives on legitimate customers, whitelist the customer in Radar and re-attempt the charge manually after review.
What is the recovery rate for Stripe fraudulent failures?
The overall recovery rate is 5–15%. For genuine fraud and card testing, recovery is effectively 0% and should not be attempted. For Radar false positives — which can represent 15–30% of all fraudulent blocks on aggressively configured accounts — recovery rates of 60–75% are achievable once the Radar rule is adjusted and the customer is whitelisted.
What to do next
You are here
fraudulent
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 fraudulent 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.