Card testing pattern detection is the practice of finding the short, fast bursts of small authorization attempts that attackers use to check whether stolen card numbers are live. The core signature is a run of low-value charges, often under one dollar, spread across many card numbers that originate from a small set of IP addresses, devices, or email addresses, paired with a high decline rate. You detect it by counting attempts per card, per BIN, per IP, per device fingerprint, and per email, then blocking or challenging sessions that break your normal baseline.
Card Testing Attack Patterns Guide
Why card testing hides in low-value traffic
A single one-dollar authorization looks harmless on its own. The pattern only appears when you aggregate attempts across a window of time. Attackers rely on this by keeping each individual request small, spacing attempts across many merchant accounts, and rotating card numbers while reusing the same infrastructure. That is why detection depends on group-level counters rather than on any single transaction.
Signals that mark a card testing run
- Many distinct card numbers attempted from one IP address or device fingerprint inside a short window.
- A cluster of authorizations for amounts under a few dollars, including repeated identical amounts.
- Decline rates far above your normal baseline for the same payment processor and card brand.
- Card numbers that fail sequentially, which suggests enumeration rather than real customer behavior.
- New email addresses, disposable domains, or mismatched billing and shipping data on every attempt.
- Traffic that arrives in regular intervals or in a tight spike rather than a natural daily curve.
- CVV and AVS mismatch codes on nearly every attempt in the cluster.
How to detect card testing patterns
- Log every authorization attempt with card BIN, last four digits, IP address, device fingerprint, email, amount, and timestamp.
- Build a rolling 60-minute counter of attempts per IP address and per device fingerprint.
- Add a 60-minute counter of distinct card numbers attempted per IP address and per device fingerprint.
- Add a per-BIN counter of attempts and distinct card numbers over the same window.
- Flag any group that exceeds your attempt threshold while also exceeding your distinct-card threshold.
- Compute the decline rate for each flagged group and compare it with your account baseline for that processor.
- Cross-check flagged groups against CVV and AVS result codes to confirm the pattern.
- Route confirmed groups to a block rule, a step-up authentication challenge, or manual review before the next attempt settles.
Tuning thresholds without breaking good customers
Set your first thresholds from your own data rather than from a vendor default. Pull 30 days of authorizations, calculate the 99th percentile for attempts per IP and per device, and start your rule just above that line. Shared corporate networks, kiosks, and public Wi-Fi produce several legitimate cards from one address, so pair the IP counter with a distinct-card counter to separate normal shared use from enumeration. Review every rule weekly for the first month and loosen any rule that fires on repeat customers.
Containment after you confirm a pattern
- Block the offending IP address, device fingerprint, and email domain at the gateway level.
- Add the abused BIN range to a watchlist with a lower attempt ceiling.
- Report the cluster to your acquirer and payment processor with timestamps and request identifiers.
- Refund or void any authorization that settled from the cluster and document the chargeback risk.
- Rotate any API keys or credentials that the traffic touched.
Document each detection, the evidence that confirmed it, and the action taken. That record supports disputes, helps your processor tighten its own filters, and gives you the baseline data you need to tune the next round of thresholds.