stripe radar decline rate spiked after enabling new rule

Not specified by the original author.

TL;DR

Roll the new rule back to review-only first, then measure the decline rate before and after the change in Radar analytics to confirm the rule is the cause. Narrow the condition or add exceptions for the legitimate segment it caught, and re-enable it only after the rule tester shows it matching the intended fraud pattern. Never ship a block rule without a review-only soak period again.

stripe radar decline rate spiked after enabling new rule

Use this when

• Authorization or conversion rate dropped right after a rule change.
• The new rule is the only recent change.
• You need to prove which rule caused the spike.

Not for this skill when

• The decline rate rose with no rule changes. Look at issuer declines, traffic mix, or outages.
• Declines come from the issuer side. Radar rules do not cause issuer declines.
• The spike is in disputes, not declines. That is a different problem.

Steps

1. Set the new rule to review-only, or disable it, right away. Verify: the rule list shows the change.
2. In analytics, compare the decline rate for the 24 hours before and after the rule went live. Verify: the spike lines up with the rule change.
3. Pull a sample of declined payments and confirm the rule matched them. Verify: the payment timelines name the rule.
4. Tighten the condition or add an allowlist exception for the legitimate segment. Verify: the rule tester matches the fraud pattern but not the sample good payments.
5. Re-enable the rule in review-only mode for a soak period before restoring block. Verify: review volume from the rule stays sane for several days.

Variant phrasings

radar new rule increased declines

Shorter phrasing.

stripe radar rule causing authorization drop

Authorization-focused phrasing.

decline spike after radar rule change

Metric-first phrasing.

Compatibility: Stripe Radar custom rules. Works with Radar analytics decline-rate views.

Why it happens

A rule that looks precise in the tester can still match a broad real-world segment, especially when it keys on a common attribute like billing country or order amount. Because block rules act silently, the first sign of trouble is the revenue dip, not an alert.

Edge cases / pitfalls

• Two rule changes close together can confound the before-and-after. Change one rule at a time.
• Seasonal traffic shifts can mimic a rule-caused spike. Compare against the same weekday last week, not just yesterday.
• Review-only mode still costs analyst time. Set a calendar reminder to revisit the rule after the soak.

Provenance

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

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

Thread query: stripe radar decline rate spiked after enabling new rule

TL;DR: Roll the new rule back to review-only first, then measure the decline rate before and after the change in Radar analytics to confirm the rule is the cause. Narrow the condition or add exceptions for the legitimate segment it caught, and re-enable it only after the rule tester shows it matching the intended fraud pattern. Never ship a block rule without a review-only soak period again.

Not specified by the original author.

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.

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

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

Thread query: stripe radar blocked a legitimate order: how to fix false positive

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.

Not specified by the original author.

TL;DR

risklevel is informational. Nothing blocks on it unless a rule says so, so add a rule such as requiring review when risklevel is elevated, or requesting 3D Secure. Check rule ordering so an earlier allow rule is not pre-empting your new rule. Then verify with the rule tester that an elevated payment now hits the rule.

radar risk_level elevated but payment still confirmed: how to fix

Use this when

• Payments you consider risky keep confirming despite an elevated risk_level.
• You want elevated or highest risk to trigger review or 3D Secure.
• The Dashboard shows elevated but no rule fired.

Not for this skill when

• You want to change how Radar computes risk_level. That is scoring, not rules.
• The payment was blocked and you are confused. Check the decline reason instead.
• risk_level is normal. There is nothing to gate on.

Steps

1. Open Radar rules and confirm no existing rule acts on risklevel. Verify: a search for risklevel in your rules returns nothing.
2. Add a rule: when risk_level is elevated, require review; when highest, block or request 3D Secure. Verify: the rule saves without syntax errors.
3. Move the new rule above any broad allow rules so it evaluates first. Verify: the rule order in the Dashboard reflects the change.
4. Run the rule tester against a past elevated payment. Verify: the tester shows the rule matching.
5. Monitor the review queue for a day to confirm elevated payments now route there. Verify: queued payments carry the elevated level.

Variant phrasings

stripe radar elevated risk still charges

Charge-focused phrasing.

risk_level elevated no radar rule fired

Rule-focused phrasing.

how to block elevated risk stripe radar

Action-focused phrasing.

Compatibility: Stripe Radar custom rules; risk_level values are normal, elevated, and highest. 3D Secure actions need Radar for Fraud Teams.

Why it happens

Radar separates scoring from policy. The score and level describe the payment; only your rules decide what happens. Default Radar has no rule that blocks on elevated alone, so elevated payments confirm unless you add the policy.

Edge cases / pitfalls

• Blocking on elevated alone creates false positives. Prefer review or 3D Secure for elevated, and reserve block for highest.
• An allowlist rule placed above will exempt trusted customers before your risk rule sees them. That is usually what you want, but verify it is intentional.
• risk_level can change as new signals arrive. Rules evaluate at payment time against the level at that moment.

Provenance

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

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

Thread query: radar risk_level elevated but payment still confirmed: how to fix

TL;DR: risklevel is informational. Nothing blocks on it unless a rule says so, so add a rule such as requiring review when risklevel is elevated, or requesting 3D Secure. Check rule ordering so an earlier allow rule is not pre-empting your new rule. Then verify with the rule tester that an elevated payment now hits the rule.