Card testing log analysis is the practice of mining payment gateway, web server, and API logs for the fingerprint of automated card testing: tight bursts of small authorization attempts, abnormally high decline ratios from a single source, and rapid sequential requests that never convert into real orders. Testers need volume to find live card numbers, and volume leaves a dense trail that legitimate shoppers do not create. The goal of the analysis is to isolate that trail within minutes, not days, and to tie every suspicious request back to a device, IP range, or merchant endpoint.
What does card testing look like in raw logs?
Automated testing produces machine rhythm. Requests arrive at near-constant intervals, often 50 to 500 milliseconds apart, from the same subnet or ASN. The card numbers share a common bank identification number (BIN) prefix, and the same email or phone value reappears across dozens of attempts.
Human traffic is noisy and irregular. Bots are not. When a single client fingerprint generates 200 authorizations in 10 minutes and sells nothing, the pattern is the signal.
Which log fields matter most?
You cannot detect what you never capture. At minimum, your payment and edge logs should retain the following fields with timestamps precise to the millisecond.
- Source IP, ASN, and geolocation, plus whether a proxy or VPN was used
- Device fingerprint, user agent string, and TLS or JA4 fingerprint
- Card BIN, last four digits, and issuer country
- Authorization response code and decline reason
- Order value, item count, and cart lifetime
- Session ID, account ID, and email hash
- Endpoint path and API key used for each attempt
Which thresholds should trigger an alert?
Fixed thresholds work better than intuition. Common starting points include more than 10 authorization attempts from one IP in 5 minutes, a decline rate above 70 percent for a single fingerprint over an hour, and more than 5 distinct card numbers tried against one account.
Tune these numbers against your own baseline. A subscription business and a digital goods store will have different normal decline rates.
How do you run a card testing investigation step by step?
- Pull all authorization events for the alert window and group them by IP, fingerprint, and card BIN.
- Rank each group by attempt count and decline ratio to find the loudest cluster.
- Trace the cluster backward to the entry endpoint and forward to any successful captures.
- Check whether any approved transaction shipped or delivered before the attack ended.
- Block the cluster at the edge, then re-run the query 24 hours later to confirm the traffic stopped.
What separates a small probe from a full BIN attack?
A probe is a few dozen attempts used to test whether your gateway will reject stolen numbers. A full BIN attack is thousands of attempts spread across hundreds of IPs, often with rotating fingerprints and low per-IP volume designed to slip under rate limits.
When per-IP counts look clean but the aggregate decline rate for a BIN range spikes, your detection has to shift from IP-based rules to velocity rules grouped by BIN and issuer.
Why does log retention change your detection ceiling?
Most testers return within days using the same infrastructure. If you keep raw authorization logs for only 24 hours, you lose the ability to correlate repeat offenders across campaigns and you re-block the same ranges by hand.
Retain structured authorization logs for at least 90 days in a queryable store, separate from general application logs, so correlation queries stay fast. Keep payment data out of those logs and store only tokens, BIN, and last four digits.
What should happen after you confirm an attack?
Contain first, then measure. Block the offending ranges and fingerprints, force step-up verification on any account that was touched, and void or refund unauthorized captures. Document the timeline, because card networks may require an incident summary if chargebacks follow.
Finally, feed the confirmed indicators back into your rules and monitor the same query daily. Card testing log analysis is only useful when it runs continuously.