What log analysis reveals about card testing
Card testing is a burst of authorization attempts that use stolen card numbers to find which ones still work. The attacker expects most attempts to fail, and that failure rate is the signal. When you read gateway responses and checkout logs together, card testing shows up as an unusual concentration of hard declines and near-zero-dollar orders coming from a small pool of IP addresses, devices, or email domains inside a short window. Manual review rarely catches it in time because a scripted run finishes in minutes. Log analysis catches it because the pattern lives in the metadata, not in any single transaction.
Prerequisites
- Raw access logs, application logs, and payment gateway response logs stored in a queryable format for at least 30 days.
- Unique request identifiers that join a checkout attempt to its gateway response.
- A baseline of normal decline rates by card brand, country, and payment method.
- Permission to throttle or block traffic at the edge, not just flag it.
Detection procedure
- Pull every authorization request from the last 24 hours with timestamp, IP, user agent, device fingerprint, card BIN country, amount, and response code.
- Normalize response codes into three buckets: approved, soft decline (insufficient funds, retry later), and hard decline (stolen card, invalid account, do not honor).
- Group the rows by IP address and count hard declines per group.
- Repeat the grouping by device fingerprint, email domain, and card BIN prefix.
- Rank each group by hard declines divided by total attempts, then keep the groups whose ratio sits far above your baseline.
- Cross-check the top groups against timing, since card testing runs show tight intervals, often under five seconds between attempts.
- Count distinct BIN prefixes inside each group. One card failing is a customer problem. Hundreds of BINs failing through one IP is a test run.
- Check for amount clustering at the smallest value your gateway accepts, including zero-dollar and one-dollar authorizations.
- Score each candidate group and write the result to a watchlist table with a timestamp.
- Feed the watchlist into edge rules so repeat offenders meet a block or a challenge before the next burst.
Signals worth weighting
Decline code composition
A high share of do-not-honor and invalid-account codes points to a list of dead or stolen numbers. Soft declines spread evenly across a population look like normal customer behavior.
Velocity shape
Healthy traffic rises and falls with the day. A test run spikes hard for a few minutes, stops, and returns from a related IP range. Measure attempts per minute, not attempts per day.
How to Analyze Logs for Card Testing: A Merchant Detection Guide
Infrastructure reuse
Watch for one user agent string across many sessions, datacenter ASNs mixed with residential traffic, and disposable email domains created in the same hour.
Order behavior
Test orders often skip shipping fields, pick the cheapest item, and abandon immediately after an approval. Tie that behavior back to the IP group that carried the declines.
Tuning out false positives
Gift card buyers, subscription retries, and shared corporate networks all produce decline clusters. Exclude known merchant IP ranges, set a minimum attempt count before a group becomes a candidate, and re-check any rule that fires more than a few times a day against a random sample of the flagged rows. If the sample is full of ordinary customers, raise the threshold instead of blocking.
Responding to a confirmed burst
Block the source at the edge, void approvals that used cards from the same BIN range during the window, and refund the test charges. Log the block reason with the rule identifier so the next analyst can trace why the decision was made.