RecoverGuide
The fraudulent decline code on Stripe: who suspects what, and what to say
Last updated 13 August 2026 · written by Bruce McGinley, who builds RecoverFlow
Stripe suspects the payment is fraudulent. That is the documented description, and the emphasis matters: this code is Stripe's own suspicion, not the issuer's.
The documented next step is aimed at you: do not report more detailed information to your customer. Present it in the same manner as a generic_decline.
It is not one of the nine codes that stop Stripe executing retries, so your retry schedule continues to run.
On this page
Three kinds of fraud suspicion, three different codes
Fraud suspicion can come from three places in a card payment, and Stripe's documentation gives each its own surface.
- Stripe suspects fraud: that is
fraudulent, per the decline codes reference. - Your own block list matches: that is
merchant_blacklist, documented as the payment matching a value on the Stripe user's block list, meaning yours. It carries the same instruction to present it as a generic decline. - The issuer suspects fraud: Stripe's card declines guide notes that issuers may decline when they suspect fraudulent activity, and that the customer resolves it by contacting their issuing bank and confirming their identity. Issuer-side suspicion usually surfaces as other codes, since issuers categorize most declines as generic.
Knowing which party said no tells you where the fix lives. For fraudulent, the assessment happened on Stripe's side of the fence.
What to put in the email: nothing specific
The reference gives fraudulent the same handling instruction as lost_card, stolen_card and merchant_blacklist: do not share the detailed reason, present it as a generic decline. Our free decline code lookup flags this whole group, because they are the codes where a well-meaning, transparent dunning email is exactly the wrong move.
If a message goes out at all, it says the payment did not go through and links to a card update page. It does not say fraud. The word does nothing useful for a legitimate customer and does something actively harmful in front of anyone else.
Retries run, but read the payment first
fraudulent is not on the nine code list, so scheduled retries continue to execute. Before leaning on them, open the payment in the Stripe Dashboard and look at what actually happened, since the code tells you Stripe's fraud systems were involved and the payment page carries the detail.
Stripe's card declines guide also documents the general levers for declines that stem from suspected fraud: collect CVC and postal code at checkout, and consider 3D Secure, which can lower decline rates in countries that support it. Those help the next checkout. For a failing subscription renewal, the customer re-entering their card through your dunning link gives the next attempt a fresh, fully verified starting point.
Questions people actually ask
Is fraudulent a hard decline on Stripe?
It is not on Stripe's list of nine codes that stop retry execution, so Stripe retries it on your schedule. The related code highest_risk_level is on that list. Whether a retried payment fares better is a different question: the documented cause is Stripe suspecting fraud, which is not a timing problem.
Should I tell the customer their payment was flagged as fraudulent?
No. Stripe's decline codes reference says not to report more detailed information to the customer and to present it in the same manner as a generic_decline. Send a plain payment-failed message with a card update link if you contact them at all.
What is the difference between fraudulent and merchant_blacklist?
Who owns the list. fraudulent is documented as Stripe suspecting the payment is fraudulent. merchant_blacklist means the payment matched a value on your own Stripe block list. Both carry the same instruction: present as a generic decline.
What is the difference between fraudulent and highest_risk_level?
highest_risk_level appears on the nine code list in Stripe's Smart Retries documentation, so it stops retry execution until a new payment method is added. fraudulent does not appear there, so scheduled retries continue.
Where this came from
Checked against primary sources on 13 August 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe: Decline codes reference — the documented meaning and next steps for every code on this page.
- Stripe: Card declines — advice codes, retry limits, and Stripe's guidance on reducing declines.
- Stripe: Smart Retries — the source for the nine hard decline codes and what happens to scheduled retries after one.
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it can attribute to a specific action it took, with a $29 monthly floor and a $299 monthly ceiling, and the floor is waived for the first 30 days.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and there is a page on this site that says exactly when that is the right call.
See how the pricing works