What card testing fraud is
Card testing fraud is what happens when someone pushes a batch of stolen card numbers through a payment form to learn which ones still work. The attacker does not want your product. They want a clean list of live cards, and your checkout is just the testing bench.
That distinction matters. A card testing attack rarely looks like a normal fraud case because the individual orders are tiny and the buyers never complain. The damage lands somewhere else: authorization fees on every attempt, a spike in chargebacks weeks later, and a fraud ratio that puts your processing account at risk.
Why attackers bother testing cards
Card numbers go stale. People cancel cards, banks reissue them, and leaked databases age fast. A number that has not been checked recently has unknown value. Once it clears a small transaction, it can be sold or used for a bigger purchase, and the price it fetches goes up.
So the attacker runs the cheapest possible transaction, often a dollar or less, across hundreds or thousands of numbers. If your store sells digital goods or accepts guest checkout, the whole cycle can finish in minutes.
Signals that show up in your order data
I look for clusters, not single orders. One odd charge is noise. Twenty of them in ten minutes is a test run.
- A sudden spike in low-ticket orders, especially amounts under a few dollars.
- Many attempts from one IP range, one device fingerprint, or one session, each with a different card number.
- Distinct card numbers funneling to the same shipping address, email pattern, or phone number.
- A wall of declines followed by a short burst of approvals on the same endpoint.
- Email addresses that look generated, or sequences like name1, name2, name3.
- Billing addresses that do not match anything you ship to, with card BINs from regions you do not serve.
- Repeated card update attempts on dormant accounts.
Your authorization rate is a useful gauge here. A jump in declines with a matching jump in attempts usually means someone is guessing, not that your gateway broke.
How to reduce your exposure
No single control stops this. Layers do.
- Require CVV and run address verification on every card-not-present transaction. Some legitimate sales drop off, so test the tradeoff.
- Apply velocity limits per IP, per device, per card, and per email, not just per account.
- Rate limit the payment endpoint itself. Attackers script directly against it and skip your forms.
- Enable 3-D Secure or EMV 3DS where your processor supports it. It shifts liability and adds a step that scripted attacks handle badly.
- Put a challenge on checkout, account creation, and card-on-file updates.
- Keep decline messages generic. Telling the client why a card failed hands the attacker a free validator.
- Block or step up transactions from high-risk BINs and geographies you do not sell to.
- Alert on volume thresholds during your slowest hours. Testing tends to run when your team is offline.
What to do after you catch an attack
Void or refund what you can before settlement, then contact your processor and tell them what happened. Ask about fraud alerts on the account so the activity is documented. Review the decline and approval logs to find the window, block the identifiers you can trust, and check whether the same pattern appears on other payment endpoints you own.
Then watch chargebacks for the next 60 to 90 days. Tested cards often get used again elsewhere, and some of those transactions will come back to you. Handling it early is cheaper than explaining a fraud spike to your acquirer later.