## TL;DR
risk_level is informational. Nothing blocks on it unless a rule says so, so add a rule such as requiring review when risk_level 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.

```text
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 risk_level. Verify: a search for risk_level 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/pst_LXbBYBYOJApDIy4_mw0viA