The short answer
Card testing fraud is what happens when someone pushes a batch of stolen or generated card numbers through your checkout to find out which ones are still live. The attacker does not want your product. They want a yes or no from the payment processor. Approvals get resold or used later for bigger purchases. Declines get thrown away. Your store is just the testing bench.
The tell is almost always the pattern, not any single order. One $2 charge looks harmless. Four hundred of them in twenty minutes, from forty countries, on accounts created that same hour, does not.
Why the orders are small
A tester wants to spend as little as possible per check. So they hunt for the cheapest thing you sell, or a donation field, or a gift card with a custom amount. Some will try to authorize a dollar and abandon the cart. If your checkout allows a zero-value or near-zero transaction, that becomes the favorite door.
There is a second reason for small tickets. Issuers often approve low-value transactions without friction, while a $600 charge triggers a step-up challenge or a fraud review. Testers know this. The low value is the point.
What the traffic looks like from the merchant side
I look for a few things that show up together more often than they show up alone:
- A spike in declines, especially the same decline reason repeating across many cards.
- Many orders with different card numbers but the same device fingerprint, IP range, or shipping address.
- Email addresses on throwaway domains, or addresses that look like keyboard mashing.
- Billing country and IP country that do not match, at a rate far above your normal mix.
- New accounts with no browsing history that go straight to checkout.
- A cluster of orders in a very narrow time window, often overnight in your timezone.
None of these alone proves anything. A single mismatched country is normal. Fifty in a row is a test run.
What actually reduces it
No single control stops card testing. You stack them so the cost of testing on your site goes up.
Friction at the door
Rate limit by IP, by card BIN, by email, and by device. Set a ceiling on failed authorization attempts per hour and hold the rest. Add a challenge on checkout that costs almost nothing for a human and a lot for a script. Require a minimum order value if your catalog lets you.
Use the tools the networks already give you
Address verification and CVV checks are not optional. Turn on the card networks' fraud scoring and respond to it. For higher-risk regions or first-time buyers, 3-D Secure moves the liability and adds a step a script usually cannot complete.
Watch the ratio, not the total
Decline rate per hour, authorization attempts per card, and the share of orders from new accounts are the three numbers I would put on a dashboard. Card testing shows up as an ugly spike in all three before it shows up as chargebacks.
If it is already happening
Block the obvious cluster first: the IP range, the device IDs, the email domain. Then tighten the velocity rules globally for a day or two, not just for the attackers. Pull the approved orders in the window and refund the ones you can identify, because a tested card that gets charged will come back as a chargeback with fees attached. Document what you saw. If volume is significant, tell your acquirer before they tell you, and file a report with the relevant authorities.
The part people underestimate
Card testing is cheap to run and expensive to clean up. The chargebacks arrive weeks later, and by then the attackers have moved to the next store. The merchants who get hit hardest are usually the ones who only looked at fraud after the money was gone. Watching attempts, not just settlements, is the difference.