Velocity checks, in one paragraph
A velocity check counts how many times something happens inside a set window. Not a person, not an account: an identifier. One card number, one IP, one device fingerprint, one email address, one BIN. Cross the threshold and the transaction gets held, stepped up, or declined. Card testing is the reason most merchants turn these rules on in the first place. Someone with a list of stolen numbers needs to know which ones still authorize, so they run small charges fast and watch the responses. Velocity rules are built to catch that burst.
What card testing looks like in your logs
The signature is not a big order. It is many tiny ones. A card testing run usually shows a few traits at once:
- Dozens of authorizations in minutes, often for amounts under a dollar or just above it.
- Repeated declines clustered on the same device or IP, followed by a success.
- Card numbers that share a BIN range, hitting your checkout in sequence.
- Email addresses that look generated, and shipping details that never get filled in.
- Billing and shipping mismatches that go unchallenged because the order value is trivial.
Normal shoppers do not produce that shape. They buy one thing, or they browse and leave. A single customer might fail a card once and try another. Ten failures from one fingerprint inside five minutes is a different animal.
Dimensions worth counting together
Single-dimension rules are easy to spot and easy to work around. Counting several identifiers at once gives you a picture instead of a number.
- Card: attempts per card number per hour, plus attempts per card per day.
- BIN: how many distinct cards from the same BIN range touch you in a short period.
- IP and subnet: attempts per address, and attempts across the whole /24.
- Device: fingerprint velocity, which survives IP rotation better than address counting.
- Account and email: new accounts with multiple card attempts in their first hour.
When two or more of those spike at the same time, you are almost certainly looking at a testing run and not a busy Tuesday.
Setting thresholds without punishing real customers
Pick the number from your own data, not from a blog post. Pull ninety days of approvals, find the 99th percentile of attempts per card per day, and start above it. Then treat the first crossing as a review, not a block. Step-up authentication, a manual hold, or a soft decline costs you far less than a false positive on a repeat buyer.
Two tuning notes I keep coming back to. Segment your thresholds by channel, because mobile and desktop behave differently. And review them quarterly, since a rule that fit last year's traffic may be wide open now.
Where velocity alone breaks down
Velocity is a lagging signal. It tells you an attack is underway, not that this particular charge is fraudulent. Attackers who understand thresholds will spread attempts thin, and a slow drip across hundreds of cards can slip under a rule that only looks at volume. BIN-level rules also flag legitimate prepaid and gift card traffic, which generates support tickets you did not ask for.
So pair velocity with signals that do not depend on counting: CVV and AVS responses, address verification, device reputation, issuer decline codes, and whether the same card has ever completed a clean order with you. Velocity tells you where to look. The rest tells you what you found.