Log analysis for card testing detection means reading payment gateway, web server, and application logs to find many low-value authorization attempts from a small set of sources. A card testing attack tries stolen card numbers against a merchant's checkout, and the logs show the pattern before the fraud losses pile up. Detection depends on velocity, decline rates, and the number of distinct cards tied to one IP, session, or device.

Card Testing Logs vs Transaction Logs: A Comparison Review

What does card testing look like in logs?

Card testing leaves a trail of failed authorizations, not completed sales. The attacker sends a burst of requests, and most come back as declines, invalid card errors, or do-not-honor responses. The same script may cycle through hundreds of card numbers in minutes.

Card Testing Log Patterns: A Comprehensive Guide

• Many authorization attempts with small amounts, often $0 to $2.
• High decline rate from one IP address or a small IP range.
• Distinct card numbers that share a BIN or run in sequence.
• Repeated use of the same email, phone, or device fingerprint.
• Short session times and direct hits to the payment endpoint.
• User agents that do not match normal browser traffic.

Those signals can also come from a gift card checker or a subscription retry system. The difference is scale, timing, and the mix of card numbers. Card testing shows a wide set of cards from a narrow set of sources.

How to Analyze Logs for Card Testing: A Merchant Detection Guide

Which log sources matter most?

No single log tells the whole story. You need payment logs for authorization results, web logs for request patterns, and application logs for session context.

related article

• Payment gateway logs: auth attempts, response codes, amounts, card BIN, and timestamps.
• Web server access logs: IP, URL, method, status code, user agent, and request timing.
• WAF logs: blocked rules, bot scores, and rate-limit hits.
• Application logs: checkout session IDs, account IDs, cart values, and device data.
• Authentication logs: login failures and new account creation tied to the same source.

Keep at least 30 days of these logs in a searchable store. Card testing can run for days at a low rate to avoid rate limits.

Which signals separate card testing from normal traffic?

Look for a cluster of signals, not one. A single high decline rate can come from a broken payment integration or a bank outage.

1. Velocity per IP: more than 10 authorization attempts in 10 minutes from one address.
2. Card diversity: more than 5 distinct card numbers in one session.
3. Decline ratio: over 70% declines across at least 20 attempts.
4. Amount clustering: a tight range of small values, such as $1.00 and $1.01.
5. BIN concentration: many cards from one issuer or region.
6. Behavioral mismatch: no page views, no cart edits, and a direct POST to the payment endpoint.

Set thresholds from your own baseline. A high-volume merchant may see 10 attempts per IP in 10 minutes during a sale. A small store may never see that outside an attack.

How do you query logs for card testing?

Start with a time window and group by the source. The goal is to rank sources by suspicious activity, then pull the detail.

1. Filter logs to authorization and checkout endpoints for the last 24 hours.
2. Group by IP address and count attempts, declines, and distinct card fingerprints.
3. Sort by decline count and distinct card count to find the top sources.
4. Join web logs to payment logs on session ID or timestamp plus IP.
5. Compare the top sources to the last 7 days of normal traffic.
6. Export the full request list for each source for review.

Run this query every 5 to 15 minutes if your stack allows. Hourly batches can work for low-risk stores, but the attack may finish before you see it.

What detection rules should you write?

Rules turn log patterns into alerts. Keep them simple and test them against past data before you enable blocking.

• Alert when one IP hits the payment endpoint more than 20 times in 10 minutes.
• Alert when one session uses more than 10 distinct card numbers.
• Alert when the decline rate for an IP passes 80% with at least 15 attempts.
• Alert when a new account makes 5 payment attempts in 5 minutes.
• Alert when the same device fingerprint appears with more than 3 IP addresses in an hour.

Pair each alert with a response. An alert with no action creates noise and missed attacks.

What do you do after detection?

Contain the source first, then review the damage. Card testing often comes with account creation and credential stuffing, so check those logs too.

1. Block the source IP or IP range at the WAF or edge.
2. Rate-limit the payment endpoint for the affected session or account.
3. Add a CAPTCHA or challenge for suspicious sessions.
4. Notify your payment processor and provide the log extract.
5. Refund or void any successful charges tied to the attack.
6. Review new accounts and orders from the same time window.

Do not rely on IP blocking alone. Attackers rotate through proxies and residential networks. Combine blocks with device checks and payment rules.

Common mistakes in card testing log analysis

• Watching only successful charges and ignoring decline logs.
• Keeping logs for less than 24 hours, which hides slow attacks.
• Using one static threshold for all endpoints and times of day.
• Failing to join web logs to payment logs, which hides the source.
• Treating every high decline rate as fraud without checking gateway health.

Each of these gaps gives an attacker more time. A small change to log retention or a join key can close most of them.

FAQ

How fast should you detect card testing?

As close to real time as your stack allows. A 5 to 15 minute batch is a common target. Some processors offer real-time fraud rules that can block the attack before your logs update.

Does card testing always use small amounts?

No. Many attacks use $0 or $1 authorizations to check if a card is live. Others test with the real order value. Amount alone is a weak signal.

Can log analysis alone stop card testing?

No. Log analysis finds the pattern. You still need rate limiting, CAPTCHA, 3D Secure, and processor rules to block it. Logs give you the evidence and the feedback loop.

Key takeaways

• Card testing shows up as many auth attempts, high declines, and many distinct cards from few sources.
• Payment logs, web logs, and application logs each hold part of the pattern.
• Build rules on velocity, card diversity, decline ratio, and session behavior.
• Respond with blocks, rate limits, challenges, and processor notice.
• Keep 30 days of logs and review thresholds against your own baseline.