fraudulent: what this Stripe decline code means and whose suspicion it records
lane: stopfraudulentThe payment was declined because Stripe suspects that it's fraudulent. Stripe's guidance is not to report more detailed information to the customer, and to present it in the same manner as a generic decline.
What it means
The suspicion is about the payment, and Stripe's wording puts it on Stripe's side of the line: the payment was declined because Stripe suspects it is fraudulent. In practice these often carry outcome.type blocked, meaning Radar or Stripe's risk scoring stopped the payment before any issuer saw it, so check outcome before assuming a bank was involved. The neighbouring codes make the contrast: lost_card and stolen_card relay something a cardholder reported about a card, while fraudulent is a judgement about this transaction.
On a fresh checkout that judgement is routine. On a subscription renewal it is strange enough to matter, because the payment being judged is one you have taken before, from an account that has been paying you. The explanations run from dull to serious: a rule written too broadly, a risk score moved by something incidental, an account taken over and given a new card, a relationship that was never what it looked like. The code can't say which, and a renewal wearing this flag is worth a person's attention either way.
Stripe's instruction on messaging is unusually direct: don't report more detailed information to the customer, and present it in the same manner as a generic decline. The logic is that you don't know who you are talking to. If the suspicion is right, a precise reason is feedback for the person causing it. If it is wrong, an email that mentions fraud is a bad thing to send a paying customer. The generic message is right in both worlds.
The verdict leaves a trail. outcome.risk_level is on the Charge, outcome.rule names a rule when one fired, and risk scores appear where the account's Radar plan includes them. If you conclude the payment was legitimate, the Dashboard's allow list lifts the block for future payments; Stripe notes it doesn't retry the one that was stopped.
Why it happens
Stripe's risk scoring
The payment's signals resembled fraud closely enough for Stripe's systems to act. Resembling fraud is not committing it; the code records suspicion, and suspicion is sometimes wrong.
A rule you wrote
A custom Radar rule matched. outcome.rule identifies which one, which makes this the rare decline that comes with its own paper trail.
An account that changed hands
A takeover often shows up as a new card on an old account followed by unusual activity. A renewal flagged as fraudulent can be the first visible symptom, which is an argument for looking at the account and its recent history rather than only at the charge.
A false positive on a good customer
Rules written for one attack catch bystanders. When the same rule keeps flagging renewals you know are sound, the rule is the thing to fix, and outcome.rule says where to look.
Common mistakes
Telling the customer why
Stripe's instruction is explicit: don't report the detail, present it as a generic decline. If the payment was fraud, a precise explanation is a debugging aid for the person committing it. If it wasn't, an accusation of fraud is a terrible email to send a paying customer.
Retrying it
A retry resubmits the same payment to the same verdict. If a rule fired, it fires again, and if the suspicion was right, you are pressing to complete a payment your own tooling flagged. Neither branch improves with repetition.
Treating the allow list as a retry
Adding a payment to the allow list lifts the block for future payments, and Stripe notes it doesn't retry the stopped one. Fix the rule if it needs fixing, allow-list if warranted, then decide about the payment separately.
Filing a flagged renewal with the routine declines
On an established subscription this code is information about the account, and the possibilities include a compromised login and a misfiring rule. It is one of the few declines where a person looking beats any automated response.
How Lirova handles it
Lirova stops on fraudulent: no retry and no email. The stop set is our own judgement, not a rule anyone handed us, and the reasoning for this member is short. A retry replays the payment into the same verdict. An email can't explain itself without breaking Stripe's disclosure guidance, and if the account rather than the card is the problem, a request for new card details invites exactly the wrong thing. So the automation does nothing here, and what happens next is a decision a person makes with the case in front of them.
FAQ
What does the fraudulent decline code mean in Stripe?
Stripe suspects the payment is fraudulent, in the docs' own words, and these often carry outcome.type blocked, meaning Stripe's side stopped the payment before any issuer saw it. It records suspicion rather than proof, and outcome.rule names the rule when one fired.
Should I tell the customer their payment was flagged as fraudulent?
No. Stripe's instruction is to present it in the same manner as a generic decline. If the suspicion is right, detail helps the wrong person; if it is wrong, a fraud accusation is a bad message to send a paying customer. The generic wording covers both.
Should I retry a payment declined as fraudulent?
No automated retry helps: the same payment meets the same verdict. If you believe the payment is legitimate, the path is fixing the rule and using the allow list, then making a deliberate new attempt, and Stripe notes the allow list itself doesn't retry the stopped payment.
How do I stop Radar from blocking a legitimate customer?
Find what fired: outcome.rule identifies a custom rule, and outcome.risk_level shows the scoring. Adjust the rule or your risk settings, and add the payment to the allow list so future attempts pass. The blocked payment itself stays blocked; a new attempt is a separate action.
Is fraudulent the same as the issuer suspecting fraud?
Not quite. Issuers signalling their own suspicion tend to send do_not_honor or a generic response, since explaining their fraud models to merchants is not in their interest. fraudulent is worded as Stripe's suspicion, and the outcome fields usually show Stripe's side acted. Both end in the same generic customer-facing message.
Related codes
Updated 2026-09-01