The strongest first line of defense against card testing is a layered velocity check: real-time limits applied at the same time to the card number, BIN, IP address, device fingerprint, email, and customer ID, with every rule returning a reason code your team can review. This guide covers which dimensions catch which attack pattern, how to set thresholds from your own traffic instead of guesswork, and how to pair velocity rules with decline-rate and CVV signals so you stop the attack without turning away good customers. The criteria used throughout are detection speed, dimension coverage, threshold tunability, false-positive cost, and auditability.
Why card testing looks like a velocity problem
Card testing is the practice of pushing large numbers of small authorization attempts through a merchant to find out which card numbers are live. The attacker does not care about the goods. The attacker cares about the response code. That focus produces a signature in your logs: bursts of low-value attempts, many distinct card numbers from few sources, high decline ratios, and a sudden spread of BINs and countries that never appeared in your normal traffic.
Because the attack depends on repetition, counting events over time is the cheapest reliable detector. A single authorization request tells you almost nothing. Forty requests from one device in six minutes tells you a great deal.
Dimension 1: card number velocity
Count attempts per card number across short and long windows. A real customer may retry a card two or three times after a typo or a soft decline. A tested card usually appears once or twice and never returns, which means card-level counts catch clumsy attacks and miss distributed ones.
- Pro: near-zero false positives at a limit of four attempts per card per 24 hours.
- Pro: trivially cheap to compute from data you already store.
- Con: useless against attackers who use each number only once.
Dimension 2: BIN velocity
Group attempts by the first six to eight digits of the card. Attackers often work through a purchased range, so BIN counts rise before any individual card looks suspicious.
- Pro: catches enumeration inside a single issuing range.
- Pro: pairs well with BIN country versus IP country mismatch.
- Con: legitimate spikes occur during payroll days, campus events, or a promotion aimed at one bank.
Dimension 3: IP and subnet velocity
Count attempts per IP, then roll up to the /24 subnet. Botnets rotate addresses, but they often rotate within a narrow hosting range, so subnet counts recover much of the signal that raw IP counts lose.
- Pro: exposes datacenter and proxy traffic quickly.
- Con: mobile carriers and corporate NATs place thousands of real buyers behind one address.
- Mitigation: set different limits for residential, mobile, and hosting ASNs rather than one global number.
Dimension 4: device fingerprint
A fingerprint built from browser and hardware attributes survives IP rotation and often survives cookie clearing. Attempts per fingerprint per hour is the single highest-signal rule for digital-goods merchants.
- Pro: strong against scripted attacks that reuse one automation stack.
- Con: fingerprints collide on identical corporate hardware and can drift after browser updates.
Dimension 5: email and phone
Disposable domains, plus-addressing tricks, and sequential numeric local parts cluster tightly during an attack. Keep a list of domains you have seen abused on your own site rather than relying on a purchased blocklist.
Dimension 6: account and customer ID
Count attempts per authenticated account and per saved customer record. This catches an attacker who has valid credentials and is using your checkout as a testing rig.
Setting thresholds from your own baseline
Do not copy limits from a blog post. Pull ninety days of authorization data, compute the 99.5th percentile of attempts per dimension per hour, and start your first rule slightly above that value. Run new rules in shadow mode for two weeks, log what they would have blocked, and confirm the flagged population is mostly decline-heavy traffic. Then enforce.
- Measure the 99.5th percentile per dimension for each traffic segment.
- Draft a rule set with separate ceilings for card, BIN, IP, subnet, device, and email.
- Shadow for two weeks and label each hit as attack, unclear, or good customer.
- Enforce, then review hits weekly for the first month.
Pairing velocity with non-velocity signals
Velocity alone misses the slow-and-low attacker who stays under every limit. Combine counts with CVV mismatch rate, AVS result distribution, authorization decline ratio per device, and the share of attempts under one dollar. A device with twelve attempts, nine declines, and a median ticket of 0.50 USD is a stronger case than any single count.
Response options and their trade-offs
Hard block
Blocks the request at the edge. Best for confirmed automation and hosting-range traffic. Worst for shared IPs, where a block removes real buyers.
Step-up authentication
Forces 3-D Secure or a one-time code on flagged attempts. Preserves conversion on genuine customers and raises the attacker's cost per test. Adds friction and depends on issuer support in the card's market.
Manual review queue
Slows the response but protects revenue on high-ticket orders. Needs staffing and a clear SLA, so it works poorly as the only control.
Where velocity checks fall short
Distributed attacks that spread one attempt across many IPs, devices, and BINs can stay under every threshold. Slow attacks that pace attempts over days do the same. Cover both with issuer-side decline monitoring, behavioral signals at checkout, and a rule that flags any new customer whose first order authorization amount is below your normal minimum.
Recommended setup by use case
Small merchant on a hosted processor: enable the built-in velocity and card-testing rules, then add one custom rule for attempts per email per hour. Low maintenance, limited dimension coverage.
Digital goods or subscriptions: custom rules on device fingerprint and BIN plus step-up authentication on first orders. Higher engineering cost, the best protection per dollar for instant-delivery inventory.
Marketplace with many sellers: per-seller thresholds with a shared global ceiling, so one compromised seller account cannot test cards against the whole platform.