Card testing attacks against small merchants

Card testing is a fraudster validating stolen card numbers by running small transactions to see which ones approve. The merchant is not the target — the cards are — but the merchant absorbs the consequences: a flood of declines, fees on attempts, chargebacks on the successes, and a chargeback ratio that can put an account into a monitoring program.

It is an online-first attack, which is why stores that have just added an ordering page are the ones most often surprised by it.

What does it look like on your account?

A burst of small transactions in a short window, mostly declined, often repeating amounts, frequently overnight. Approvals scattered among them. Card numbers that share a pattern. And no corresponding orders that make any sense.

The tell is the ratio and the rhythm. Real customers do not arrive at three in the morning in groups of two hundred with an eighty percent decline rate.

Why does a small store get targeted?

Because small sites have weaker controls, not because they are valuable. An attacker looking for a place to test numbers wants a checkout that accepts attempts quickly and does not rate-limit. A new online ordering page built for a corner store is an ideal candidate precisely because nobody expected it to need defending.

Physical counters are largely immune, since testing requires automation. The exposure arrives with the website.

That is worth saying to anyone building you an ordering page. A checkout is not just a sales channel; it is a publicly reachable endpoint that accepts card attempts, and it needs to be built with that in mind rather than treated as a form.

What stops it?

Rate limiting and friction, in that order. Limiting how many attempts can come from one source in a period breaks the economics of the attack, because testing depends on volume. Adding a challenge on the payment step stops automated scripts outright.

Beyond that: blocking after a set number of consecutive declines, requiring the card security code, and using whatever fraud screening your gateway provides. Most gateways have these controls available and switched off by default.

What should you do while it is happening?

Turn off the checkout if you have to. An hour of no online orders is cheaper than a thousand attempts, and the decision is easier if you have made it in advance rather than at two in the morning.

Then call your processor. They see this pattern constantly, they can advise on controls specific to your gateway, and they would much rather hear from you than find it themselves. An account that reports an attack looks very different from one that appears to be generating fraud.

What does it cost if you ignore it?

Per-attempt fees on every transaction including declines, chargebacks on the ones that succeeded, and a chargeback ratio that can trigger monitoring. In the worst case a processor terminates the relationship, which is the expensive outcome.

That progression is why speed matters more than elegance. Stopping the attack badly at hour one beats stopping it properly at hour twelve.

What should you check before it happens?

Four settings on your gateway: is the security code required, is there a limit on attempts per source, is there a block after consecutive failures, and is any fraud screening active. Most small merchants can answer none of those, which is the answer.

The Federal Trade Commission's data security guidance for businesses is a reasonable general starting point, and your gateway's own documentation covers the specific switches.