Card testing attack prevention starts with one idea
A card testing attack is a flood of small authorization attempts run through your checkout to find stolen card numbers that still work. The attacker does not care about your product. They care about a yes or no answer from the payment processor. Prevention comes down to making that answer slow, expensive, and hard to get at scale.
card testing attack prevention software
Why your store gets picked
Testers look for checkouts that answer fast, accept tiny orders, and do not require much verification. A $1 donation page or a gift card with instant delivery is close to ideal for them. If your decline rate stays low while your authorization volume climbs, you are a good target and they will come back.
I have watched this pattern repeat on small merchants. The attack usually hits between 1 a.m. and 5 a.m. local time, when nobody is watching the dashboard.
Warning signs worth watching
- A spike in authorization attempts that never turn into orders.
- Many cards tried from one IP, device, or email domain in a short window.
- Decline rates jumping from a normal 5 to 10 percent to 40 percent and up.
- Orders clustered at a low price point, often the smallest amount your store allows.
- Billing addresses that pass with mismatched names, or a run of AVS failures.
- Cardholder complaints about charges they did not make.
Any one sign can be noise. Two or three together usually means someone is testing you.
Prevention controls that work
Rate limits and velocity rules
Set hard caps on attempts per IP, per device fingerprint, per email, and per card BIN inside a rolling window. Ten attempts per hour per IP is a reasonable starting point for most stores. Block the whole session, not just the single request, or the attacker rotates the card number and keeps going.
Bot and device signals
Headless browsers and scripted requests leave traces: no mouse movement, instant form fills, identical user agents across many IPs, and datacenter IP ranges. A bot management layer that scores those signals filters most automated traffic before it reaches your payment page.
Verification at the door
Require CVV and full address verification on every order, and turn on 3D Secure for high-risk regions or first-time buyers. 3DS shifts liability and kills most card testing outright because the attacker rarely holds the second factor. It adds friction, so apply it to the risky slice rather than every customer.
Authorization strategy
Ask your processor about a small-amount block, or a rule that voids authorizations under a set threshold instead of capturing them. Some processors let you auto-void any authorization under a dollar. That single rule removes the economic reason a tester picks your store.
What to do when you get hit
- Block the offending IPs, ASNs, and device fingerprints at the edge, not in your application code.
- Add a CAPTCHA or challenge step to the checkout path for a few days.
- Raise your minimum order value for new customers.
- Call your processor and ask about fee relief for the declined authorizations. Card testing costs real money even when nothing ships.
- Document the timeline, volume, and controls you added. You may need it for a dispute or a chargeback ratio review.
Measuring whether it worked
Track authorization attempts per hour, decline rate, and the ratio of attempts to completed orders. A healthy ratio stays near your baseline. If attempts drop but conversion drops with them, your controls are too broad and you are turning away real buyers.