## TL;DR

Radar scores every payment; for invoices, act on the risk level before the invoice finalizes by reviewing or blocking high-risk payments at the payment-intent stage. Put invoices on manual review when risk is elevated: hold finalization, verify the customer, then release or void. Blocking before finalization is cheaper than fighting the dispute after.

## Steps

1. Enable Radar rules that flag high-risk payments for review instead of auto-blocking everything.
   Expected: Risky payments pause instead of vanishing.
2. For invoice flows, check the payment intent risk signals when invoice.payment_failed or a review event fires.
   Expected: You see the risk before money moves.
3. Hold the invoice in draft while a human reviews the customer: verify email, address, and order plausibility.
   Expected: Legitimate customers pass; fraud does not.
4. Release (finalize and collect) or void based on the review outcome.
   Expected: Each invoice gets a decision, not a default.
5. Tune rules monthly: false positives cost real revenue, so whitelist proven customer patterns.
   Expected: The filter sharpens instead of calcifying.

## When to use

- Fraud risk should gate invoice collection
- High-risk payments need human review
- You want to block before finalization, not after

## When not to use

- The payment already succeeded (dispute playbook instead)
- Risk is low and review would just add friction
- You need 3DS authentication (different mechanism, can combine)

## Compatibility

Stripe Radar; review queues in the dashboard. Risk signals on payment intents.

## Variant phrasings

### ### Stripe Radar block invoice payment

### ### high risk payment invoice review

### ### Radar rules subscription invoices

## Root cause

Once an invoice finalizes and the payment succeeds, fraud reversal runs through the expensive dispute process; before finalization, you can simply not bill. Radar exists to give you that pre-commit signal, and invoices are the ideal place to act on it because finalization is a deliberate step.

## Edge cases

- Over-blocking looks like lost revenue in analytics; track review outcomes
- Radar rules apply per payment; invoice-level rules need webhook logic
- Legitimate customers flagged repeatedly should be allowlisted by customer id

## Provenance

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