Card Testing Log Analysis Example: Detect Carding in Payment Logs

The strongest card testing log analysis example starts with one joined view: payment gateway authorization records joined to edge request logs on IP, timestamp, and a session or device identifier. That pairing beats gateway-only analysis because the gateway records the card outcome while the edge records the request shape, and card testing leaves evidence in both. Four criteria decide whether the view is worth building: whether the join key survives across systems, how granular your issuer response codes are, how much clean baseline traffic you have for comparison, and how long you retain raw events.

The log fields you need on hand

A useful analysis needs fields from two sides. From the authorization log: event timestamp, merchant or account ID, amount, currency, card BIN, tokenized card reference, issuer response code, authorization ID, and the submitted billing region. From the edge or application log: request timestamp, source IP, autonomous system number, user agent string, request path, and device or browser fingerprint when one exists.

A representative authorization line, read field by field: timestamp 2024-03-11T02:14:07Z, merchant 8841, amount 0.00, currency USD, BIN 414709, token tkn_9f2c, response 05, auth id 773120, ip 198.51.100.44, asn 64500, user agent python-requests/2.31, device fingerprint empty. One line says little. Four hundred lines like it in thirty minutes says a great deal.

Signal one: authorization velocity and decline clustering

Count authorization attempts per merchant, per BIN, and per source IP in rolling one, five, and fifteen minute windows. Card testing produces short bursts that sit far above the merchant's own baseline, and the burst is usually dominated by declines rather than approvals.

• Pros: cheap to compute, works with limited history, and catches the blunt-volume end of the attack.
• Cons: noisy for merchants with genuinely spiky demand, and useless against slow, low-rate testing spread across many accounts.

Signal two: card spread per source

Measure distinct card tokens per source IP or device in a window, then compare that ratio to your baseline. A normal shopper reuses one or two cards. A testing script sends many distinct tokens through one source, or one token through many sources, depending on how the operator splits the work.

• Pros: separates real buyers from enumerators even when request volume looks moderate.
• Cons: shared corporate NAT and carrier-grade NAT inflate the ratio and produce false positives, so pair this with ASN context.

Signal three: amount and response code fingerprinting

Group attempts by amount plus response code. Testing traffic tends to use small or minimum amounts and concentrates on a narrow band of issuer codes such as do-not-honor, invalid card number, and CVV mismatch. A merchant whose normal mix includes a healthy share of approvals will look nothing like a block of attempts where nearly every response is a decline.

Signal four: joining gateway and edge logs

Join on source IP with a tolerance window of a few seconds, because gateway timestamps and edge timestamps rarely align exactly. Once joined, look for authentication mismatches: requests that never loaded a product page, missing device fingerprints, and user agents that identify scripting libraries rather than browsers.

• Pros: exposes the request-level behavior that gateway logs alone hide, and gives responders something actionable to block.
• Cons: requires consistent clock sync, shared identifiers, and retention windows that overlap across both systems.

Run the analysis in this order

1. Establish a two-week baseline of attempts per merchant, per BIN, and per source.
2. Flag windows where attempt counts exceed the baseline by a wide margin.
3. Layer in decline rate, distinct card tokens per source, and amount distribution.
4. Join to edge logs and score for scripting user agents, empty fingerprints, and ASN concentration.
5. Review the top clusters by hand before you write rules, then re-run against last month's data to check the false positive rate.

When to use which approach

Gateway-only analysis

Best for small merchants or teams without edge log retention. It catches volume spikes and decline clustering within a day of setup, and it does not depend on joining infrastructure. Accept that it will miss low-rate distributed testing.

Joined gateway and edge analysis

Best for merchants with meaningful authorization volume, an existing logging pipeline, and personnel who can tune rules. It produces fewer false positives and gives you blockable identifiers, at the cost of clock sync work and longer retention.

Manual review of a single incident

Best when you already know an account was abused and need to scope it. Pull every authorization in the window, sort by source, and map which card tokens touched which sources. That map is usually the clearest artifact you can hand to a payment processor or an acquirer.

Pitfalls that waste the effort

Retention is the first one. If raw events roll off after a week, you cannot compare current traffic to a seasonal baseline. Clock drift is the second; unsynchronized hosts make the join unreliable. The third is treating every decline burst as an attack, when a payment processor outage or a broken checkout release produces the same shape. Confirm the cause before you act on the numbers.