radar rule test mode vs live mode mismatch: how to fix

TL;DR

Test and live are separate rule sets, separate value lists, and separate simulated outcomes. A rule that works in one mode and fails in the other is almost always a configuration copy that missed something. Diff the two rule sets field by field, then validate live with a small slice of traffic.

radar rule test mode vs live mode mismatch: how to fix

Use this when

• A rule fires in test mode but not live, or the reverse.
• You edited a rule and the behavior did not change where you expected.
• Value list entries seem to vanish between modes.

Not for this skill when

• Real cards behave differently from test cards at the issuer. That is expected.
• The rule works in both modes but the outcome is wrong. That is rule logic, not mode sync.
• You are debugging 3DS issuer pages. Test cards only simulate those.

Steps

1. Put the rule list from both modes side by side. Verify: you can see every rule, threshold, and condition in each mode.
2. Check value lists separately. Entries added in test mode do not exist in live. Verify: every list the rule references has the same entries in live.
3. Verify metadata conditions: test PaymentIntents must carry the same metadata your live code sets. Verify: a test intent includes the flag the rule checks.
4. Use 3D Secure test cards and Radar test scenarios to simulate the rule path in test mode. Verify: the test payment hits the intended rule.
5. Roll the live change out with a review-only action or a small traffic slice first. Verify: live behavior matches the test simulation before full enforcement.

Variant phrasings

stripe radar rule works in test not live

Same mismatch, common phrasing.

radar test mode different from live

Shorter symptom search.

rule fires in live but not test mode

Reversed-direction wording.

Compatibility: Stripe Radar. Rules, value lists, and review queues are all mode-specific.

Why it happens

Stripe keeps test and live fully isolated so experiments never touch real money. That isolation means every rule edit, list entry, and metadata dependency exists twice, and humans reliably update one copy. Test cards also simulate only a subset of real issuer behavior, so even identical configs can diverge on edge cases.

Edge cases / pitfalls

• Never launch a new block rule in live with full enforcement on day one. Use the review action first.
• Test mode cannot reproduce issuer-specific 3DS behavior, so treat test success as necessary but not sufficient.
• Document which mode each rule change went to, or the next edit will drift again.
• Review queues are mode-specific too. A test-mode review tells you nothing about live reviewer load.

Provenance

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

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

Thread query: radar rule test mode vs live mode mismatch: how to fix

TL;DR: Test and live are separate rule sets, separate value lists, and separate simulated outcomes. A rule that works in one mode and fails in the other is almost always a configuration copy that missed something. Diff the two rule sets field by field, then validate live with a small slice of traffic.