Short answer
A velocity check counts payment attempts that share one attribute, such as a card identifier, IP address, device, or email, inside a set time window. Card testing produces a burst of small authorizations from one source against many cards, or many sources against one card, so the count breaks the normal pattern and the rule fires. The check does not prove fraud on its own. It raises risk for that transaction and triggers a step-up, a block, or a manual review.
What card testing looks like in the data
Card testing validates stolen card data by running small purchases, often under a dollar, on a merchant with loose authorization rules. An approved attempt confirms the card is live. The signals that separate this traffic from normal shopping are the shape of the burst:
- Attempt counts per card, IP, or device that exceed the population baseline
- Tight timing between attempts, often seconds apart
- Low average order value compared with the merchant mix
- High decline rates and repeated soft declines on the same attribute
- Guest checkout or new accounts used for most attempts
Dimensions worth counting
A single counter misses most attacks because attackers rotate the attributes they control. Count several at once and combine them into a composite key.
- Hashed card number, so the counter works without storing the PAN in clear text
- IP address and IP subnet
- Device fingerprint and browser signals
- BIN range and issuer
- Email address and email domain
- Billing address and shipping address
How to build and tune the rule
- Pick one attribute to count first, usually the card identifier or the device fingerprint.
- Set the window from your own traffic, starting near 10 minutes for card counts and 1 hour for IP counts.
- Add BIN and email to the key so one reused attribute cannot hide a broad attack.
- Log every attempt with the full attribute set before you enforce anything.
- Run the rule in monitor mode for two weeks and record the volume of matches.
- Move the threshold to the level that catches known test traffic without touching normal repeat buyers.
- Attach a response to each threshold band, then review the numbers weekly.
Response actions
Match the response to the confidence level. One attribute over a soft limit earns a 3-D Secure challenge or a CAPTCHA. Two attributes over the limit earns a session block. Sustained counts across many cards from one address range earns a network level block and a report to your acquirer.
Limits of velocity checks
Distributed card testing spreads attempts across thousands of addresses, so per-IP counters stay low. Attackers also rotate cards and route traffic through residential proxies. Pair velocity rules with BIN level limits, authorization rate monitoring, and device reputation. Watch your decline rate by BIN as well, since a spike in declines on cards from one issuer often arrives before the velocity rule fires.
Metrics to track
- Attempts per attribute per window against the threshold
- False positive rate on repeat customers
- Authorization approval rate by BIN
- Time from the first test attempt to a rule match