The short answer

Card testing is when someone runs stolen card numbers through your checkout to learn which ones still authorize. Your store is the lab, not the target. Prevention comes down to three layers: verify the card at the moment of sale, throttle how fast anyone can submit payment attempts, and watch for the pattern instead of judging orders one at a time. Turn on verification first. Add velocity limits second. Then clean up whatever slipped through.

how to prevent card testing

Why your store gets picked

Attackers scan thousands of sites looking for weak checkout rules. A store with a cheap digital item, guest checkout, no CAPTCHA, and CVV checks set to warn instead of decline is an easy mark. They are not shopping. They need one thing from you: a yes or a no from the processor.

Preventing Card Testing on Payment Forms: A Practical Guide

The tells are usually structural. Guest checkout plus a $1 product plus no bot protection is the combination that gets found first.

read more

Signs I check for

• A sudden spike in declined authorizations with a normal or barely changed order volume
• Many different card numbers hitting one IP address, device fingerprint, or email domain
• Orders clustered in the same BIN range, or card numbers that look sequential
• Tiny order values, often digital goods, sent to a handful of addresses under different names
• Traffic jumping straight to checkout with almost no product page views
• Billing and shipping details that never match, with disposable email domains

Rules that cut the volume

None of these is a complete answer on its own. Stacked, they raise the cost of the attack past what most carding crews will pay.

How to Reduce Card Testing Attacks: A Comprehensive Guide

• Require CVV and AVS, and decline on mismatch rather than flagging it for review
• Turn on 3D Secure. It shifts liability in many cases and adds friction bots handle badly
• Set velocity limits per IP, per email, and per card fingerprint. Five card numbers from one IP in a day is not a customer
• Block after a set number of failed attempts, not just after a completed sale
• Put CAPTCHA or bot detection on checkout and account creation, not only on login
• Restrict guest checkout for high-risk SKUs or require an account with a verified email
• Screen against disposable email lists and known proxy and VPN ranges, carefully, since real customers use those too
• Use zero-dollar or small authorizations only where your processor supports the workflow cleanly

Processor-side tools

Stripe Radar, Adyen risk rules, Braintree, Kount, and Sift all ship fraud scoring and custom rule engines. Ask your acquirer for blocklists and BIN-level controls, because some attacks are best stopped before the authorization request ever reaches your stack. If you process on a smaller gateway, ask what velocity tools exist at the platform level. Many merchants never ask.

If you are under attack right now

1. Disable guest checkout and raise your velocity thresholds to something strict
2. Enable 3D Secure on all transactions if it is not already live
3. Call your processor risk team and ask for blocks on the attacking IPs and BIN ranges
4. Void or refund unauthorized authorizations before settlement, not after
5. Pull your logs and figure out what the attacker managed to extract

What not to do

Do not refund everything and hope it stops. Do not lean on one rule and call it done. Do not store CVV data, ever. That is prohibited under PCI DSS no matter how convenient the checkout flow becomes.

The part nobody enjoys

Card testing evolves. Thresholds that worked at a thousand orders a month break at ten thousand. I review approval rate, dispute rate, average order value, and top decline reasons on a weekly cadence, and I adjust rules when the mix shifts. Boring, but that is the job.