Velocity Rules: The Five Numbers That Stop a Card Testing Attack
The gap that makes this work
A card testing attack needs volume. The bot pushes hundreds of authorization attempts a minute at a live checkout, reading each decline or approval to sort live cards from dead ones. A real shopper needs three attempts at most: one card, a retry, maybe a second card. That gap is the whole defense. A velocity limit does not have to be clever. It has to sit in the gap between three attempts and three hundred.
One key is never enough. Attackers rotate IP addresses through residential proxies, so a limit keyed only to IP blocks nobody and blocks real users behind shared connections. The Merchant Risk Council's 2025 survey found card testing hit 33 percent of merchants, and the ones who stopped it fastest were the ones limiting on several keys at once: IP address, device fingerprint, card number, email address, and session. A BIN attack shows why: the generated numbers share a bank prefix, so a limit keyed to the card prefix catches what an IP limit misses.
Five rules, with numbers
These are starting points from Stripe's Radar rules guide and Visa's merchant guidance, not gospel. Tune them against your own traffic for a week before you trust them.
First, block an IP with more than one successful authorization in the past hour. A real customer buys once, then stops. Second, block a card number with more than one blocked payment in the past hour. Third, block an IP that tries more than three different cards in an hour. Fourth, block a customer or email that tries more than two cards in a day. Fifth, cap total authorization attempts at 10 in five minutes from any single IP, device, or session, and hold the block for an hour.
That last rule is the one that matters most, because it targets the mechanism. The attack needs hundreds of attempts a minute and a real shopper needs three. Ten in five minutes is generous to the shopper and fatal to the bot. 3-D Secure 2 adds a second layer on top of these rules, stepping up the risky attempts with a challenge while the clean ones pass straight through.
What breaks when you get the numbers wrong
Too tight, and you block real buyers. A family sharing one IP, an office behind one NAT, a university dorm: all of them look like one address trying several cards. That is why the rules above use several keys and why the card-count rules matter more than the raw attempt count. A household tries two cards. A bot tries forty.
Too loose, and you pay for it twice: once in authorization fees on thousands of attempts, and again when your acquirer notices. Visa's Acquirer Monitoring Program has included enumeration criteria since April 2025, so a testing attack that runs for a weekend can put your processing relationship under review. Set the rules, watch the first week of blocks, and adjust the numbers until the blocks are nearly all bots. Then leave them alone. Velocity rules are the rare control that gets better the less you touch it.
Frequently asked questions
What is a velocity rule?
A velocity rule caps how many payment attempts can come from one key, like an IP address, device, card number, or email, in a set window. It stops card testing because the attack needs hundreds of attempts a minute and a real shopper needs three.
Why do I need more than one velocity key?
Attackers rotate IP addresses through residential proxies, so an IP-only limit blocks nobody. Limiting on IP, device, card number, email, and session at once catches the rotation, because the bot cannot change all five at the same time.
What is a good starting velocity limit?
A practical starting rule blocks any IP, device, or session past 10 checkout attempts in five minutes, holding the block for an hour. Stripe's examples also block an IP with more than one successful authorization per hour, and more than three cards per hour.
Can velocity rules block real customers?
Yes, if they are too tight or keyed to IP alone. Families, offices, and dorms share IPs and try several cards. Use several keys, watch the first week of blocks, and tune until the blocks are nearly all bots.