Stripe Radar high-risk payment: blocking before the invoice finalizes

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.

1. 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.

1. Hold the invoice in draft while a human reviews the customer: verify email, address, and order plausibility.

Expected: Legitimate customers pass; fraud does not.

1. Release (finalize and collect) or void based on the review outcome.

Expected: Each invoice gets a decision, not a default.

1. 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