Card testing log analysis is the review of authorization records, web server logs, and device signals to find repeated low-value payment attempts that use stolen card numbers. One declined charge means little. Two hundred declined charges across forty cards in nine minutes is a pattern. The work is to find that pattern in data you already store, then close the endpoint that allowed it.
What the pattern looks like
Card testing produces a burst, not a trickle. Scripts submit many card numbers against one checkout form. The attacker keeps the amount low, often $0 to $2, so a hit does not trigger a large chargeback. The log side effects:
- A short window with a large count of authorization attempts from a small set of IP addresses or one ASN.
- A high share of decline codes that map to invalid, closed, or restricted accounts.
- Sequential or block-ordered card numbers, visible in the BIN and last four digits.
- One device fingerprint or session cookie tied to dozens of distinct cards.
- Fixed gaps between attempts, often 1 to 5 seconds, from a script rather than a person.
- Payment form hits with no product page views in the same session.
Fields to keep in the log record
Store these per attempt, in UTC: timestamp; merchant account; attempt ID; amount and currency; card BIN (first six or eight digits); last four; card issuing country; AVS result; CVV result; gateway response code and text; authorization latency in milliseconds; client IP; ASN; user agent; device ID; session ID; account ID; email domain. Do not store the full card number and never store the CVV. PCI DSS forbids retention of sensitive authentication data after authorization. BIN plus last four gives the grouping you need without the liability.
Metrics that separate testing from normal decline traffic
- Authorization attempts per IP per hour, compared with the 99th percentile of your own traffic.
- Distinct cards per device per hour.
- Distinct BINs per session.
- Decline rate by endpoint, not by merchant overall.
- Count of $0 and $1 authorization attempts per day.
- Median gap between attempts inside one session. Scripts repeat at fixed intervals. People do not.
Set the threshold from your own baseline. A fixed number copied from a vendor deck misfires on high-volume days.
Review order
- Sort authorization attempts by IP for the last 24 hours and count failures.
- Join to session and device records. Flag any device with more than N distinct cards.
- Group decline codes. A spike in "invalid account number" or "pickup card" carries more weight than a spike in "do not honor."
- Check the payment endpoint access log for request rate and user agent strings.
- Cross-check account and email domain age. New accounts on new domains carry more risk.
- Save the slice to a case file before the retention window closes.
False positives
Shared IP space causes noise. Mobile carrier NAT, corporate proxies, and campus networks put thousands of users behind one address. Your own client retry logic creates bursts that look scripted. Processor test cards show up in production logs after a bad deploy. Time zone drift between gateway and web server splits one burst into two. Filter known corporate ranges, tag your own test traffic, and normalize timestamps to UTC before you count.
Containment
Rate limit the payment endpoint at the edge. Add a challenge to the form when a session crosses the card count threshold. Block the ASN rather than the single IP when the burst is wide. Tell your acquirer before chargebacks arrive; card networks track merchant-level testing volume. Keep the evidence, because dispute responses need the attempt record.
Retention and cadence
PCI DSS requires audit log retention of 12 months, with the last three months available for analysis, plus a review process on a defined schedule. A count of declined authorizations by endpoint, run once a day, takes minutes and catches most bursts. A weekly pass covers BIN concentration and device reuse.