Fix: Stripe “Radar” False Positives – Rescuing Blocked Payments

A Stripe Radar false positive occurs when Radar’s automated fraud algorithms or custom risk rules flag a legitimate buyer as fraudulent, setting the transaction status to blocked and preventing payment processing. These blocks return a 402 Request Failed status with an outcome seller message stating that Stripe evaluated the payment as high risk. Rescuing these payments requires identifying whether the default machine learning score or a custom rule triggered the block, adding legitimate attributes to your Radar Allow list, and calibrating rule thresholds to request 3D Secure rather than blocking transactions outright.

How do you fix Stripe Radar false positives and unblock legitimate customers?

To rescue legitimate payments blocked by Stripe Radar, locate the transaction under Radar > Payments, identify whether an automated risk score (75 or higher) or a custom rule blocked it, and click Add to Allow list for that customer’s card fingerprint or email. Then, rewrite blocking rules to use Request 3D Secure instead.

---

Diagnostic Snapshot: Stripe Radar False Positives

Parameter	Diagnostic Value
Failure State	status: "failed", outcome.type: "blocked"
Seller Message	Stripe evaluated this payment as normal/high risk and blocked it.
Primary Mechanism	Radar Risk Score >= 75 or an overly broad custom block rule
Impacted Layer	PaymentIntent authorization / Card issuer charge initiation
Required Permissions	Stripe Dashboard Administrator or Risk Analyst role

---

Diagnostic Path: Isolate Why Radar Blocked the Payment

Payment Marked as Blocked
  │
  ├──► Open Payment Record in Stripe Dashboard
  │      └── Check "Radar evaluation" section
  │            │
  │            ├── Blocked by: "Stripe's default block rule"
  │            │     ├── Risk score is 75 - 99 (High Risk)
  │            │     └── Action: Add customer attribute to Allow list & evaluate missing data (CVC/ZIP)
  │            │
  │            └── Blocked by: "A custom rule"
  │                  ├── Identify rule syntax (e.g., IP mismatch, prepaid cards, high velocity)
  │                  └── Action: Convert rule from "Block" to "Request 3D Secure"
  │
  └──► Check Outcome Data in API
         └── Inspect payment_intent.charges.data[0].outcome.rule

---

How Stripe Radar Evaluates Payments

Every charge routed through Stripe passes through Radar’s risk evaluation engine. Radar assigns each transaction an integer risk score from 0 to 99, representing the estimated likelihood of the charge resulting in a fraudulent dispute:

• 0 to 64: Normal Risk (Transaction permitted)
• 65 to 74: Elevated Risk (Permitted, or sent to Review queue in Radar for Fraud Teams)
• 75 to 99: High Risk (Blocked by default)

Beyond the machine learning score, Radar executes custom rules in a sequential order:

1. Allow rules: If met, the payment proceeds and skips subsequent block rules.
2. Block rules: If met, the payment is rejected immediately.
3. Review rules: If met, the payment is processed but flagged in your manual review queue.
4. 3D Secure rules: If met, Stripe dynamically requests cardholder authentication.

When a customer complains of an unexpected decline, distinguish between bank declines and Radar declines. If the bank declines the charge, troubleshoot using Fix: Stripe “402 Request Failed” (Card Declined Deep Dive). If Radar blocked it, the issuer never received the charge; Stripe intercepted it first.

---

Primary Causes of False Positives

1. Incomplete Billing Data Passed to the API

Radar relies heavily on standard verification vectors. If your checkout form only collects the card number, expiry date, and CVC, Radar lacks essential signals:

• AVS (Address Verification Service): Without the billing postal code, cardholder verification cannot run.
• Cardholder Name: Mismatches or absent names increase the machine learning risk weight.
• Customer IP Address: If backend-to-backend API integrations process charges without forwarding the user’s client IP, Radar evaluates the charge originating from your server’s hosting facility (e.g., AWS, DigitalOcean), which is often flagged as a proxy or hosting service.

2. Overly Aggressive Custom Geolocation Rules

A common custom rule is:

Block if :card_country: != :ip_country:

While this rule stops international card fraud, it consistently blocks valid buyers using commercial VPNs, business travelers, expats, and customers purchasing gifts for overseas recipients. If rules target broad ranges, verify that you are not causing system-wide drops as outlined in Troubleshooting: Stripe “Radar” rule blocking entire IP Ranges.

3. Rapid Retry Velocity Blocks

When a legitimate customer makes a simple typographical error on their expiration date or billing address, their card declines. If they quickly re-enter their card details three times within two minutes, custom or default velocity rules interpret the behavior as an automated card testing attack, elevating the risk score above 75.

---

Step-by-Step Resolution

Step 1: Immediately Unblock the Legitimate Customer

To allow a verified customer to purchase immediately:

1. Open the Stripe Dashboard and go to Radar > Payments (or search the customer’s email).
2. Click on the blocked charge to open the payment details page.
3. Scroll down to the Risk evaluation box.
4. Click the three dots icon or the quick-action button and select Add to Allow list.
5. Select the attribute to trust:
   • Card fingerprint: Allows this exact physical card to pass through without being blocked by Radar.
   • Email address: Allows charges using this customer email to bypass standard block rules.
   • IP address: Useful for corporate accounts purchasing from a static office subnet.
6. Instruct the customer to retry their purchase.

Step 2: Ensure Proper Billing and Client Data Collection

Update your frontend integration to capture complete billing information:

// Example: Creating a PaymentIntent with required Radar data
const paymentIntent = await stripe.paymentIntents.create({
  amount: 10000,
  currency: 'usd',
  customer: customerId,
  description: 'Order #48291',
  receipt_email: 'buyer@example.com',
  // Radar data signals:
  shipping: {
    name: 'Jane Doe',
    address: {
      line1: '123 Market Street',
      postal_code: '94105',
      city: 'San Francisco',
      state: 'CA',
      country: 'US',
    },
  },
  metadata: {
    client_ip: req.ip,
  },
});

Step 3: Replace Hard Block Rules with Dynamic 3D Secure

Instead of dropping payments that exhibit elevated risk factors, use 3DS authentication to verify card ownership. This eliminates false positives while keeping fraud protection intact.

1. Go to Radar > Rules.
2. Locate rules that hard-block based on country mismatch or elevated risk: Block if :risk_score: >= 75
3. Instead of leaving all borderline traffic to hard blocks, introduce a dynamic 3DS rule above the block threshold: Request 3D Secure if :risk_score: >= 65 and :risk_score: < 85
4. If you have custom country mismatch rules, rewrite them:
   • Old Rule (Too Aggressive): Block if :card_country: != :ip_country:
   • New Rule (Safe Authentication): Request 3D Secure if :card_country: != :ip_country:

When 3D Secure succeeds, liability for fraudulent chargebacks shifts from your business to the card issuer in most jurisdictions. If the customer completes the challenge, the payment processes safely without manual intervention.

---

Advanced Verification: Testing Rule Changes

Before deploying a revised Radar rule to production, use Radar’s built-in rule simulator:

• In Radar > Rules, edit your rule and click Test rule.
• Stripe will run the rule against your historical transaction data for the past 6 months.
• Review how many fraudulent charges were blocked versus how many successful, dispute-free transactions would have been rejected. Ensure the false positive ratio remains near zero.