Card Testing Log Analysis Tools: Fraud Team Guide

Card testing log analysis tools read payment gateway records, web server logs, and WAF logs, then group events by IP, device, and card fingerprint to find bulk authorization attempts. Four categories cover most setups: SIEM and log platforms (Splunk, Elastic, Microsoft Sentinel, Sumo Logic), CDN and WAF log tools (Cloudflare, Akamai, Fastly, AWS WAF), processor fraud engines (Stripe Radar, Adyen Risk, Braintree, Checkout.com), and dedicated fraud vendors (Sift, Forter, Kount, Riskified, Feedzai).

What card testing looks like in a log

Card testing is a script that submits many authorization requests to learn which card numbers are live. Approvals get kept. Declines get discarded. The attacker pays nothing for the failed attempts.

Log signatures to look for:

• Many small authorizations, $0.00 to $1.00, from one IP or ASN inside a short window.
• Distinct card tokens per IP above 10 in 10 minutes.
• Card numbers inside one BIN range with sequential or near-sequential digits.
• AVS and CVV mismatch on most attempts.
• Short sessions, no cart, no shipping address, no account.
• The same user agent string across hundreds of sessions.

Log fields you need

• Timestamp with timezone.
• Client IP and ASN.
• Device fingerprint or cookie ID.
• Session ID.
• Card BIN, last four digits, and processor token.
• Amount and currency.
• Authorization response code.
• AVS result and CVV result.
• Request path, method, and user agent.
• Merchant account ID.

Missing any of the first six fields makes velocity rules hard to tune. Missing the response code makes it impossible to separate real declines from noise.

Tool categories

SIEM and log platforms

Splunk, Elastic, and Sentinel correlate the payment gateway stream with the web tier. Ingest cost scales with volume, so drop full request bodies and keep parsed fields.

WAF and CDN logs

Cloudflare, Akamai, and Fastly hold the request layer. Rate rules, bot scores, and managed challenge results live here. Export these to the SIEM so one query joins both sides.

Processor fraud tools

Stripe Radar, Adyen Risk, and Braintree score the authorization stream. Rules can block on BIN, velocity, and risk score before the request reaches your stack. These tools see the card data, so your own logs do not have to.

Dedicated fraud vendors

Sift, Forter, Kount, Riskified, and Feedzai take an event feed and return a decision. They add device and network history across merchants, which a single merchant cannot build.

Query patterns that work

1. Count distinct card tokens per IP per 10-minute window. Alert above your baseline.
2. Count distinct IPs per card token. One card tried from 20 IPs is account takeover, not card testing.
3. Group declines by BIN over 24 hours. A spike in one BIN points at an enumeration run.
4. Count authorizations per session ID. Real buyers submit one to three.
5. Join WAF bot score to authorization volume. High volume plus low bot score confirms automation.

PCI limits on what you may log

PCI DSS bans storing sensitive authentication data, including the CVV and full track data, after authorization. Log the BIN, the last four digits, or a processor token instead of the full account number. Scrub card numbers from request bodies before ingest. A log store that holds PANs falls inside PCI scope and needs the same controls as the payment system.

Known gaps

• Log sampling hides low-volume runs. Sample at the gateway, keep payment logs complete.
• False positives come from subscription retries, gift card balance checks, and BIN lookup tools.
• Short retention windows lose the evidence needed for chargeback disputes.
• Blocking at the IP layer fails against residential proxy pools. Combine IP, device, and card signals.