## TL;DR
Find which rule blocked the payment in the Radar payment detail view, then move it from block to review while you tune it. Add the customer or segment to an allowlist value list so repeat good buyers stop getting caught. Refund the blocked charge if one exists, have the customer retry, then mark the payment as safe to train Radar.

```text
stripe radar blocked a legitimate order: how to fix false positive
```

## Use this when
- A real customer reports their card was declined and the payment shows a Radar block.
- One specific rule is catching good orders.
- You need a repeatable false-positive workflow, not a one-off unblock.

## Not for this skill when
- The decline came from the card issuer, not Radar. Issuer declines carry a different decline code.
- The order was actually fraudulent and you are second-guessing the block. Trust the review queue.
- You want to stop all Radar blocks account-wide. That is a policy change, not a fix.

## Steps
1. Open the payment in the Stripe Dashboard and note which Radar rule fired. Verify: the rule name is visible in the payment timeline.
2. Switch that rule's action from block to review, or narrow its condition, before touching anything else. Verify: the rule list shows the new action.
3. Add the customer's email, card fingerprint, or IP to an allowlist value list referenced by your rules. Verify: a test evaluation with the same attributes no longer matches the rule.
4. Refund the blocked payment if a charge exists, and ask the customer to place the order again. Verify: the retried payment succeeds.
5. In the review queue, mark the payment as safe. Verify: Radar logs the feedback for future scoring.

## Variant phrasings
### radar blocked good customer how to allow
Same workflow, customer-centric phrasing.
### stripe radar false decline legitimate payment
Focuses on the decline itself.
### radar rule blocking real orders
Rule-centric phrasing.

Compatibility: Stripe Radar with custom rules; Radar for Fraud Teams for advanced rule conditions. Applies to card payments evaluated by Radar.

## Why it happens
Rules are blunt pattern matchers. A condition like blocking when the IP country differs from the card country also matches travelers, VPN users, and expats. Without allowlists and without a review step before block, every edge case becomes a lost order.

## Edge cases / pitfalls
- Marking payments as safe trains future scoring. Only do it after verifying the customer, or you will teach Radar to allow fraud.
- Allowlists on card fingerprints break when the customer gets a new card. Prefer email or customer id for long-lived trust.
- A rule set to block never reaches the review queue, so nobody learns from it. Prefer review for new rules until the false-positive rate is known.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fnZ4z6X5JT5C3qNXbwNJHA