Card testing prevention best practices come down to four controls: rate limits on every axis an attacker can rotate, a check that the card details match the person paying (CVV plus address verification), bot detection on any form that accepts card data, and alerts that fire when small-value authorizations spike. A test costs a fraudster a few cents, so the goal is not to make fraud impossible. The goal is to make each test expensive enough that the attacker moves to a softer target.

Card Testing Prevention Tools: A Buying Guide

What does card testing look like in a payment log?

A card testing attack looks like a burst of tiny authorization attempts. Amounts sit at $1 or less, or at zero when the attacker only wants an address verification result. One card number can hit several stores in the same minute, so any single merchant sees just a slice of the pattern.

related article

Signals that show up in payment logs:

related article

• Hundreds of attempts from one IP block, or one attempt each from hundreds of IPs.
• Card numbers that fail the Luhn check on a small share of tries, which points to generated numbers.
• Billing country that does not match the IP country or the shipping address.
• Fresh accounts that add a card and run an authorization within seconds.
• Decline rates above 80% on one payment endpoint while other endpoints stay normal.

Which controls stop the most card testing?

Layer these controls. Each one costs the attacker something, and a stack of them raises the price of a single test above the value of the card number.

more on this topic

Rate limit every axis, not just the IP

An attacker rotates IP addresses, so an IP limit alone fails. Count attempts per card number, per email, per device fingerprint, per billing ZIP, and per account. Cap all of them.

A workable starting point: 5 attempts per card per hour, 10 per email per day, 20 per device per hour. Adjust the numbers after you see your own data.

Check CVV and address verification at authorization

A failed CVV combined with a failed ZIP match is a strong sign of a test. Decline those orders or send them to manual review.

The catch: some card issuers do not support CVV checks, and address verification support varies by country. Treat a missing result as unknown, not as a pass.

Put a bot check in front of every card form

CAPTCHAs, device fingerprinting, and JavaScript challenges stop simple scripts. Attackers solve some of these with automated tools, so rotate the challenge type and watch for solve rates that look too good to be human.

Review authorizations below your normal ticket size

Small amounts are the fingerprint of card testing. If your average order is $60, an order at $0.50 from a new customer deserves a second look.

Do not auto-approve micro-charges just because the amount is low. The loss is not the $0.50. It is the interchange fee, the chargeback, and the network fine that follow.

Require 3D Secure on risky orders

3D Secure shifts liability for a fraudulent chargeback to the issuer when authentication succeeds. Many testers abandon at the challenge, which is the outcome you want.

Apply it by rule rather than to every shopper, since the extra step adds friction at checkout.

Track BIN concentration and decline spikes

Attackers often work one card BIN range at a time. An alert on "more than 50 declines from one BIN in 10 minutes" catches a wave while it is running, not after the chargebacks arrive.

How do you set thresholds without blocking real customers?

Start from your own traffic. Pull 30 days of approved orders and mark the ones that later charged back. Your thresholds should separate those two groups, and if a rule flags too many good orders, loosen it before launch.

Run every new rule in monitor mode first. Log what it would have blocked, review that list by hand for a week, then turn the rule on.

Skipping the monitor step is the classic mistake. Merchants kill checkout conversion to stop an attack that had ended days earlier.

What should you do during an active attack?

1. Turn up the friction. Add a CAPTCHA, set rate limits to the strictest value, and require 3D Secure for new cards.
2. Block the source. Ban the IP ranges, device IDs, and emails tied to the wave.
3. Call your processor. Ask for authorization logs and a block on the BIN range under attack.
4. Void and refund. Void test authorizations where you can. Refunds cost less than chargebacks and keep your fraud ratio clean.
5. Document everything. Keep the logs. If a card network fines you for excessive fraud, your record of the response matters.

Which checkout design choices invite card testing?

Guest checkout with no email verification, a payment form that returns a different error for "card declined" than for "card not found," and a signup flow that lets a user try cards before confirming an email. A decline message that says "this card is invalid" tells the attacker the number is dead. A generic "payment failed" tells them less.

Gift card balance checks and donation pages with open amount fields also attract testers, because both take a card with no shipping address. Apply the same controls to those forms as to your main checkout.

Card testing prevention checklist

• Rate limits on card number, email, device, IP, and account.
• CVV and address verification results checked, with unknown treated as unknown.
• Bot detection on every form that accepts a card number.
• Velocity rules that count failed attempts, not only approved orders.
• Alerts for decline spikes and single-BIN bursts.
• 3D Secure rules for high-risk and first-time buyers.
• Generic error messages at checkout.
• A written response plan with named owners.

Frequently asked questions

Is card testing the same as a data breach?

No. Card testing checks numbers an attacker holds. A breach is how those numbers get taken in the first place. Merchants face the testing problem even when no breach happened on their own systems.

Do small merchants get targeted?

Yes. Testers scan thousands of stores for weak checkout flows, and shops with no fraud rules are easy marks. Attack volume matters more to the tester than the size of any single store.

How fast should a block take effect?

Minutes, not hours. A wave can burn through thousands of attempts before a nightly report lands. Real-time rules on the authorization call do the work.

Does blocking card testing hurt sales?

A tuned rule set does not. Review flagged orders by hand while you tune, and keep a manual override for known customers.