Card Testing Attacks: Small Charges With a Big Signal

What card testers are actually buying

A card testing attack is not really about your products. The attacker has a list of stolen card numbers, often bought in bulk, and needs to know which ones still work before selling them on or using them for larger fraud. Your checkout becomes the testing instrument: each small authorization attempt answers the question, live or dead, for a few cents of effort.

For more on this, see this related guide and our earlier explainer on the same theme.

That is why the orders look so strange. The basket is whatever is cheapest, the details are throwaway, and the attacker does not care whether anything ships. Sites with low priced digital goods, donations, or gift cards get hit hardest because they allow fast, cheap, repeatable tests, but any checkout that returns clear approve and decline responses can be used.

The pattern in your payment data

One test looks like a declined card, which happens to honest shoppers every day. A testing run looks like a statistical impossibility: dozens or hundreds of authorization attempts in a short window, a decline rate several times your normal level, repeated small amounts, and cards sharing BIN ranges or originating from a narrow set of IP addresses and devices.

Timing is a giveaway too. Testing is automated, so it runs at machine speed and often at hours when your real traffic is asleep. Pull a simple report of authorization attempts per hour with decline rates before you need it. The first time you see the spike in that report should not be the day your processor calls you about it.

Defenses that stop testing without punishing shoppers

Start with velocity limits at the checkout and payment steps: cap authorization attempts per IP, per device, and per session in a rolling window, and slow responses down as attempts pile up. Testing economics depend on speed and volume, so even modest friction breaks the model while a normal shopper, who tries a card once or twice, never notices the limit exists.

Readers also found this companion piece from our archive useful.

Layer in bot controls where the attempts begin, and consider requiring account creation or a minimum basket for the products testers abuse most. Talk to your payment processor about their card testing tools as well; most gateways can flag or block testing patterns at the network level, before the attempts turn into decline fees on your bill.

What to do during an active attack

Tighten first and investigate second. Drop the velocity thresholds, block the offending IP ranges and BINs temporarily, and switch the most abused products or payment paths to stronger verification while the burst is live. Every hour of testing adds decline fees and can push your decline ratios into territory that draws processor scrutiny and fines.

Afterward, review what the attack learned. Cards that were approved during testing may be used elsewhere quickly, and any that completed orders on your site deserve a fraud review before fulfillment. Save the logs: timestamps, IPs, and BIN patterns are exactly what your processor and other merchants need to connect your attack to the wider campaign.

Frequently asked questions

Why do card testers pick small stores instead of big ones?

Small stores often have weaker velocity controls, no dedicated fraud review, and slower responses, so a testing run can finish before anyone notices. Attackers also rotate through many small checkouts to stay under the thresholds of any single large platform. Size is not protection; controls are.

Will adding a CAPTCHA stop card testing?

It raises the cost but does not end the threat. Modern testing uses headless browsers and solving services that handle common challenges. CAPTCHA works best as one layer alongside velocity limits and gateway level detection, not as the whole defense.

What does a card testing attack cost the merchant?

Declined authorization attempts often carry per attempt fees, and a large run can generate thousands of them in a night. Worse, sustained high decline rates can trigger processor monitoring, fines, and in serious cases threats to the merchant account itself. The fees are the small part of the bill.

How do I tell card testing from a busy sale day?

Real demand converts. A sale day shows more approvals, normal basket sizes, and traffic that matches your marketing. Testing shows a collapsing approval rate, minimum value baskets, repeated attempts from narrow sources, and order details nobody would ship to. The approval rate is the fastest discriminator.