Card testing looks like a flood of small charges: a few cents here, a dollar there, dozens in a minute. Someone has a list of stolen card numbers and is using your checkout to find out which ones still work. To stop it, make every guess cost the attacker something. Velocity limits, CVV and address checks that actually decline the transaction, a bot challenge before the payment form submits, and a rule that flags any card trying multiple numbers in a short window. Those four controls kill most of it.

strategies to stop card testing

Why your store gets picked

Testers do not care about your products. They care that your gateway answers approved or declined. A store with no CVV requirement, no velocity rule, and a checkout that accepts a new card in under five seconds is an easy target. Attackers also favor merchants that never push back, because a declined test costs them nothing and a working card number sells on a carding forum within hours.

strategies to stop card testing

The damage lands later. You pay interchange on transactions that will be charged back, you eat the dispute fee, and your ratio climbs toward a monitoring program. Some processors close an account before the ratio ever gets that far.

more on this topic

Velocity rules that catch real testers

Generic rules like "more than five orders per hour" catch almost nothing, because testers rotate IPs and emails. Count on the dimensions that are hard to fake at scale:

read more

• Distinct cards per device fingerprint in a rolling 24 hours
• Distinct BINs per IP in a 10 minute window
• Failed authorizations per email address or account
• One card number attempted from more than one IP
• Small order value from a new customer on a new device

Start with the card-per-device and BIN-per-IP counters. Block or challenge when either trips, and log the decision so you can tune the thresholds later.

Put a challenge in front of the payment step

CAPTCHA on the checkout page helps. CAPTCHA on the submit button helps more, because that is the request the tester needs. If you run a headless flow or an API, require a token from your bot vendor and reject submissions without a valid one. Replay protection matters too: a token used twice is a bot, not a shopper.

Make failed authorizations expensive

Require CVV. Require AVS at least on the postal code. Then, the part people skip, make a mismatch a hard decline instead of a soft one you retry. Retrying a bad CVV is a gift to a tester, since each retry is another free validation attempt. Cap retries per card per hour, and count declines toward your velocity limits rather than ignoring them.

If you sell digital goods or anything instant, add 3-D Secure. The step-up prompt adds friction for honest buyers, but it shifts liability and shuts down a large share of test traffic, because the attacker rarely has the one-time code.

Watch the data you already have

Your gateway and your own logs hold the pattern. Look for authorization spikes outside your normal hours, a single customer ID with twenty declines, or a burst of orders with sequential or machine-generated email addresses. Alerts on those three queries catch most campaigns within minutes instead of at settlement.

Issuer and network tools worth asking about

Your processor can turn on network-level controls that flag account enumeration and BIN attacks before they reach you. Ask for card testing and enumeration controls by name, not just "fraud tools." Some acquirers also share a blocklist of IPs and devices seen across their merchant base. It is free signal, so take it.

Checklist to ship this week

1. Enable CVV and AVS with hard declines and no automatic retry on mismatch
2. Add card-per-device and BIN-per-IP counters with a 10 minute window
3. Require a bot token on the payment submission
4. Alert on decline bursts and out-of-hours authorization spikes
5. Ask your processor to enable enumeration and BIN attack controls
6. Review blocked orders and refunds weekly until volume settles

How to know it worked

Authorization attempts drop, declines drop with them, and your chargeback ratio follows a few weeks later. Pull a baseline before you change anything so you have something to compare against. If volume stays flat, the attacker has moved to a path your rules do not cover, often a different endpoint or a stored card on file. That is the next thing to look at.