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.

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.