Card Testing Log Analysis

Card testing log analysis means reading authorization, gateway, and web server logs to find many low-value payment attempts that share a small set of fingerprints. The goal is to identify the attack window, the endpoints being hit, and the identifiers that repeat, then block on those identifiers. Start with timestamps, then group by IP, card BIN, and device.

Signals that matter

  • Decline rate spikes on small amounts, usually under $5.
  • Many distinct card numbers from one IP or ASN in a short window.
  • Sequential or adjacent BIN ranges inside the same minute.
  • Checkout attempts with no cart activity or a direct POST to the payment endpoint.
  • Successful authorization responses that never reach an order confirmation.

Prerequisites

  • Access to gateway or PSP authorization logs with timestamp, amount, card BIN, response code, and IP.
  • Web server or CDN access logs for the same window.
  • A way to export records to a spreadsheet or query engine.
  • A clock reference. Confirm log time zones are aligned before comparing sources.

Steps

  1. Pick the window. Start from the first alert or the first support ticket about declined charges, then pull 24 hours before and after it.
  2. Export authorization records for that window. Keep timestamp, amount, response code, BIN, last four, IP, and merchant order reference.
  3. Normalize every timestamp to UTC. Misaligned zones will hide the burst.
  4. Filter to attempts under your low-value threshold. Set that threshold at the 5th percentile of your normal order value.
  5. Count attempts per IP per hour. Flag any IP above the 99th percentile of your baseline.
  6. Count distinct card BINs per IP. One IP touching more than a handful of BINs in an hour is a strong signal.
  7. Group by response code and split issuer declines from gateway rejects. The mix tells you whether the attacker is guessing valid numbers or probing your rules.
  8. Join the web logs to the payment logs on timestamp and session ID. Look for direct POSTs to the payment endpoint with no prior cart or checkout page view.
  9. Check user agents and TLS fingerprints. Scripted clients cluster on a few user agents that do not match your normal browser mix.
  10. Score each candidate cluster. Weight BIN diversity and request velocity above raw attempt count.
  11. Write the findings into a blocklist: IP, ASN, user agent, and card BIN range for the confirmed window.
  12. Re-run the same query over the next 48 hours to confirm the burst has stopped.

What a confirmed pattern looks like

A typical burst runs 10 to 40 minutes. Requests arrive at even intervals because the tool is scripted. Amounts stay fixed or step through a few values. The same IP or a small ASN block carries most of the traffic. Almost all attempts fail, and the few successes are never followed by a shipping address or a repeat visit.

Common false positives

  • Corporate NAT. One IP can represent hundreds of real buyers.
  • Gift card balance checks, which are low value and repeated by design.
  • Subscription retries after a card expires.
  • Test mode traffic that shares infrastructure with production logs.

After the analysis

Report the window, the identifiers, and the volume to your PSP. Add rate limits at the endpoint, require a session token before the payment call, and save the log query as a recurring alert so the next burst surfaces without manual work.