A burst of tiny online orders may look harmless. In reality, it can be card testing, a fraud tactic in which criminals try stolen card numbers to learn which ones still work. Small businesses are attractive targets because an unprotected checkout form can be easier to exploit than a large retailer’s heavily monitored website.
Why it matters
Card testers often use automated scripts to submit many transactions in seconds. Amounts may be less than a dollar, donations may repeat, or attempts may come from different names and addresses while sharing similar technical details. Most cards decline, but every approved payment confirms useful information for the criminal.
Where problems begin
The merchant absorbs the mess. Even declined attempts can create gateway costs, while successful tests can lead to refunds, chargebacks, higher dispute ratios, and processor scrutiny. A sudden wave may also slow the website and bury legitimate orders in noisy transaction data.
What merchants can do
Good protection uses layers. Add CAPTCHA or another bot challenge when behavior looks abnormal. Apply velocity limits to repeated attempts from the same device, IP address, card, or email. Use AVS and card-security-code checks thoughtfully, and block clearly suspicious traffic without making every customer solve an obstacle. Tokenization and a hosted payment form can reduce the amount of card data touching the merchant’s systems.
A practical next step
Watch reports for spikes in declines, repeated low-dollar amounts, strange timestamps, and rapid attempts across many cards. If testing starts, contact the gateway or processor quickly, preserve logs, tighten rules, and consider temporarily disabling the affected form. The goal is not to reject every unusual customer. It is to make automated abuse expensive and obvious before it becomes a costly dispute problem.
Checkout design matters too. Forms that allow unlimited attempts, reveal overly specific decline messages, or lack basic rate limits give attackers room to experiment. Work with the website developer and gateway provider together; each may see only part of the traffic. After the incident, review which control actually stopped it.
Stay prepared. Review it regularly. Keep the process documented. Train staff before problems appear. Clear records make follow-up much easier. Check the agreement because provider rules and timelines vary.
