Card Testing Detection Device Buying Guide
Discover the essential features and considerations when purchasing a card testing detection device for online security.
Card Testing Detection Methods: Spot and Stop Attacks
Card testing detection in one paragraph
Card testing detection is the practice of finding bursts of small authorization attempts that attackers use to check whether stolen card numbers are live. You detect it by correlating four signals inside the same time window: a spike in authorization attempts from a narrow set of IP addresses or ASNs, a high ratio of declines and CVV or AVS mismatches, order values that cluster at or below a fixed threshold, and device or session fingerprints that repeat across many card numbers. No single signal is enough on its own. Two or more together, measured against your own baseline, is what separates an attack from a busy sale day.
Prerequisites
- Read access to gateway and authorization logs with BIN, response code, IP, session ID, and timestamp.
- Order records joined to session ID or device fingerprint.
- A baseline of normal authorization volume by hour, country, and channel.
- The ability to change gateway rules, rate limits, or WAF rules without a code deploy.
Detection procedure
- Export authorization records for the last 24 hours with response code, amount, IP, BIN, and session ID.
- Group the records by IP address and count attempts per hour.
- Flag every IP above your normal ceiling, which for consumer traffic is often 10 attempts per hour.
- Group the flagged IPs by ASN and country.
- Mark ASNs that belong to hosting providers, VPN services, or relay networks.
- Count how many distinct card BINs each flagged IP submitted.
- Flag any IP that submitted more than five distinct BINs.
- Pull the response code mix for the flagged IPs.
- Flag IPs whose decline rate exceeds 70 percent.
- Check the amount distribution for the flagged set.
- Flag clusters where more than 80 percent of attempts fall under two dollars.
- Join the flagged IPs to session IDs and device fingerprints.
- Count how many card numbers share a single fingerprint.
- Flag fingerprints tied to more than three distinct card numbers.
- Compare the flagged set against the same hour one week earlier.
- Write the intersection of at least three signals into a review queue with the raw evidence attached.
Why the intersection matters
A single IP with a high attempt count can be a shared office network. A wave of declines can be an issuer outage. A cluster of one dollar orders can be a legitimate digital product. When IP velocity, BIN spread, decline rate, amount clustering, and fingerprint reuse all point at the same records, the odds of a false positive drop hard. Reviewers who act on one signal alone block real customers and miss the attack that hides below their threshold.
Threshold tuning
Set thresholds from your own traffic, not from a vendor default. Pull 30 days of authorization data, compute the 99th percentile of attempts per IP per hour, and use that number as your ceiling. Recompute it monthly. Seasonality matters: a holiday spike in real orders changes the shape of normal traffic, and a fixed threshold will start flagging gift buyers.
Response steps
- Block the confirmed IP addresses and hosting ASN ranges at the gateway or WAF.
- Enable a challenge such as CAPTCHA on the checkout endpoint for the affected country or ASN range.
- Require CVV and AVS match on orders below your low-value threshold.
- Raise the minimum order value for guest checkout on the affected channel.
- Add the reused fingerprints to a watch list rather than a permanent block list.
- File a fraud report with your acquirer and card network if volume crossed your monitoring program limits.
- Log the case, the signals, and the outcome so the next review starts from evidence.
Signals that mislead
BIN alone is a weak filter. Prepaid and gift card BINs carry heavy legitimate use. Decline code alone is weak too, since soft declines, expired cards, and issuer timeouts all produce them. Geographic mismatch loses value once you sell internationally. Treat each of these as one input, never as the verdict.