There is a number you will never see, and it is almost certainly larger than the number that keeps you up at night.

You know your chargeback count. It arrives with an email, a fee, a countdown clock, and a small physical drop in your stomach. What you don't know is how many honest customers your payment system quietly turned away this month — people who typed in a real card, got a red error, assumed they'd done something wrong, and closed the tab. They don't email you. They don't leave a review. They just stop existing in your data. Every fraud rule you write to protect yourself is also a rule that rejects someone. The uncomfortable part isn't that the tradeoff exists. It's that most merchants tune one side of it obsessively and have never once looked at the other.

This is what Stripe Radar is really doing on every transaction: not catching fraud, but placing a bet about where to draw a line through uncertainty. Understanding where that line sits — and how to move it deliberately instead of by accident — is the difference between preventing chargebacks and preventing revenue.

Radar isn't a fraud detector. It's a decision under uncertainty

When a payment hits Stripe, Radar evaluates it against a machine learning model trained on signals across the network: the card, the device fingerprint, the IP, the email, the velocity of attempts, whether this card has been seen before, whether this device has tried many cards. It produces a risk score from 0 to 100 and a corresponding risk level — normal, elevated, or highest. By default, Stripe blocks payments at the highest risk level and lets the rest through.

That default is a policy choice, not a fact about the world. And it's the single most important thing to internalize about fraud prevention.

Psychologists have a formal name for this problem. Signal detection theory, developed in the 1950s by researchers including David Green and John Swets, describes exactly this situation: an observer must decide whether a faint signal (fraud) is present in noise (normal transactions), when the two distributions overlap. The theory separates two things people constantly confuse. The first is sensitivity — how well the underlying evidence actually distinguishes fraud from non-fraud. The second is criterion — where you choose to draw the line for calling something fraud.

You cannot improve sensitivity by being stricter. Stricter only moves the criterion. Move it toward caution and you catch more fraud (fewer misses) while rejecting more good customers (more false positives). Move it toward permissiveness and you approve more real buyers while eating more chargebacks. The overlap doesn't shrink. You are only choosing which kind of error you'd rather make.

This is why "just block anything suspicious" is not a strategy. It's a criterion shift dressed up as a solution, and it has a cost you've chosen not to measure.

The two errors are not symmetrical, and you know which one you feel

Here's what makes this genuinely hard: the errors have wildly different emotional weight and wildly different visibility.

A chargeback is loud. It has a name, a reason code, a dollar amount, a fee attached even when you win, and a deadline that makes you feel behind. It counts against your dispute rate, which is the number that determines whether card networks let you keep processing at all.

A false positive is silent. The customer sees a generic decline. They don't know it was you. They assume their bank is being weird, or that your checkout is broken, or — worst case — that your business is sketchy. They buy from someone else. Your Radar dashboard records a "blocked payment" and, if you squint, presents it as a win.

Behavioral scientists would recognize the asymmetry immediately. This is availability bias operating on your business strategy: the vivid, recallable, painful event drives the decision, while the invisible, diffuse, larger loss doesn't enter the calculation. Merchants routinely tighten rules after a bad chargeback week. Almost nobody loosens them after a bad conversion week, because nobody attributes the bad conversion week to the rules.

So before you write a single Radar rule, write down the actual costs. What is the fully loaded cost of one chargeback — the disputed amount, the dispute fee, the time you spend fighting it, its contribution to your dispute rate? And what is the lifetime value of one customer you wrongly turn away? If those two numbers are close, aggressive blocking is roughly a wash and you're just adding friction. If one dwarfs the other, you now know which direction to move your criterion — and you're moving it on purpose.

Rules that shift the criterion intelligently

Radar for Fraud Teams lets you write custom rules that block, allow, review, or request 3D Secure on specific conditions. The naive move is to write blunt block rules on high-level attributes: block this country, block this card brand, block anything over a dollar amount. These are terrible criteria. They have almost no sensitivity — the fraud and non-fraud distributions overlap almost completely on "is a large order" — so all you've done is discard good customers in bulk.

Better rules exploit signals where the distributions genuinely separate.

Velocity on the card testing pattern. A single device or IP attempting many distinct cards in a short window is not a shopping behavior. It has no legitimate analogue. That's a signal with real sensitivity, and blocking on it costs you almost nothing.

Mismatch between customer-supplied and card-issuer data. A billing postal code that fails AVS, combined with an elevated risk score, is meaningfully more diagnostic than either alone. Radar can compose these. Conjunctions of weak signals often separate better than any single strong one.

Familiarity. If this card, email, or fingerprint has successfully purchased from you before without a dispute, that's genuine evidence — and it's the same evidence card networks now formally recognize under compelling evidence standards for fraud disputes. An allow-list rule for returning customers doesn't just improve conversion; it protects the exact population you most want to keep.

And the escalation rule most merchants skip: instead of blocking an elevated-risk payment, request 3D Secure. This is the only move in the entire toolkit that doesn't force you to trade one error for the other. It converts an uncertain transaction into an authenticated one — the customer proves identity with their bank — and for authenticated transactions, fraud-based chargeback liability generally shifts to the issuer. You've stopped choosing between a chargeback and a lost customer. You've made someone else carry the risk. The cost is a little checkout friction, which is real, which is why you apply it selectively to elevated risk and not to everyone.

Your next moves

  • Open Radar → Reviews and blocked payments in your Stripe Dashboard and read ten blocked transactions from the past month, one by one. For each, ask honestly: does this look like fraud, or like a real person on a VPN with a new device? You are calibrating your false-positive rate by hand because nothing else will do it for you.
  • Calculate your two numbers today. Cost of one chargeback (disputed amount + dispute fee + your hours + dispute-rate impact) versus lifetime value of one lost customer. Write both on the same line. Let the larger one tell you which direction to tune.
  • Write one 3D Secure request rule instead of a block rule. Target elevated-risk payments — not highest, which Stripe already blocks, and not normal, which you'd be taxing for nothing. This is the highest-leverage single rule most merchants have never enabled.
  • Add an allow rule for returning customers whose card or fingerprint has a prior successful, undisputed charge with you. Then check your block log a week later to see how many good payments it rescued.
  • Delete your broadest block rule — the country-level, amount-level, or card-brand-level one you added during a panic — and watch what happens for thirty days. If disputes don't move, that rule was never protecting you. It was only costing you.

When the line moves anyway

Here is the part no rule engine solves. You will tune your criterion well, and fraud will still get through, because the distributions overlap and always will. A chargeback arrives, and now you're on the other side of the problem: not deciding whether to accept a payment, but proving that you should have been allowed to keep one. That fight has its own deadline — typically about seven days to respond in Stripe — and its own quiet failure mode, which is simply not getting to it during a week when everything else was on fire. Prevention buys you fewer of these. It never buys you zero.

That's the gap Argeback was built to close. It watches your Stripe account for incoming disputes, pulls together the evidence that actually moves a reviewer — the order records, the delivery signals, the customer's own correspondence — drafts the response, and files it before the clock runs out, from your phone, on a day you didn't have time to think about chargebacks at all. You tuned the front door as well as it can be tuned. Let something else guard the back one. See how it works →