The top pick for card testing detection is a layered stack: gateway-side velocity and BIN rules as the first filter, issuer decline and CVV/AVS mismatch data as the second, and an automatic challenge or block as the third. The criteria that separate a working setup from a noisy one are detection latency, false-positive rate, the manual review hours each alert costs you, and how fast you can scope a rule to a single IP, card BIN, or email domain.
Card testing is the practice of running many small authorization attempts against stolen card numbers to learn which ones still work. The merchant eats the interchange fees, the chargeback exposure when the surviving cards come back for real orders, and often the network fines that follow. Detection is less about catching one bad order and more about seeing the pattern across a burst of attempts.
The signals that carry the most weight
- Authorization attempt velocity per IP, device fingerprint, and card BIN
- Many different card numbers touched from one session, cookie set, or device
- CVV or AVS mismatch ratios that spike across a small batch of orders
- Uniform order values, often rounded or just below a low free-shipping threshold
- Accounts created minutes before checkout, disposable email domains, billing and shipping geography that do not match the issuing country
- Decline bursts, where one source produces dozens of declines in a few minutes
- Checkout completed faster than a human can type, or with forms filled in a single pass
Detection approaches compared
Gateway velocity and BIN rules
Most payment gateways and fraud modules let you cap authorization attempts per IP, per card, and per BIN over a rolling window. Rules are deterministic, cheap to run, and easy to explain when a customer disputes a block.
- Pros: fast to deploy, no data science, transparent logic, low cost at low volume
- Cons: attackers rotate IPs and BINs, fixed thresholds create false positives on shared corporate networks and carrier NAT
Recommended for small and mid-size merchants who need a first layer today and can tune thresholds weekly.
Machine learning risk scoring
Risk engines score each order against historical patterns, pulling in device, browser, email, and behavioral features alongside the transaction.
- Pros: catches distributed attacks that stay under fixed thresholds, adapts as the fraud pattern shifts
- Cons: needs order volume to train well, opaque scoring, and ongoing tuning to keep false positives down
Recommended for catalogs with steady volume and a wide range of legitimate customer behavior that would break simple caps.
3-D Secure challenges
Sending a step-up challenge to the issuing bank forces authentication before authorization. Testers usually abandon rather than complete it.
- Pros: blocks automated attempts at the source, can shift liability on eligible transactions, strong signal that the cardholder is present
- Cons: adds friction and can cost conversions, not every issuer supports it, exemptions still need rule logic
Recommended for high-risk verticals, cross-border orders, and new customers while you build history on returning ones.
Checkout hardening and honeypot fields
Hidden fields, rate limits on the payment endpoint, CAPTCHA after repeated failures, and required CVV entry all raise the cost of automation.
- Pros: no vendor needed, stops crude bots, improves every other layer
- Cons: does not stop residential proxy networks or hand-typed testing, can annoy real buyers if overdone
Recommended for any merchant running a custom checkout or a self-hosted storefront.
Build versus buy criteria
Score each option on the same five points before you commit. First, time to first block: how long until a rule is live. Second, tuning effort per week. Third, false-positive rate on known good orders. Fourth, whether you can export the decision data for your own analysis. Fifth, how the tool behaves during a spike, since card testing arrives as a burst, not a trickle.
Response playbook during a live attack
- Confirm the pattern in the authorization log, not just the order list, and note the time window.
- Block the narrowest identifier first: the IP range or device ID, not the whole country.
- Add a temporary BIN rule if the attempts cluster on one issuer range.
- Turn on a challenge for the affected channel while leaving the rest of the storefront untouched.
- Refund or void any test orders that slipped through, and flag the cards in your system.
- Log the attack window and update thresholds so the same pattern trips sooner next time.
Metrics worth tracking
- Authorization attempts per approved order, by hour
- Decline rate split by reason code
- Chargebacks traced back to test orders
- Alerts actioned versus alerts auto-resolved
Detection works when the signal, the threshold, and the response live in the same loop. Review the numbers weekly, tighten one rule at a time, and keep a written record of what each change was meant to catch.