Velocity checks are rules that cap how many transactions or attempts a card, device, IP address, email, or account can make inside a set time window. They are one of the primary defenses against card testing, because anyone validating stolen card numbers has to send many small authorization requests in a short burst, and that pattern is exactly what a velocity rule is built to notice.
velocity checks vs card testing
What card testing is
Card testing is the practice of running a large number of low-value transactions against a checkout page to learn which card numbers are still active. Most attempts decline, so the amounts stay small to reduce losses and to slip under amount-based limits. Numbers that authorize are then used for higher-value fraudulent purchases.
The cost to a merchant goes past chargebacks. A wave of failed authorizations distorts decline rates, fills review queues, and can draw attention from the acquiring bank and the card networks.
velocity checks for card testing
How velocity checks work
A velocity rule counts activity along one or more dimensions and compares the count with a threshold:
- Card number or card fingerprint: how many attempts a single card makes.
- IP address: how many different cards are tried from one connection.
- Device fingerprint: attempts tied to one browser or device.
- Account or email: sign-ups and orders from the same address.
- BIN range: attempts grouped by issuing bank prefix.
- Amount and result: many small tickets, a high decline ratio, repeated probe-sized charges.
Thresholds are either absolute, such as a fixed number of attempts per hour, or relative, such as a spike measured against the merchant's normal baseline for that hour of the week. Most fraud platforms combine both and produce a risk score instead of blocking on a single count.
Why velocity checks catch card testing so well
Real shoppers generate sparse, varied traffic. A person buys once or twice from a device and address they have used before, and their approvals follow normal patterns. Card testing looks the opposite: dense clusters of attempts, many cards from one origin, shipping and billing details that do not match, and approval rates far below the site average.
Even when an attacker rotates card numbers, the shape of the traffic gives them away. A checkout page that normally sees a handful of orders an hour does not suddenly see forty attempts from one subnet without a reason.
Controls that work alongside velocity checks
- CVV and address verification checks on every authorization.
- 3-D Secure or another step-up challenge for risky attempts.
- Bot detection and CAPTCHA on the payment step.
- Blocklists for known bad IPs, devices, and BIN ranges.
- Manual review queues for orders the scoring engine flags.
Tuning velocity rules without blocking good customers
Aggressive thresholds stop attacks and also stop legitimate buyers. A short monitoring period solves most of that problem.
- Run new rules in log-only mode for two to four weeks before enforcing them.
- Segment thresholds by sales channel, currency, and customer history.
- Allowlist subscription billing and repeat customers with a clean record.
- Revisit thresholds each quarter, since attack patterns shift.
What to do when a card testing burst hits
- Switch the affected endpoint to its strictest velocity rule set.
- Require authentication on suspicious attempts instead of a straight decline.
- Notify your acquirer and payment processor so they can watch the account.
- Pull the logs, identify the common origin, and add it to your blocklist.
- Keep a written record of the response for any chargeback disputes that follow.
Where velocity checks fall short
A distributed attack spreads attempts across thousands of addresses, so per-IP counts never cross the line. Low-and-slow testing does the same thing over days rather than minutes. Velocity checks catch the common case, which is most of it, and cover the rest when paired with device fingerprinting, behavioral scoring, and authentication.