risk allowlist rule failed to override block rule

TL;DR

An allowlist only overrides a block when it evaluates first and matches exactly. Move the allowlist rule above the block rule, then check the value matches the request attribute character for character. A near-match on email or card fingerprint is a miss.

risk allowlist rule failed to override block rule

Use this when

• Trusted customers, emails, or cards still get blocked by Radar.
• You added an allowlist entry but the block rate did not change.
• The block log shows the block rule firing instead of the allow rule.

Not for this skill when

• The issuer declined the payment. No Radar rule can override that.
• The block rule is doing its job and should stay enforced.
• The allowlist entry is for a different attribute than the rule checks.

Steps

1. Open the rule list and confirm the allowlist sits above the block rule. Verify: the allowlist position is higher in the evaluation order.
2. Pull a blocked payment and compare the request attribute against your allowlist entry exactly, including case and whitespace. Verify: the strings are identical.
3. Check the attribute type: an allowlisted email domain does not match a full email address, and vice versa. Verify: the entry type matches the rule condition.
4. Confirm the allowlist and the block rule live in the same mode. Test-mode lists do not apply to live payments. Verify: the entry exists in the live value list.
5. Run a test payment from the allowlisted customer. Verify: the allowlist rule fires and the block rule never evaluates.

Variant phrasings

radar allow rule not working

Shorter phrasing of the same problem.

allowlist not overriding block

Symptom-level search.

trusted customer still blocked by radar

Merchant-side wording.

Compatibility: Stripe Radar rule ordering. Allow rules override block rules only when evaluated first.

Why it happens

Radar evaluates rules in list order, and the first decisive match wins. An allowlist buried below the block rule is dead configuration. Even when ordered right, allowlists fail on near-matches: a trailing space, a case difference, or a domain-versus-address mismatch means the condition never fires, and the block rule wins by default.

Edge cases / pitfalls

• Overly broad allowlists, like whole domains or large IP ranges, punch holes fraudsters can walk through. Keep entries narrow and review them quarterly.
• Allowlisting a card fingerprint helps only until the card is replaced. Tie long-term trust to the customer id instead.
• Every allowlist entry is a fraud exception. Log who added it and why.
• After reordering, re-test the block rule with a non-allowlisted payment to confirm it still fires.

Provenance

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

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

Thread query: risk allowlist rule failed to override block rule

TL;DR: An allowlist only overrides a block when it evaluates first and matches exactly. Move the allowlist rule above the block rule, then check the value matches the request attribute character for character. A near-match on email or card fingerprint is a miss.