Card Testing Log Analysis Example: Authorization Log Guide

The most useful card testing log analysis example to copy is a gateway authorization log joined to client IP, card BIN, and response latency. That one join exposes the three things that matter: a decline-rate spike, fan-out across many card numbers from one source, and a timing signature that ordinary checkout failures do not produce. I ranked it above edge request logs and dispute files on four criteria: signal per row, retention window, ability to join with network data, and the privacy cost of the fields required.

What card testing looks like in a raw log

Card testing is an enumeration attack. Someone holds a list of numbers and needs to learn which ones will authorize, so they push many small attempts through a checkout endpoint and read the response codes. In an authorization log the pattern appears as volume, not as one smoking-gun event.

• A burst of attempts inside a short window, with sub-second spacing between rows from the same source.
• Many distinct card tokens or BINs from one IP, ASN, or device fingerprint.
• Authorization amounts clustered at $0.00, $1.00, or another small merchant-defined value.
• Decline codes that skew toward invalid card number, do not honor, and insufficient funds rather than expired card or wrong CVV.
• Repeat attempts on the same token after a decline, which an ordinary shopper repeats at most once.

None of those lines is proof on its own. The worked example below combines them so the conclusion holds up in a fraud review.

The worked example, step by step

1. Export 24 hours of authorization events with timestamp, card token, BIN, amount, response code, gateway latency, and a hashed client identifier.
2. Bucket events by minute. Plot attempt count and decline rate on the same axis, then mark where decline rate crosses your baseline by a wide margin.
3. Rank sources by distinct card tokens per hour. One IP touching forty tokens in ten minutes is the core signal.
4. Break the response-code mix inside the spike window and compare it with the same hour one week earlier.
5. Join edge logs on the hashed IP to pull ASN, user agent, and TLS fingerprint for each ranked source.
6. Check approval rate inside the spike. A successful enumeration leaves a tail of approvals followed by chargebacks weeks later.

Log sources compared

Gateway authorization log with IP, token, and BIN

Pros

• Carries the response code, so you can tell a decline from a block.
• Includes amount, currency, and gateway latency in the same row.
• Joins to edge and device data on a hashed client identifier.

Cons

• Holds cardholder data, so storage and access fall under PCI DSS logging requirements.
• Retention windows are short on many processors, which limits retroactive review.
• Distributed attacks over residential proxies do not cluster on a single IP.

Edge or WAF request log

Pros

• No card data, so fewer compliance obligations.
• Exposes bot signatures, ASN, TLS fingerprint, and request rate per source.
• Retention is often longer than the processor side.

Cons

• No response codes, so approvals and declines are invisible.
• Checkout traffic mixes with catalog and asset traffic.
• You cannot count distinct card tokens from the request line alone.

Application checkout event log

Pros

• Session ID, cart contents, account ID, and device fingerprint sit together.
• Links repeated attempts to one account or one device.
• Useful when card testing is a step inside account takeover.

Cons

• Sampling and truncation hide the tail of a burst.
• Gateway responses are dropped by many instrumentation setups.
• Error naming is inconsistent across teams, which breaks grouping.

Chargeback and dispute file

Pros

• Confirms real loss instead of a suspected one.
• Carries issuer reason codes and the matching token.

Cons

• Arrives weeks after the attack, so it cannot drive live blocking.
• Covers only approved attempts, which is a thin slice of the activity.

Which source to start with

Small teams on a processor that keeps 90 days or more should start with the gateway authorization log joined to a hashed IP. Merchants with heavy bot traffic and short processor retention should start at the edge, confirm the automation, then pull the auth log for the same window. Marketplaces and subscription businesses should start with the checkout event log, because account linkage identifies the operator behind the tokens. Treat the dispute file as a validation set for your thresholds, never as the detector.

Baselines and false positives

Every threshold needs a comparison window. Compare against the same weekday and hour, then subtract known internal ranges such as load tests, health checks, and your own retry loop.

• Holiday and payday spikes raise attempt volume across all sources.
• Issuer outages push decline rates up for a whole BIN range at once.
• One customer with many stored cards can look like fan-out.
• Corporate NAT shared by hundreds of people inflates tokens per IP.
• Balance checks on gift cards produce small amounts and odd codes.

Threshold on distinct tokens per source per hour, not on raw attempt count. The token count separates enumeration from a busy day.

Metrics for the weekly review

• Distinct tokens per source per hour, top 20 sources.
• Decline rate by BIN range and by issuing bank.
• Approval rate inside every spike window.
• Share of attempts with an amount below $2.
• Chargeback rate on tokens first approved during a spike.
• Mean gateway latency during bursts, which rises when a script hammers one endpoint.

Run the six steps once on last week's export and you have a reusable query, a baseline, and a written example your fraud team can review line by line.