Card Testing: How Merchants Detect and Stop It

If you accept payments online, the useful advice is this: treat card testing as an attack pattern to detect and block, not as a technique to learn. Card testing is the practice of pushing batches of card numbers through a checkout form to find out which ones still authorize. The goal is to sort live numbers from dead ones, and the cost lands on your processing fees, your dispute ratio, and eventually your ability to accept cards. Nothing below explains how to run those attempts. It explains how to spot them and stop them.

What card testing looks like in your data

The pattern is usually loud once you know where to look. Attackers favor the cheapest possible order because they only need an authorization, not a fulfilled shipment. That means a burst of low-value attempts, often under a dollar, hitting the same endpoint from a small pool of IP addresses, devices, or email addresses. Many attempts fail. The ones that succeed may never convert into a real order, or they convert into a digital good that ships instantly and cannot be recalled.

Volume matters more than any single transaction. One odd small charge is noise. Forty small charges in twenty minutes from the same subnet is a signal your fraud tooling should have already caught.

Signals worth monitoring

• Authorization attempt count per IP, per device fingerprint, and per email address over short windows.
• Decline rate tied to a single card range or issuer identification number.
• Order value distribution, especially a sudden shift toward the lowest possible basket.
• Address verification and card verification value mismatch rates compared with your own baseline.
• Number of distinct card numbers used per session or per customer account.
• Time-of-day clustering that does not match your normal buying pattern.

Pull these into one dashboard. Fraud teams miss card testing most often because the signals live in separate systems that nobody compares.

Starting threshold bands

Your baseline is the only baseline that counts, so treat these as starting points and tighten them with your own data. Attempts per IP per hour: review above five to ten, block above twenty. Decline rate on one issuer range: investigate past roughly forty percent once you have more than twenty attempts. Card numbers per device per day: more than three to five is unusual for retail. Mismatch rate per session: a jump above your normal five to fifteen percent range deserves a manual look.

Set the rules to alert first, then enforce. Blocking on day one will cut real orders along with the attack.

Pitfalls

• Relying on a single control. IP blocking alone fails against rotating proxies.
• Ignoring your own low-value transactions. Small orders are the attack surface.
• Setting thresholds once and never revisiting them after a season or a promotion.
• Letting digital goods deliver before any risk check completes.
• Treating a drop in decline rate as good news without checking authorization volume.

FAQ

Does card testing affect small stores?

Yes. Automated tools do not screen by revenue. A store with a simple checkout and no velocity limits is an easier target than a large retailer with a fraud team.

What is the first fix?

Rate limiting on the payment endpoint plus a rule that flags bursts of low-value attempts. Both are cheap and both cut the volume attackers can push through.

How do I know an attack already happened?

Look for a spike in authorizations that did not turn into fulfilled orders, a rise in disputes weeks later, and a cluster of attempts sharing an IP range or device identifier.

Can I stop it completely?

No. You can make your store an expensive target, which is often enough to send attackers to an easier one.