Why exactly one fraud rule is allowed to block

The file that collects our fraud signals states the same rule three times in its own header, which is unusual enough to be worth explaining: nothing blocks. A device seen buying under four different email addresses in a week raises a flag. A customer whose refund rate is over half raises a flag. A network shared across six stores raises a flag. Not one of them cancels an order, and a test exists whose entire job is to let a maximally flagged customer buy again.

That posture is not squeamishness. It follows from what the signals actually are. A household shares a laptop. A co-working space shares an address. A carrier NAT exit shares an IP with a city. Every shape these rules can see has an innocent reading and a guilty one, and the difference between them is context that lives in a merchant’s head rather than in our database. Automating that judgement means being wrong about real customers, at the till, with no recourse and no explanation they would accept.

The exception, and what makes it one

Card testing breaks the argument, and it breaks it on time rather than on severity. A scripted run fires hundreds of small authorisations in minutes against any storefront that will take a card, to find which numbers out of a stolen list are still live. By the time a notification is read, the run is finished: the merchant is holding a provider fine and an authorisation-rate problem that can cost them their payment account, and the attacker is holding a validated list.

A flag cannot be a response to this, because by the time anybody reads it there is nothing left to respond to.

So one file in the product refuses automatically, and the limits on it are the whole design. Fifteen checkouts from one browser, or fifty from one network, at one store, inside ten minutes. Nobody buys fifteen times in ten minutes; somebody retrying a declined card does it three or four times. The refusal cools down that device or that network at that store for five minutes, doubling on a repeat trip to a ceiling of an hour, and is remembered for a day so the ladder has a memory.

What it deliberately cannot do

It never touches the shop. Nothing in that file reads or writes a store’s status, because automated code does not get to take a merchant’s storefront offline on a heuristic. A false positive costs one visitor a few minutes; the alternative costs a real business its day.

It collects nothing new, either. It counts rows that the ordinary fraud signals already write, over a much tighter window — no card number, no BIN, no challenge, no third party. Which produces a consequence we had to write down rather than discover: a merchant who switches fraud-signal collection off switches this rule off with it. There are no rows to count, so no burst can ever trip. Opting out of collection is opting out of the card-testing refusal, and the settings page says so in those words.

And the refusal is honest. A 429 with a sentence and a Retry-After, not a mysterious 500 and not a silent success. Somebody who trips this from a shared office needs to know it is temporary and roughly how temporary.

The rule we did not write

Later, a merchant asked for something that sounds adjacent: hold orders over €500 from a new device. Read as refuse the checkout, it would have been the second thing in the product that stops a sale automatically — on a threshold somebody typed, for a condition with no clock on it, paid for by a customer who did nothing wrong. The speed argument that justifies the card-testing rule is simply unavailable there.

Read as hold the fulfilment, every one of those costs disappears and the merchant still gets what they asked for. The order charges and settles. What waits is the download grant, the licence key or the parcel — which is the thing they were actually worried about. The merchant takes on a payment they may end up refunding, with whatever fee their provider keeps. That is a real cost, and it is paid by the party who chose the rule.