Velocity checks for card testing are fraud controls that count and limit repeated payment activity over a set period. They help merchants and issuers spot bursts of authorization attempts that look automated, such as many cards tried from one device or many low-value orders in a short window.
What card testing looks like in payment data
Card testing is a pattern of payment fraud in which someone submits many card numbers to learn which ones authorize. The goal is usually to find usable cards before reselling them or making larger purchases. In payment data, the pattern often appears as:
- A sharp rise in authorization attempts across many card numbers.
- High decline rates mixed with a few approvals.
- Repeated small orders or account sign-up attempts.
- One device, IP address, email pattern, or phone number linked to many cards.
- Unusual concentration of cards from the same bank identification number range or region.
How velocity checks work
A velocity rule sets a limit for a defined identifier inside a time window. Common counters include attempts per card, per customer account, per IP address, per device, per BIN, and per merchant account. A rule can trigger on raw attempt counts, decline counts, approved order counts, total value, or a mix of these signals.
When a limit is crossed, the merchant can block the payment, require strong customer authentication, send the order to manual review, or rate-limit the account. The right action depends on the risk level and the expected behavior of legitimate customers.
Which velocity limits matter most
- Per-card limits: Cap repeated attempts on one card number in a short period.
- Per-IP and device limits: Flag one network or device trying many cards.
- Per-account limits: Watch new accounts, email addresses, and phone numbers tied to many payment attempts.
- Per-BIN limits: Detect unusual bursts from a card range or issuer country.
- Merchant-wide limits: Spot overall spikes that exceed normal daily patterns.
Layered controls that support velocity checks
Velocity checks work best with other payment security controls. Address verification and card verification value checks add data points. Device fingerprinting and IP reputation help link attempts. 3-D Secure authentication can add a challenge for risky payments. Machine learning models can compare current behavior with past fraud patterns. Chargeback monitoring closes the loop by showing which rules miss losses.
Tuning thresholds without blocking good customers
Start with conservative limits, then review blocked and challenged orders. Segment rules by channel, country, customer type, and order value. Keep a review queue for edge cases. Track false positives and adjust windows and thresholds. A rule that is too tight can reject legitimate buyers, while a rule that is too loose lets card testing continue.
Responding to a suspected card testing attack
- Raise the risk action for affected identifiers, such as requiring authentication or manual review.
- Rate-limit or block the IP address, device, account, or BIN range tied to the burst.
- Review authorization logs for patterns across cards, times, and order values.
- Notify your payment processor or acquirer if the activity is large or persistent.
- Update velocity rules and document the change for your fraud team.
Velocity checks are not a complete defense, but they are a practical first layer. Combined with authentication, device intelligence, and manual review, they reduce the window in which card testing can operate.