Stripe Radar false positives: why legitimate payments get blocked and how to fix it

Some links in this article are affiliate links. We may earn a commission if you sign up to Whop through our links, at no extra cost to you. Read our affiliate disclosure.

You launch a course, run a flash sale, or open enrollment on a coaching program. Payments start coming in. Then you check Stripe and notice something strange: a handful of legitimate buyers never made it through checkout. Stripe Radar flagged their transactions as fraudulent and blocked them silently. The customer saw a generic "card declined" message, assumed it was their bank, and left. You never knew they tried to pay. This is the false positive problem, and for creators selling digital products, it is far more common than most people realize.

Stripe Radar is a machine-learning fraud prevention system that screens every transaction processed through Stripe. It is good at catching actual fraud. It is also, in certain verticals, overly aggressive with legitimate transactions. If you sell courses, coaching, paid communities, or info products, your purchase patterns look suspicious to an algorithm trained primarily on e-commerce data. High ticket prices, one-time purchases from new customers, international buyers paying with unfamiliar card types: all of these are normal for your business and abnormal for Radar's baseline model.

This guide covers how to diagnose your false positive rate, understand why creators get disproportionately flagged, and implement specific fixes to stop losing revenue to Radar's overcaution.

How Stripe Radar works

Stripe Radar is a fraud detection layer that sits between the customer's checkout action and the actual payment processing. Every transaction passes through Radar's machine-learning model, which assigns a risk score between 0 and 100. The higher the score, the more likely Radar considers the transaction fraudulent.

Radar's model is trained on data from millions of businesses across the Stripe network. It evaluates signals including:

• Card fingerprint: has this card been used for fraud on other Stripe merchants?
• IP geolocation: does the buyer's IP location match the card's issuing country?
• Device fingerprint: is the buyer using a known device, or a suspicious browser configuration?
• Velocity: how many transactions has this card or email attempted in a short period?
• Email analysis: is the email address disposable, newly created, or associated with previous fraud?
• Behavioral signals: how quickly did the buyer complete checkout? Did they copy-paste the card number (common with stolen cards)?

By default, Radar blocks transactions with a risk score above 75. Transactions scoring between approximately 50 and 75 may be placed in a review queue (if you have Radar for Fraud Teams enabled) or allowed through with a warning flag. Transactions below 50 pass through normally.

The system works well for typical e-commerce: physical goods, moderate price points, repeat customers, domestic shipping. It works less well for the purchase patterns common in creator businesses.

Why creators trigger false positives more than e-commerce sellers

Stripe Radar's training data skews toward traditional e-commerce patterns. When your business deviates from those patterns, the model treats the deviation as a risk signal, even when the transaction is completely legitimate. Here is why creators hit this problem disproportionately.

High ticket prices

A $2,000 coaching package or a $997 course triggers Radar's "unusually high amount" signals. For a typical e-commerce store, a $2,000 single transaction is rare and suspicious. For a creator selling a premium coaching program, it is the standard price. Radar does not know the difference unless you tell it.

One-time purchases from new customers

E-commerce businesses build up a history of repeat buyers. Radar uses this history to establish trust. When a first-time customer buys a $500 course from you, Radar has no prior relationship data to fall back on. Every signal is evaluated cold, which pushes the risk score higher. Creators selling launches (where most buyers are new) see this effect amplified.

International buyers

If you market globally (and most digital product creators do), a significant portion of your buyers will have mismatches between their card-issuing country and their IP location. A buyer in Thailand using a US-issued card, or a European buyer using a VPN, triggers multiple risk signals simultaneously. For an e-commerce store shipping domestically, this pattern would be unusual. For your online course, it is Tuesday.

Launch spikes and irregular volume

Stripe Radar factors in your typical transaction volume. If you normally process 20 transactions per week and then process 200 in a single day during a launch, the sudden spike itself becomes a risk signal. The algorithm interprets volume spikes as potential card-testing attacks, where fraudsters run batches of stolen cards through a merchant. Your launch looks exactly like a card-testing attack to an algorithm that cannot distinguish intent.

The real cost of false declines

False positives are invisible losses. Unlike chargebacks (which show up in your dashboard with dollar amounts attached), false declines happen silently. The customer is turned away. You never see the attempted payment. No notification, no log entry you would naturally check.

The downstream effects compound beyond the immediate lost sale:

• Customer frustration: a declined legitimate buyer rarely tries again. They assume the problem is with their card or your site, and they move on. Some request support, which costs you time. Most simply leave.
• Cart abandonment: false declines during a launch window are especially damaging because the buyer's purchase intent is time-sensitive. If they cannot pay now, they will not come back in two days when the window has closed.
• Reputation damage: in small creator communities, a buyer who gets declined may mention it publicly. "I tried to buy but the payment kept failing" erodes trust in your checkout process.
• Skewed analytics: if you are optimizing your funnel based on conversion rates, false declines distort the data. You might conclude your sales page is underperforming when the real problem is at the payment processing layer.

The relationship between fraud prevention and false declines is a seesaw. Tighter Radar rules catch more fraud but also block more legitimate transactions. Looser rules let more fraud through. The goal is calibration, not maximizing either extreme. For creators, the default calibration is almost always too aggressive.

How to check your Radar false positive rate

Stripe does not label false positives directly (it would require knowing which blocked transactions were legitimate, which Stripe cannot determine after the fact). But you can approximate your false positive rate using the block rate metric.

In your Stripe Dashboard:

1. Navigate to Payments.
2. Click Analytics (or Radar in newer dashboard versions).
3. Look for the Block rate: the percentage of attempted transactions that Radar blocked.
4. Filter blocked payments by status to see individual blocked transactions, including the risk score and the rule that triggered the block.

For most e-commerce businesses, a block rate between 0.5% and 2% is normal. For creator businesses, rates between 3% and 8% are common because of the factors described above. If your block rate exceeds 5%, review blocked transactions manually. You will likely find a significant number that were legitimate buyers.

Also check your review queue if you use Radar for Fraud Teams. Transactions sitting in review that you approve consistently are another indicator that Radar's thresholds are too tight for your business model. If you approve more than 80% of review-queue transactions, your review rules are triggering too broadly.

If you notice that false declines are coinciding with broader account issues (holds, reserves, or compliance inquiries), our guide to Stripe high-risk classification explains how Stripe categorizes businesses and what triggers escalated scrutiny.

Understanding Radar rules: defaults vs. custom

Stripe Radar operates on two layers of rules: default rules that Stripe applies automatically, and custom rules that you write yourself.

Default rules

Stripe's default rules are not publicly documented in full detail, but the primary default is: block transactions with a Radar risk score above 75. This threshold applies to all Stripe accounts unless you override it. Additional default behaviors include blocking cards that have been reported for fraud across the Stripe network and blocking transactions from sanctioned countries.

Custom rules

Custom rules let you override, supplement, or refine Radar's defaults. You write rules using Stripe's rule syntax, which evaluates attributes of the transaction. Rules can result in three actions: Block (reject the transaction), Review (hold for manual approval), or Allow (bypass risk scoring entirely).

Examples of useful custom rules for creators:

• :risk_score: < 65 AND :card_country: = 'US' with action Allow: lets moderate-risk domestic transactions pass without blocking.
• :is_recurring: with action Allow: permits recurring subscription charges from previously approved customers, bypassing risk checks on renewal payments.
• :risk_score: > 50 AND :risk_score: < 75 with action Review: sends borderline transactions to your review queue instead of blocking them, giving you the chance to approve legitimate payments manually.

Custom rules require Radar for Fraud Teams ($0.07 per screened transaction) for full functionality. The free Radar tier supports basic custom rules but does not include review queues or advanced attributes.

5 practical steps to reduce false positives

1. Create allow lists for repeat buyers

In Radar settings, you can add customer email addresses, card fingerprints, or IP addresses to an allow list. Customers on the allow list bypass Radar's risk scoring entirely on future purchases. For creators with membership or community models, this is the single highest-impact change: your existing members should never be blocked on a renewal or upsell purchase.

If you use Radar for Fraud Teams, you can automate this with a rule: :customer_purchases: > 1 with action Allow. This automatically trusts any returning customer.

2. Adjust your default block threshold

Radar's default blocks at a risk score of 75. For creator businesses, raising this to 80 or 85 (via a custom rule that allows transactions scoring below your new threshold) reduces false positives meaningfully. You will accept slightly more risk, but for most digital product businesses, the incremental fraud is far smaller than the recovered legitimate revenue.

Alternatively, change the default action from Block to Review for scores between 65 and 85. This keeps the safety net (you still see flagged transactions) while giving legitimate buyers a path to complete their purchase through manual approval.

3. Route medium-risk transactions through 3D Secure

Instead of blocking transactions with moderate risk scores, route them through 3D Secure (3DS) authentication. Create a Radar rule: if risk score is between 40 and 65, request 3D Secure. The customer gets a verification step (typically a bank app confirmation or SMS code) rather than a decline. If they authenticate successfully, the transaction processes and you receive liability shift protection from the issuing bank.

This approach is particularly effective for high-ticket purchases from new international customers, exactly the scenario where Radar false positives are most common for creators. The customer can prove they are who they say they are without being turned away. For more on using 3DS strategically alongside chargeback prevention, see our chargeback prevention guide.

4. Enrich transaction metadata

Radar's accuracy improves when it has more data about the transaction. Pass additional metadata with each payment intent:

• Customer name and email (via the Customer object, not just the payment)
• Product type (course, coaching, community) via metadata fields
• Customer account age on your platform
• Previous purchase history if you track it

When Radar can see that a buyer has an account on your platform created 30 days ago and has logged in 12 times, the risk score drops compared to an anonymous card-not-present transaction with no context. Use the payment_intent.metadata field to pass this information.

5. Review blocked payments weekly

Set a calendar reminder to review blocked transactions every week. In Stripe Dashboard, filter payments by status "Blocked" and examine each one. Look for patterns:

• Are blocks concentrated on specific countries you sell to regularly?
• Are blocks hitting a specific product or price point?
• Are blocks spiking during launches?

Each pattern you identify is a custom rule waiting to be written. If you see 15 blocked transactions from the UK in a week and you sell to UK customers regularly, that is a clear signal to create an allow rule for UK cards below a certain risk threshold.

When to upgrade to Radar for Fraud Teams

Radar for Fraud Teams costs $0.07 per screened transaction. At 1,000 transactions per month, that is $70. At 10,000 transactions, $700. The question is whether the additional features justify the cost.

Radar for Fraud Teams adds:

• Manual review queues: flagged transactions go to a queue where you (or your team) approve or decline them individually. Without Fraud Teams, the only options are Block or Allow. With Fraud Teams, you add Review as a third option.
• Advanced rule attributes: access to customer lifetime value, total purchase count, time since first purchase, and other behavioral attributes in your custom rules.
• Allow and block lists: granular lists for emails, card fingerprints, IP addresses, and card BINs.
• Risk insights: detailed breakdown of why a specific transaction received its risk score.

For creators processing fewer than 500 transactions per month with a block rate under 3%, the free Radar tier is usually sufficient. Once you exceed 500 monthly transactions or your block rate crosses 5%, the manual review queue alone is worth the $0.07 per transaction. Being able to review and approve borderline transactions instead of auto-blocking them recovers revenue that more than covers the cost.

When Radar is not enough: the platform approach

Tuning Radar rules, maintaining allow lists, reviewing blocked payments weekly, enriching metadata, and monitoring your block rate: all of this is ongoing operational work. For solo creators or small teams, this maintenance competes directly with time spent on product development, marketing, and customer support.

Merchant of Record (MoR) platforms take a fundamentally different approach. Instead of giving you a fraud prevention toolkit and expecting you to configure it, they handle fraud screening at the platform level. You sell through their infrastructure, and fraud prevention is their problem, not yours.

Whop operates as a Merchant of Record for digital products, courses, communities, and coaching programs. Fraud screening happens automatically at the platform level, which means you do not manage Radar rules, review queues, or blocked payment logs. The platform's model is trained specifically on creator economy transactions (not general e-commerce), so the false positive rate for coaching, courses, and communities is structurally lower than what you would see tuning Stripe Radar yourself.

• Just 2.7% + $0.30 per transaction. No subscription required. No hidden costs.
• Whop automatically handles and fights disputes on your behalf.
• Whop helps protect from holds and account closures because compliance reviews trigger at predictable revenue milestones.
• Named social proof: Iman Gadzhi made $25M+ on Whop. TJR runs $1M/month. Airrack hits $250K/month.

The decision is not about whether Stripe Radar is bad (it is not; it is a strong fraud prevention system). The decision is about whether manually tuning a general-purpose fraud model is the best use of your time compared to using a platform purpose-built for your business type. If you have been hit with account actions alongside false positive issues, our guide on Stripe account bans covers what happens when Radar flags compound into broader account risk.

What to do next

Stripe Radar false positives are not a bug. They are a byproduct of applying a general fraud model to non-general purchase patterns. Creator businesses (courses, coaching, paid communities, info products) trigger more false positives because their transactions look suspicious to an algorithm trained on e-commerce baselines: high prices, new customers, international buyers, launch-day volume spikes.

The fix is calibration, not abandonment. Start by checking your block rate in the Stripe Dashboard. Review blocked payments to identify patterns. Create allow lists for repeat customers. Adjust your block threshold upward. Route medium-risk transactions through 3D Secure instead of blocking them. Enrich your payment metadata. Review blocked payments weekly.

If the operational overhead of maintaining these adjustments exceeds the value of your time, consider a Merchant of Record platform like Whop that handles fraud prevention at the platform level. Either path works. The wrong choice is ignoring the problem entirely and losing 5-10% of your revenue to an algorithm that does not understand your business.

Frequently asked questions

What is a good false positive rate for Stripe Radar?

Most payment processors consider a false positive rate below 2% acceptable for general e-commerce. For digital product creators (courses, coaching, communities), rates between 3-8% are common because the purchase patterns naturally trigger fraud signals. If your block rate exceeds 5%, you are almost certainly losing legitimate revenue and should review your Radar rules. Check your block rate in the Stripe Dashboard under Payments, then Analytics.

Does Stripe refund me for transactions that Radar blocks incorrectly?

No. Stripe does not charge you for blocked transactions, but it also does not compensate you for the lost revenue. A blocked transaction never processes, so there is no fee and no refund. The cost is entirely in lost sales that you never see. This is why monitoring your block rate matters: you cannot recover revenue from customers who were turned away at checkout and never came back.

What is the difference between Stripe Radar and Radar for Fraud Teams?

Stripe Radar (free) comes with every Stripe account and provides basic machine-learning fraud scoring plus a limited set of default rules. Radar for Fraud Teams costs $0.07 per screened transaction and adds manual review queues, advanced custom rules (using attributes like customer lifetime value and purchase velocity), and allow/block lists. For most creators processing fewer than 500 transactions per month, the free tier is sufficient. Once you scale past that, the $0.07 per transaction is worth it for the additional control.

Can I recover a sale after Stripe Radar blocks it?

Not directly. Once Radar blocks a payment attempt, the customer sees a generic decline message. You can reduce the impact by setting borderline transactions to "review" instead of "block," which holds the payment for your manual approval rather than declining it outright. If you know a blocked customer personally, you can ask them to retry (ideally from the same device and IP) after you have added their email or card fingerprint to your allow list.

Does 3D Secure reduce false positives?

Yes, but with a tradeoff. When you route a flagged transaction through 3D Secure instead of blocking it, the customer gets a chance to authenticate and complete the purchase. If they pass authentication, the transaction processes and you receive fraud liability protection from the issuing bank. The tradeoff is conversion friction: 3D Secure adds a step to checkout, and approximately 10-15% of customers abandon at the authentication screen. Use 3DS selectively for medium-risk transactions rather than applying it globally.

Why do international transactions trigger Stripe Radar more often?

Stripe Radar weighs several signals that international transactions frequently trigger: mismatch between the card-issuing country and the IP address country, use of VPNs (common in countries with internet restrictions), unfamiliar BIN ranges (bank identification numbers), and shipping/billing address inconsistencies. For creators selling globally, these signals generate a disproportionate number of false positives. The fix is to create custom rules that lower the risk weighting for your most common buyer countries rather than relying on Radar defaults.

Should I use Stripe Radar or switch to a platform that handles fraud prevention for me?

It depends on your volume and technical comfort. If you process fewer than 200 transactions per month and sell primarily to domestic customers, Radar with basic tuning is usually sufficient. If you sell high-ticket digital products to an international audience, the ongoing work of maintaining custom rules, reviewing flagged payments, and monitoring your block rate becomes a significant time cost. Merchant of Record platforms like Whop handle fraud screening at the platform level, which means you do not manage Radar rules, review queues, or allow lists yourself.

Last reviewed: 2026-05-22. Stripe Radar features and pricing are current as of 2026. Radar for Fraud Teams costs $0.07 per screened transaction per Stripe's published pricing. False decline revenue impact estimates are based on published industry research, not Stripe disclosures. Nothing here is legal or financial advice. WhatPayment may earn a commission on certain links. Read our affiliate disclosure.