Card Testing Detection Device Buying Guide for US Merchants
Buy a card testing detection device by matching detection coverage to your payment flow, then verify latency, alert quality, and audit logs in a short pilot.
Card Testing Detection Platform: How Detection Works
Short answer
A card testing detection platform scores each payment attempt and stops runs of stolen card numbers before capture. It reads attempt rates per card, per device and per IP, authorization response codes, and mismatch rates on address and CVV checks. Rules catch crude attacks. Models catch attacks that spread one try across many cards.
What card testing looks like in the data
An attacker pushes a list of card numbers through a checkout form. Each number gets one or two tries. Numbers that authorize get marked for resale or for a larger purchase. The pattern shows up in order logs:
- Many distinct card numbers tried on one merchant within minutes.
- First authorizations at $0 or $1, then a larger charge.
- Decline rates above 80 percent on a burst of attempts.
- One device or one IP across dozens of card numbers.
- Cardholder names and billing addresses that repeat with different numbers.
- Card BINs from the same issuer range in sequence.
Signals the platform scores
Velocity
Counts of attempts per card, per device fingerprint, per IP, per email and per BIN range over fixed windows. A single card with 5 attempts in 10 minutes is a different event from 500 cards with 1 attempt each.
card testing detection program
Authorization response patterns
Issuer response codes carry information. A run of do not honor or invalid card number replies in a short window points to enumeration. So does a spike in insufficient funds across unrelated cards.
Card Testing Detection Procedure Guide
Identity mismatch
Rates of AVS failure and CVV failure on new accounts. Card testing produces high mismatch rates because the attacker holds the number, not the billing address. A merchant whose baseline mismatch rate is 2 percent and sees 40 percent on one hour of traffic has a signal.
Device and network reputation
Proxy and datacenter IP ranges, headless browser fingerprints, and device IDs that appear across many customer accounts. Card testing scripts leave artifacts in these fields.
What the platform does when a rule fires
- Block the attempt and return a decline the attacker cannot distinguish from an issuer decline.
- Force 3-D Secure step-up on the account or the BIN range.
- Rate-limit the endpoint by IP and device.
- Queue the order for manual review.
- Write the event to a case file with the card fingerprint and device ID.
Silent blocking matters. A clear error message tells the attacker which numbers are live.
Numbers to track
- Attempts per card per 24 hours.
- Decline rate by hour and by BIN.
- AVS and CVV mismatch rate against a rolling baseline.
- Share of orders from datacenter IP ranges.
- Chargeback count 30, 60 and 90 days after a burst.
Card testing costs show up twice: authorization fees at the moment of the attack, and chargebacks weeks later. Both belong on the same report.
Limits
Detection platforms see only their own merchant's traffic. An attacker who sends one attempt per merchant stays under most velocity thresholds. Network-level data from issuers and acquirers closes part of that gap. No platform catches all attempts, and a low decline rate is not proof of safety. PCI DSS requires lockout after no more than 10 invalid authentication attempts, which sets a floor for account protection but does not address guest checkout.