Every online card payment gets a score before it gets an answer. Somewhere between tapping "Pay" and seeing a confirmation, a model looks at the card, the device, the shipping address, how fast the form got filled out, and how many times that card has been tried in the last hour. It produces a number. That number decides whether the payment is approved, challenged, or quietly rejected.
Most coverage of that machinery frames it as a fraud problem: how do we catch the bad guys? The more interesting number sits on the other side of the ledger. Industry estimates put global merchant losses from false declines — real customers wrongly turned away — above $231 billion in 2026, with U.S. merchants absorbing something on the order of $118 billion of it. Actual ecommerce fraud, by the same estimates, is a fraction of that; one widely cited Javelin figure puts the ratio near 13 to 1. Roughly half of merchants surveyed believe up to 5% of their legitimate orders get declined as fraudulent.
What happens in those hundred milliseconds
Modern fraud scoring is event-driven and runs inside the authorization window, typically returning a verdict in under 100ms. Each transaction is scored more or less independently against a handful of signal families: card and issuer attributes, device fingerprint, velocity (how many attempts from this card, IP, or device in a given window), behavioral signals like whether the card number was typed or pasted, and historical signals like address match and prior order history.
The model emits a score. What happens next is not machine learning, it is business policy:
function route(score, { amount, isFirstOrder }) {
// These cutoffs are policy, not math. They encode exactly how much
// revenue you are willing to trade for how much fraud loss.
if (score >= 0.9) return "block";
if (score >= 0.45 || (amount > 500 && isFirstOrder)) return "challenge_3ds";
return "approve";
}The thresholds are the whole game. Move the block cutoff from 0.90 to 0.80 and your fraud rate drops, your decline rate climbs, and somewhere a customer who has ordered from you eleven times gets told their card was declined and goes to a competitor. Nothing in the system records that as a loss.
3-D Secure turned a binary into three options
3-D Secure 2 exists largely to break the approve-or-block dichotomy. Before authorization, the merchant sends a rich data payload — device details, billing information, transaction history, dozens of fields — to the issuer's access control server. The issuer runs its own risk assessment on that data. If it is confident, it returns a frictionless authentication and the customer never sees anything at all; vendors commonly report frictionless rates around 95%. Only the risky slice gets a challenge: a one-time passcode, a biometric prompt, or an approval tap in the bank's app.
The second thing 3DS does is move money around. On a successfully authenticated transaction, liability for a fraud chargeback shifts from the merchant to the issuing bank, on the logic that the issuer made the authentication call. That is genuinely valuable at volume. It is also narrower than people assume. The shift applies only to fraud-reason chargebacks — not "item not as described," not "never arrived." And it applies only when authentication actually succeeded, not to technical failures, bypasses, or cards whose issuer is not enrolled.
Which is why the common failure mode is switching 3DS on for everything. Every challenge is one more checkout step a real customer can abandon. You trade a false decline problem for a cart abandonment problem and congratulate yourself on the improved fraud numbers.
Measure the error you are not measuring
Almost every fraud team has a fraud-to-sales ratio on a dashboard. Far fewer track a false decline rate, because a false decline does not announce itself. Nobody files a chargeback to tell you they were a good customer.
You have to infer it. Useful proxies: declined cards that succeed on a retry or at another merchant, declined orders from customers with long clean histories, support contacts about failed checkouts, and re-attempt success rate. A quick diagnostic is to segment approval rate by customer tenure. If approval for customers with five or more prior clean orders sits meaningfully below your overall approval rate, your model is penalizing loyalty, and that is worth chasing down before you touch a threshold.
The framing that helps most is to stop thinking of a fraud system as a filter that removes bad transactions. It is a classifier with two error types whose costs are both asymmetric and asymmetrically visible. A missed fraud costs you the chargeback, the fees, and the goods, and it shows up on a report. A false decline costs you the order, that customer's future orders, and their impression of you, and it shows up nowhere. Instrument only one of those, and you will optimize very confidently in the wrong direction.