Your Stripe Radar Is Silently Blocking Real Customers

Stripe Radar is supposed to stop fraud. And it does — along with a meaningful percentage of your legitimate customers.

The problem isn't that Radar exists. It's that most merchants never configure it. They accept Stripe's defaults, assume fraud protection is handled, and never check how many real payments are being rejected. Then they wonder why conversion rates are lower than industry benchmarks.

One merchant reported losing 15–20% of revenue for months before discovering Radar was blocking legitimate transactions. No alerts. No dashboard warnings. Just quietly rejected charges that never showed up in their Stripe logs as anything unusual.

How Radar Decides to Block a Payment

Stripe Radar assigns every transaction a risk score from 0 to 100. Transactions scoring above a threshold (default: 75) are blocked automatically. The scoring model evaluates:

Card data signals. Country of issue, card type, bank identification number. A prepaid card from a country where you've never had customers scores higher.

Behavioural signals. IP geolocation, device fingerprint, velocity (how many transactions from the same card/IP in a short window). A customer who enters their card number wrong twice then succeeds on the third attempt gets flagged.

Network signals. Stripe pools anonymised data across all Stripe merchants. A card that triggered disputes elsewhere scores higher on your checkout too — even if the cardholder has never interacted with your business before.

The core issue: Radar optimises for preventing fraud, not for maximising your revenue. A false decline (blocking a real customer) doesn't cost Stripe anything. A fraud-related dispute does. The incentives are structurally misaligned with your business goals.

The Signs You're Losing Revenue

False declines don't announce themselves. Look for these indicators:

Your decline rate exceeds 5%. The industry average for legitimate merchants is 2–4%. If your Stripe dashboard shows a higher decline rate, Radar is likely catching real customers in its filter. Check under Payments → Declined.

Customer support hears "my card was declined." If customers contact you saying their payment was rejected but the charge works fine elsewhere, Radar blocked them. One or two is noise. A pattern is a Radar configuration problem.

International conversion is disproportionately low. Radar scores international transactions higher by default. If you serve a global customer base but most of your successful charges are domestic, Radar may be filtering out legitimate international buyers.

Repeat customers get blocked. If a customer who has paid you successfully three times suddenly gets declined on their fourth purchase, Radar's network signals likely changed — perhaps the card was used in a disputed transaction with a different merchant.

The Rules Most Merchants Never Set Up

Stripe Radar is configurable. The defaults are a starting point, not a finished configuration. Most merchants never touch them, which means they're running a fraud prevention system that doesn't know their business.

Allow Lists

If you have B2B customers, enterprise accounts, or repeat buyers who should never be blocked, add them to your allow list. You can allowlist by:

• Email address
• Card fingerprint
• Customer ID

One rule — allowlisting your top 50 customers by email — can eliminate the most damaging false declines overnight.

Custom Rules

Radar lets you write custom rules that override the default scoring. Examples:

Block only high-risk countries you don't serve. Instead of letting Radar penalise all international transactions, create a block rule for specific countries where you've never had a legitimate customer and an allow rule for countries where you do business.

Raise the threshold for low-ticket transactions. A $9.99 subscription payment has a different risk profile than a $2,000 one-time purchase. You can create rules that are more permissive for low-value recurring charges.

Review instead of block. For transactions in the 50–75 risk score range, set them to "review" instead of "block." This lets you manually approve or reject borderline cases rather than losing them automatically.

3D Secure

For high-risk transaction types, require 3D Secure authentication (the "Verify your payment" step). This shifts liability for fraud to the card issuer and reduces your dispute rate — while giving Radar a reason to let the transaction through.

How to Audit Your Radar Configuration

Run this diagnostic on your Stripe account:

Step 1: Check your decline rate. Stripe Dashboard → Payments → filter by "Declined." Calculate: declined payments / total attempted payments. If it's above 4%, you have a problem.

Step 2: Review blocked payments. Look at the last 30 days of blocked transactions. For each one, check the risk score and the reason. Are they clustered around a specific country, card type, or time of day?

Step 3: Check your Radar rules. Stripe Dashboard → Radar → Rules. If this page is empty or shows only default rules, your Radar is unconfigured. This is the most common finding.

Step 4: Cross-reference with support tickets. Match customer complaints about declined payments against Radar blocks. If there's overlap, those are confirmed false declines — real revenue you lost.

Step 5: Review your integration. Stripe Radar performs better when it has more data. Check whether your integration sends:

• Customer name
• Email address
• Billing address
• Shipping address (if applicable)
• IP address

Missing fields force Radar to rely on less reliable signals, increasing false positive rates.

The Cost of Doing Nothing

False declines compound. A blocked customer doesn't just miss one purchase — they often don't come back. Research from the Merchant Risk Council found that 39% of customers who experience a false decline will never attempt the purchase again.

For a business processing 5,000 transactions per month with a 3% false decline rate above the expected baseline, that's 150 lost transactions per month. At a $50 average order value, that's $7,500/month in invisible lost revenue — $90,000 per year.

And unlike chargebacks, nobody sends you an alert when it happens.

What PayCanary Does About This

PayCanary's Radar Health Audit analyses your Radar configuration against known best practices:

• Missing rules detection — identifies which standard rules you haven't configured
• Decline rate benchmarking — compares your decline rate against merchants in your category
• Integration gap analysis — flags missing data fields that weaken Radar's accuracy
• Revenue impact estimate — calculates how much false declines may be costing you

You can't fix a problem you don't know exists. The first step is seeing it clearly.

Frequently Asked Questions

How do I check my Stripe Radar decline rate?

In your Stripe Dashboard, go to Payments and filter by status "Declined." Compare declined payments against total attempted payments over the last 30 days. Anything above 4% warrants investigation.

Can Stripe Radar block legitimate customers?

Yes. Radar uses probabilistic fraud scoring, which means some legitimate transactions will be flagged. The default configuration is conservative — it favours blocking borderline transactions rather than risking fraud.

How do I reduce false declines in Stripe?

Configure custom Radar rules for your business, set up allow lists for repeat customers, ensure your integration sends complete customer data (name, email, billing address), and use 3D Secure for high-risk transaction types instead of outright blocking.

Does Stripe tell me when Radar blocks a payment?

Blocked payments appear in your Stripe Dashboard under declined transactions, but there's no proactive alert. You have to check manually — or use a monitoring tool that tracks decline rates automatically.

What data should my Stripe integration send for better Radar accuracy?

At minimum: customer name, email, billing address, and IP address. Shipping address and phone number improve scoring further. The more data Radar has, the more accurately it distinguishes fraud from legitimate transactions.