What does "blocked by a Radar rule due to a high risk of fraud" mean?

It means Stripe Radar — the fraud system built into Stripe — scored the payment as too risky and stopped it before it reached the card network, so no charge was created. The block comes from either Radar's built-in protection (which blocks payments it rates at the 'highest' risk level by default) or a custom rule you or your team wrote. The cardholder only sees a generic 'your card was declined' message; the real reason is visible to you in the Stripe Dashboard on the payment's risk details.

Why is Stripe blocking legitimate payments?

Radar uses a machine-learning model plus any rules you have configured. False positives usually come from one of: a custom rule that is too broad (for example blocking an entire country, or any IP-country mismatch — which catches travelers and VPN users), the built-in model rating an unusual-but-real customer at the highest risk level, or repeated retries from one customer tripping a velocity rule. Open the blocked payment in the Dashboard and read the outcome reason and the rule that fired to see which it was.

How do I unblock a payment that Stripe Radar blocked?

You cannot un-block the specific charge that already failed — it was never sent to the network, so the customer has to attempt the payment again. To stop the next attempt from being blocked, open the payment in the Dashboard and use 'Add to allow list' to allow that card fingerprint or email address, or remove/adjust the custom rule that blocked it. Then ask the customer to retry. Allow-listing affects future payments only; it does not retry the current one.

Can I turn off Stripe Radar blocking?

You can delete or edit the custom rules you created, but you cannot switch off Radar's built-in block of the 'highest' risk band on standard Radar — that protection is always on. The right move is rarely to disable blocking (that invites fraud and chargebacks); it is to tune it. With Radar for Fraud Teams you can replace blunt 'block' rules with 'review' or 'request 3D Secure' rules so borderline payments are authenticated or queued for a human instead of rejected outright.

What does the customer see when Radar blocks their payment?

A generic decline — typically 'Your card was declined.' Stripe deliberately does not tell the customer the payment was flagged for fraud, because revealing fraud logic helps fraudsters. That is why a real customer who was blocked by mistake will often just say their card 'didn't work' with no further detail; the actual reason (risk level, rule, risk score) lives in your Dashboard and the charge's outcome object, not on the customer's screen.

Payments & Fraud Guide

"Blocked by a Radar rule due to a high risk of fraud"

Stripe stopped a payment and told you it was a fraud risk — but the customer swears the card is fine. Here's exactly what that message means, how to find the real reason in 60 seconds, how to let a legitimate customer through, and how to stop the false positives without switching off the protection that's keeping chargebacks off your account.

By Georges Rayess · Updated 30 June 2026 · 8 min read

What the message actually means

Stripe Radar is the fraud-detection system built into every Stripe account. On each payment it runs a machine-learning model that scores hundreds of signals — card details, IP address, device, email, the network's history of that card — and assigns a risk level. When a payment is blocked "due to a high risk of fraud," Radar rated it at the highest risk level (or a rule you configured told it to block), and stopped the charge before it ever reached the card network. No money moved; no charge was created.

There are only two things that can block a payment in Radar:

Radar's built-in protection. By default, Stripe blocks any payment it scores at the highest risk level. This is always on, on every Stripe account, and you can't disable it.
A custom rule. A rule you (or whoever set up your Stripe) wrote — e.g. "block if the card country doesn't match the IP country." If the message names a specific rule, that's a rule on your account, not Stripe's default.

Key point: the customer never sees any of this. Stripe shows them a generic "Your card was declined" and deliberately hides the fraud reason — telling fraudsters why they were caught would help them adapt. So a real customer who got blocked by mistake will just tell you their card "didn't work." The actual reason lives in your Dashboard.

Find out why — read the charge outcome

Before you change anything, find the exact reason. Open the payment in the Stripe Dashboard (Payments → click the failed payment) and look at the risk section, or inspect the charge's outcome object via the API. A Radar block looks like this:

"outcome": {
  "type": "blocked",
  "reason": "highest_risk_level",
  "risk_level": "highest",
  "risk_score": 92,
  "seller_message": "Stripe blocked this charge as too risky.",
  "network_status": "not_sent_to_network"
}

Three fields tell you everything:

Field	What it tells you
`type`	blocked = stopped outright. manual_review = held for you to decide (Radar for Fraud Teams). authorized = let through.
`reason`	highest_risk_level = Radar's built-in model blocked it. If a custom rule fired, the payment names the rule that triggered instead.
`risk_level` / `risk_score`	highest / elevated / normal. The 0–99 score is only visible on Radar for Fraud Teams; on standard Radar you see the level but not the number.

If reason is highest_risk_level, the ML model blocked it. If it names one of your rules, a rule did. That distinction decides your fix.

If it's a legitimate customer (a false positive)

Genuine customers do get caught — travelers whose card and IP countries differ, VPN users, a first-time buyer with a thin history, or someone who retried three times and tripped a velocity rule. Here's how to let them through:

Add them to your allow list. Open the blocked payment and click Add to allow list to allow that card fingerprint or email on future payments. Important: this does not retry the failed charge — the customer has to attempt the payment again. Allow-listing only affects the next attempt.
Fix the rule that blocked it. If a custom rule fired, edit or remove it. Blocking an entire country or every IP-country mismatch is the single most common cause of blocked-but-legitimate payments — those are blunt instruments that catch real buyers.
Swap "block" for "review" or 3-D Secure. On Radar for Fraud Teams you can change a rule from block to request 3-D Secure (authenticate the cardholder and shift fraud liability to their bank) or review (hold for a human) — so borderline payments get a second chance instead of a hard rejection.

Don't just disable protection. Deleting rules or trying to "turn Radar off" to push a payment through trades a blocked sale for a fraud loss and a chargeback later — and chargebacks count against your Visa VAMP / Mastercard ECM ratio. The goal is precision: let the real customer through while keeping the actual fraud out.

If it's actually fraud

Often the block is correct. If the payment looks fraudulent — mismatched details, a disposable email, a card-testing pattern of tiny rapid charges — leave it blocked. If similar fraudulent payments did get through earlier, refund them and mark them fraudulent (in the Dashboard or via the API): that adds the card and email to Stripe's default block lists and trains the model to catch the next one. Card testing in particular is a velocity pattern best stopped with a rule — see Stripe Radar rules that actually reduce chargebacks.

The real fix: tune Radar, don't fight it

A payment getting blocked usually means one of two things: a real fraud attempt (good — that's Radar working), or a rule set that's too blunt for your business. The durable fix is a rule set tuned to your actual fraud patterns and customer base — velocity checks sized to your real purchase cadence, geo logic that doesn't punish travelers, dynamic 3-D Secure on the genuinely risky slice instead of a flat block, and review queues for the grey zone.

Build precise rules from 20 operator-validated patterns with the Stripe Radar Rule Generator.
Learn which rules false-positive and how to size thresholds in the Radar rules guide.
Drill the attribute vocabulary so you can read and write rules fast in the Radar attribute drill.

Blocking real customers — or missing real fraud?

I rebuilt the Radar rule set on a 200K-user subscription app — chargebacks went from 13% to under 1%, and out of Mastercard ECM.

If Radar is blocking good payments, your rules are too blunt; if chargebacks are climbing, they're too loose. The 90-day Chargeback Rescue program rebuilds your Radar rules around your real fraud patterns, adds dynamic 3DS and dispute interception, and tunes the precision so legitimate customers convert while fraud stays out.

Book a Free Consultation →

See the Chargeback Rescue program →

Frequently asked questions

What does "blocked by a Radar rule due to a high risk of fraud" mean?: Stripe Radar — the fraud system built into Stripe — scored the payment as too risky and stopped it before it reached the card network, so no charge was created. The block came from either Radar's built-in protection (it blocks the "highest" risk level by default) or a custom rule on your account. The customer only sees a generic "your card was declined"; the real reason is in your Dashboard. More terms in the glossary.
Why is Stripe blocking legitimate payments?: Usually a custom rule that's too broad (blocking a whole country, or any IP-country mismatch — which catches travelers and VPN users), the built-in model rating an unusual-but-real customer at the highest risk level, or repeated retries tripping a velocity rule. Open the blocked payment and read the outcome reason and the rule that fired to see which.
How do I unblock a payment Stripe Radar blocked?: You can't un-block the charge that already failed — it never reached the network, so the customer must try again. To stop the next attempt being blocked, use "Add to allow list" on the payment to allow that card or email, or remove/adjust the rule that blocked it, then ask the customer to retry. Allow-listing affects future payments only.
Can I turn off Stripe Radar blocking?: You can edit or delete your own custom rules, but you can't switch off Radar's built-in block of the "highest" risk band on standard Radar. The better move is to tune rather than disable: with Radar for Fraud Teams, replace blunt "block" rules with "review" or "request 3-D Secure" so borderline payments are authenticated or queued instead of rejected. Disabling protection just trades a blocked sale for fraud and a chargeback.
What does the customer see when Radar blocks their payment?: A generic "Your card was declined." Stripe intentionally hides the fraud reason from the customer so fraudsters can't learn the logic — which is why a wrongly-blocked real customer just says their card "didn't work." The actual risk level, rule, and score are in your Dashboard and the charge's outcome object.