Card Testing Velocity Rules: The Short Answer

A velocity rule caps how many transactions one identifier can generate inside a set time window. To stop card testing, run counters on at least four identifiers: card fingerprint, IP address, device fingerprint, and BIN. Start with 3 to 5 authorization attempts per card per hour, 10 to 20 attempts per IP per hour, and 5 attempts per device per hour. Any counter that trips moves the order to review, step-up authentication, or a hard block, in that order.

velocity checks for card testing

Card testing works by pushing many low-value authorization attempts through a merchant until some approve. Velocity rules are the cheapest control against that pattern because they do not depend on the card being known as stolen. They depend only on the shape of the traffic.

how velocity checks prevent card testing

Prerequisites

  • Access to your gateway or risk engine rule builder.
  • At least 90 days of authorization logs with card fingerprint, IP, device ID, email, and response code.
  • A queue or alert channel for manual review.
  • A 3D Secure step-up option, or the ability to decline on rule match.

How to Build the Rules

  1. List every identifier you can count on an authorization request: card fingerprint, BIN, IP, device ID, email, phone, and billing ZIP.
  2. Pick two base windows. One short window of 1 hour catches bursts, and one long window of 24 hours catches slow grinding.
  3. Create the card counter. Count authorization attempts per card fingerprint per hour and per day.
  4. Create the IP counter. Count attempts per IP per hour, and keep a separate counter for IPs sharing a subnet.
  5. Create the device counter. Count attempts per device fingerprint per hour.
  6. Create the BIN counter. Count attempts per BIN per hour to catch attacks that rotate card numbers inside one range.
  7. Create an email and billing ZIP counter. Count distinct cards per email address and per ZIP per day.
  8. Weight the counters by response code. Treat do-not-honor and invalid-card responses as heavier than insufficient-funds, since testers generate the first two in volume.
  9. Attach an action to each threshold. Set review at the first tier, 3DS step-up at the second, and block at the third.
  10. Log every rule match with the identifier values and the counter total, so you can rebuild the sequence later.

Choosing Time Windows and Thresholds

Thresholds depend on your order volume. A merchant doing 200 orders a day can block at 3 attempts per card per hour without hurting real customers, while a subscription merchant with retry logic needs a higher card ceiling and a separate counter for legitimate retries. Always exempt your own recurring billing traffic by tagging it before it hits the rule engine.

more on this topic

Shared IP addresses cause most false positives. Corporate networks, mobile carriers, and public Wi-Fi all place many buyers behind one address, so pair the IP counter with a device counter and require both to trip before you block. If only the IP counter trips, send the order to review instead.

related article

Reviewing and Tuning

Pull the rule matches weekly and sort them into confirmed fraud, false positive, and unclear. Raise a threshold when false positives cluster on one merchant segment, and lower it when confirmed fraud lands just under the ceiling. Track the median attempt count of confirmed fraud cases, then set the block tier slightly below that median. Recheck the whole rule set after any product launch or promotion, because new traffic patterns change what normal looks like.