What do card testing bots look like in a store's traffic logs?
Card testing bots probe your checkout with stolen card numbers, hunting for the ones that still work. In traffic logs they show up as rapid small-amount authorization attempts from rotating IPs.
The quietest expensive attack
Card testing is one of the least visible and most costly bot attacks a store can face. Criminals buy lists of stolen card numbers and probe them against real checkouts, hunting for the cards that still work. Your store is not the target. It is the testing ground. But the damage lands on you anyway: gateway fees on every attempt, chargebacks on the ones that succeed, and a payment processor relationship that deteriorates with every wave.
In traffic logs, card testing has a distinctive signature. Learning to read it is the difference between catching an attack in hours and discovering it in next month's processor statement.
The log signature
A card testing attack looks like this in the logs: a burst of POST requests to the payment or checkout endpoint, each with a different card number, often a different name and address, from a rotating set of IPs. The sessions are short. There is no browsing, no product page views, no cart building in the normal sense. The bot arrives at the payment step directly or with a minimal cart, submits, and moves on.
The tell is the combination of high payment-endpoint velocity with near-zero browsing behavior. Legitimate shoppers browse before they pay. Card testers pay without browsing, dozens or hundreds of times in a row.
Small amounts, big volume
Card testers favor small authorization amounts, often a dollar or two, sometimes the store's minimum. Small amounts are less likely to trigger the cardholder's fraud alerts and less likely to draw the store's attention. A wave of $1.00 authorizations is the classic pattern, though some operations test with the actual amounts they intend to steal later.
In the logs, filter payment attempts by amount and look for clusters: many distinct cards, identical small amounts, compressed into a short window. A handful of small authorizations is normal. Hundreds in an hour from rotating IPs is not. The amount pattern is often the first thing that looks wrong, before the velocity registers.
Velocity and rotation
Card testing infrastructure is built to evade simple rate limits. The requests come from large pools of rotating IPs, often residential proxies that look legitimate individually. No single IP exceeds an obvious threshold. The attack is visible only in aggregate: the payment endpoint's total request rate spikes, the ratio of distinct cards to distinct IPs climbs, and the geographic spread of IPs makes no sense for your customer base.
This is why per-IP rate limiting alone does not stop card testing. The defense has to operate on aggregates: velocity rules on the payment endpoint as a whole, distinct-card-count rules per time window, and device fingerprinting that sees through IP rotation. If your bot defenses only look at individual IPs, card testers walk through them.
Why it costs more than the fraud
The stolen-card purchases that succeed are only part of the bill. Every authorization attempt, successful or not, can incur a gateway fee. A sustained attack burns thousands of dollars in fees alone. Then come the chargebacks on the successful transactions, each carrying its own fee and pushing the store's chargeback ratio toward the thresholds where processors raise rates or terminate accounts.
There is also the customer impact. Card testing waves can slow the checkout for real shoppers or trigger the store's own fraud rules into false positives, declining legitimate orders. An attack you do not detect quickly taxes every part of the payment operation.
Detection signals to watch
Build monitoring around the attack's invariant features. Alert on spikes in payment-endpoint request rates relative to baseline. Alert on high ratios of distinct card numbers to completed orders. Alert on authorization amounts clustering at the minimum. Alert on the same device fingerprint cycling through many cards.
AVS and CVV response codes are an underused signal. A surge in CVV mismatches or AVS failures across many cards is card testing until proven otherwise. Most stores log these codes and never alert on them. A simple dashboard of failure-code rates by hour would catch most attacks while they are still small.
Responding to an active attack
When the signals fire, the response has tiers. First, tighten velocity controls on the payment endpoint immediately: stricter rate limits, challenge pages for suspicious sessions. Second, require CVV and full AVS matching if you are not already, and consider a CAPTCHA on the payment step during the attack window. Third, engage your payment processor: they have seen this pattern across thousands of merchants and can apply network-level blocks.
After the wave, do the cleanup. Review the successful authorizations for fraud and refund the suspicious ones before they become chargebacks. Audit what the attack cost in fees. And close the gap it exploited: whatever let the testers through at scale, per-IP-only limiting, missing CAPTCHA, lenient AVS rules, gets fixed before the next wave, because there will be a next wave.