Card testing leaves a pattern, not a single event. You will see many authorization attempts across many card numbers inside a short window, driven by a small set of IPs, devices, sessions, or accounts. To analyze for it, join your payment gateway records with web server and application logs on a shared key such as request ID or session ID, then rank the result by card-number diversity per identifier, decline rate, attempt velocity, and average ticket size. The single strongest signal is a high count of distinct card numbers tied to one identifier while the approval rate stays near zero.

card testing log analysis tools

Pull these log sources together

• Payment gateway or PSP authorization logs: response codes, amounts, timestamps, card BIN, last four, and any token or reference ID.
• Web server access logs: request path, status code, user agent, response time, source address.
• Application logs: session ID, account ID, device fingerprint, email used at checkout, cart contents.
• WAF and bot management logs: rule matches, challenge results, TLS fingerprints, autonomous system number.
• Identity and account logs: signup events, password resets, address changes, and the IPs behind them.

If these live in separate systems, export a window (two to twenty four hours) into one table before you start. Card testing is short lived, so a narrow window with full fields beats a long window with partial fields.

Log Analysis for Card Testing Detection: A Practical Guide

Signals that matter in the log data

• Card diversity per identifier. Count distinct BINs and distinct last-four values per IP, per session, and per device.
• Decline concentration. A run of issuer declines, do-not-honor, or invalid card responses against one identifier.
• Attempt velocity. Intervals between attempts measured in seconds rather than minutes, with little variance.
• Ticket shape. Many attempts at a small fixed amount, often followed by one larger attempt.
• Endpoint abuse. Repeated hits on checkout, payment, card-on-file update, or account creation rather than browsing pages.
• Identity churn. New accounts, guest checkouts, and disposable email domains clustered on the same address range.
• Uniformity. Identical user agents, headers, or field ordering across sessions that claim to be different users.

Starting threshold bands for triage

Treat these as triage starting points and tune them against your own traffic mix. A high-volume merchant and a niche store will not share the same baselines.

more on this topic

• Distinct card numbers per IP in one hour: watch above 5, investigate above 10.
• Distinct card numbers per device fingerprint in one day: watch above 3, investigate above 8.
• Authorization attempts per session: watch above 3, investigate above 6.
• Decline rate for a single identifier in ten minutes: watch above 40 percent, investigate above 70 percent.
• Median gap between attempts from one identifier: watch under 15 seconds, investigate under 5 seconds.
• Approval rate on new accounts: watch below 20 percent, investigate below 5 percent.
• Mean first-attempt ticket size: watch under 5 dollars, investigate under 1 dollar when paired with high velocity.

One threshold alone produces noise. Score identifiers on several at once and sort the list. Clusters, not single rows, are what you act on.

card testing log patterns

A workable analysis workflow

1. Pick a window and a fixed set of fields. Record the field list so the next run matches.
2. Aggregate attempts by source address, device fingerprint, session, and account.
3. Compute distinct card count, attempt count, decline rate, and median interval for each group.
4. Rank the groups by a weighted score across those metrics.
5. Manually review the top groups, reading timestamps in order to confirm the burst shape.
6. Cross-check the same identifiers against account creation, password reset, and shipping address logs.
7. Convert findings into rules: block or challenge the ranges, devices, and sessions, then watch whether the pattern shifts to new infrastructure.

Confirmation and correlation

A confirmed card testing run usually appears in more than one place. The same address range that produced thirty declines often produced ten new accounts an hour earlier. The same device fingerprint may show up on a password reset and a card-on-file update. When two or more independent sources agree on the same identifier, your false positive rate drops sharply. Record the confirmation in your case notes along with the query you ran, because networks that test cards rotate infrastructure and you will want to replay the query later.

Pitfalls that break the analysis

• Comparing timestamps from systems in different time zones or clock offsets without normalizing them first.
• Reading only gateway logs and missing the account and session context that ties attempts together.
• Treating a legitimate retry storm (issuer outage, checkout bug) as an attack. Check whether declines cluster by issuer rather than by source address.
• Sampling logs at ingest. Rare events are exactly what sampling removes.
• Storing full card numbers in application logs. Keep BIN, last four, and a token, and follow your data retention policy.
• Rendering user-controlled fields such as user agent into a log viewer without escaping, which invites log injection and corrupts the record.
• Running the analysis once. Card testing recurs, so schedule it and compare against last week's baselines.

FAQ

How long should I keep the logs I need?

Long enough to cover your dispute and chargeback windows plus a margin for pattern comparison. Many teams keep security-relevant logs for at least a year, with raw request logs for a shorter period. Check the retention requirements that apply to your environment.

Can I detect card testing without storing full card numbers?

Yes. Distinct BIN plus last four is enough to count card diversity. The analysis cares about how many different cards an identifier touched, not the card values.

Is card testing the same as credential stuffing?

No. Credential stuffing reuses stolen username and password pairs to take over accounts. Card testing validates stolen card numbers, often on guest checkout with no account at all. The two can appear in the same campaign, which is why you correlate account logs with payment logs.

What is the fastest field to add if my logs are thin?

A stable session ID that appears in both the web log and the payment log. Without a join key, you end up matching on timestamps, which is slow and error prone.

What do I do after I confirm a run?

Block or challenge the identifiers, add the pattern to your ruleset, notify your payment processor if the volume is large, and re check the same identifiers for follow-up activity in the next few days.