Short answer

Card testing prevention comes down to making the attack expensive while keeping checkout cheap for real buyers. That means throttling authorization attempts per IP, device, email, and card; enforcing CVV and AVS instead of waving them through; and wiring up alerts so you notice a spike in small declines while it is still happening. CAPTCHA and 3-D Secure help, but the basic velocity rules do most of the work.

carding test prevention

What a carding test looks like in practice

A carding test is a low-value order run against a stolen card number to see if the card is still live. The attacker does not want the merchandise. They want the response code. An approval means the number gets sold or used somewhere bigger. A decline means they move to the next number, and they can run hundreds of those in a minute.

Carding Test Detection Tool: How Merchants Spot Card Testing Attacks

The patterns are consistent enough that you can spot them without expensive tooling:

Carding Test Prevention Software: How Merchants Block Card Testing

  • Many orders in a short window, all in the same small dollar range, often $0.50 to $5.
  • Sequential or near-sequential card numbers, which is the signature of a BIN attack.
  • One card number spread across dozens of emails and shipping addresses, or one email used with many cards.
  • Traffic from datacenter ranges, VPN exit nodes, or proxies rather than residential connections.
  • Digital goods and instant-delivery items chosen over anything that needs to ship.
  • Disposable email domains at checkout, especially with guest checkout enabled.

Why it costs more than the declined orders

The chargebacks are only part of the bill. Every test attempt hits your authorization rate, and a low authorization rate invites scrutiny from your processor. Visa's Acquirer Monitoring Program and Mastercard's equivalent programs track fraud and dispute ratios at the acquirer level, and merchants with bad numbers end up paying fines or losing processing entirely. Add the per-chargeback fees, the staff time on disputes, and the fact that real customers get caught in your blocks, and a small test run can cost far more than the fraudulent orders were ever worth.

read more

Controls that stop most of it

  1. Rate limit at several layers. Cap attempts per IP, per device fingerprint, per email, and per card BIN over rolling windows. One limit is easy to slip past with rotating infrastructure. Four of them together is not.
  2. Require CVV and check AVS. Turning off CVV verification to lift conversion is the single most common reason stores get hammered. It is also the easiest fix to reverse.
  3. Add a challenge, not a wall. Show CAPTCHA or a step-up 3-D Secure challenge after a few failures from the same source, rather than on every visit. Real buyers rarely see it, attackers hit it constantly.
  4. Set a minimum order value. If your average order is $60, a $1 order has no business going through without a challenge.
  5. Filter infrastructure. Block or challenge known datacenter, proxy, and VPN ranges on the checkout endpoint. Some legitimate shoppers use VPNs, so route them to verification instead of a hard block.
  6. Void instead of capture. If you catch a test order before settlement, void the authorization. Capturing and refunding just adds fees and hands value back to a stolen card.
  7. Protect gift cards and store credit. Balance-check endpoints get abused the same way card numbers do. Throttle those too.

Tuning so you do not block good customers

Every rule you add trades fraud loss for false declines, and false declines are silent. I would rather start tight for a week, log what got blocked, then loosen specific rules than start loose and chase chargebacks for a month. Watch your block rate by segment. If a rule is killing orders from a country you actually ship to, narrow it by BIN or by device reputation instead of dropping it.

The day you get hit

Pull the last 24 hours of authorization logs and group by IP, BIN, and email domain. Block the top offenders, raise your velocity thresholds, and force 3-D Secure on the affected BIN ranges. Then check whether any test orders actually shipped. If they did, that is an operations problem, not a fraud rules problem, and the fix lives in your fulfillment queue.