A fraud system can block a suspicious payment and still make the business worse off if its rules reject too many legitimate customers. For payment teams, the useful question is how to balance fraud losses, unnecessary friction and the work required to review uncertain cases.
Why it matters: The number of blocked transactions is an activity measure. It is not, on its own, a measure of a better payment business.
A risk score is evidence, not certainty
Stripe’s Radar documentation describes risk assessments alongside rules that can allow, block, request authentication or send a payment for review. It also notes that a payment judged normal risk can still turn out to be fraudulent.
That uncertainty matters. A score summarizes a model’s assessment from available signals; it does not settle the truth of every transaction. Rule changes should be evaluated against eventual outcomes and the legitimate payments they interrupt.
The documentation describes one provider’s system. It does not establish that any specific threshold would suit another merchant, country or business model.
Count the costs on both sides
A useful internal model includes fraud loss, lost contribution from legitimate orders, review time and support work. These are proposed accounting categories, not an industry benchmark or a promise that every item can be measured precisely.
Suppose a team tightens a rule and sees fewer disputed payments. It should also look for a change in completed legitimate orders, authentication abandonment and the review queue. Otherwise, a reduction in one cost may conceal an increase elsewhere.
Review capacity is particularly easy to overlook. A rule that sends many cases to people only helps if those people have useful evidence and enough time to decide.
Design the review decision
A reviewer needs the reason a case was selected, relevant transaction context and a defined set of actions. The interface should preserve the decision and make later outcome analysis possible.
Stripe’s documentation also distinguishes changing a customer’s allow-list status from retrying a payment. Operational actions that sound similar can have different effects; a support team needs to know which one it is taking.
This is the financial version of the oversight question in When an AI Product Needs a Human in the Loop: a person adds value when they can inspect evidence and change the outcome. Adding a review label without the tools to act merely relocates uncertainty.
Reporting & Sources
Operational analysis, reviewed September 26, 2026. No numerical savings or detection-rate claims are made.
