What velocity checks catch during card testing
A velocity check counts how often one attribute appears inside a fixed time window and then blocks or challenges the request once that count passes a limit. In card testing the counted attribute is usually the card number, the device fingerprint, the IP address, the email, or the customer account. Attackers push large batches of low-value authorizations to learn which stolen numbers are still live, so the number of distinct cards, attempts, and declines per session climbs far above normal long before chargebacks appear.
Signals worth counting
- Distinct card numbers per IP, device, or account
- Authorization attempts per card in 10 minutes, 1 hour, and 24 hours
- Declines and do-not-honor responses per session
- CVV and address verification mismatches per device
- Issuer country changes on one account
- New accounts created per IP subnet per hour
How to configure the rules
- Log every authorization attempt with card fingerprint, IP, device ID, email, account age, amount, and response code.
- Define three windows, typically 1 minute, 1 hour, and 24 hours, and count both distinct cards and total attempts in each.
- Set a soft limit that triggers a step-up challenge such as 3D Secure and a hard limit that blocks outright.
- Keep the hard limit tight for accounts younger than 30 days and loosen it for accounts with a payment history older than 90 days.
- Send blocked attempts to a review queue and tag each record with the rule that fired.
- Review the queue weekly and move thresholds according to the false-positive rate you measure.
- Replay 90 days of historical traffic against new thresholds before you deploy them.
Tuning without blocking good customers
Households, shared offices, and corporate cards produce real clusters of cards on one IP, so treat raw IP counts as weak evidence and pair them with device and account signals. Weight attempts that fail authorization higher than attempts that succeed, because a legitimate customer rarely retries a card more than twice. Cap the number of card numbers a single account can add in one day, and require the same payment method to stay attached for a short holding period before a second order ships.
What to do when a rule fires
Log the identifier, the counter value, the window, and the rule ID. Decline the authorization with a generic response so the attacker learns nothing about which limit was hit. Flag the account for manual review, and if a cluster of cards traces back to one device, block the device rather than the individual card numbers. Report confirmed testing bursts to your acquirer, since the compromised BIN ranges usually affect other merchants as well.
Pair velocity checks with other controls
Velocity rules work best next to address verification, CVV checks, device fingerprinting, and issuer authentication. No single counter separates a testing burst from a busy but honest customer, and thresholds tuned on one signal alone tend to produce either gaps or false declines. Review the combined rule set each quarter as traffic patterns shift.