Card Testing Prevention: Stop Carding Attacks at Checkout

Card testing prevention comes down to one goal

Card testing is what happens when someone runs a list of stolen card numbers through your checkout to learn which ones still work. The attacker does not want your product. They want a yes or no from your payment gateway. Once they have that answer, the live numbers get sold or spent somewhere bigger. Your store is the testing lab, and you pay for the experiment in chargebacks, per-transaction fees, and a fraud ratio that can put your merchant account at risk.

Prevention has two halves. Make each attempt expensive to run, and make a successful attempt tell the attacker as little as possible. Everything below serves one of those two halves.

What a card testing run looks like in your data

Most runs are loud once you know the shape. A typical pattern is a burst of small orders, often at the minimum amount your store allows, against guest checkout or freshly created accounts. Card numbers often come from a narrow range, so you see the same first six digits over and over. The billing address rarely matches anything, and the email addresses look generated: random strings, disposable domains, or names with trailing numbers.

On the gateway side the tell is a decline spike. Real customers decline sometimes. A tester declines dozens of times in an hour and keeps going.

Signals worth alerting on

• Decline rate on a single bank identification number jumping far above your normal baseline
• Many authorization attempts from one IP, subnet, or hosting provider in a short window
• Order totals clustered at your smallest allowed amount
• Repeated cards from the same BIN range across unrelated orders
• Guest checkout with no browsing history before purchase
• Email patterns that look machine generated, or addresses that have never existed elsewhere
• Attempts spread across many accounts that share a device fingerprint

The controls that do the heavy lifting

Velocity limits

Cap attempts per IP, per card fingerprint, per email, and per device over rolling windows. Rate limit the payment endpoint itself, not just the storefront page. Attackers often skip your HTML and post straight to the API that creates the charge.

CVV and address verification

Require both and reject mismatches outright. Testers usually hold a card number, not the card. A hard CVV check removes a large share of their inventory in one step.

Bot detection and challenge

Turn on a challenge when a session behaves outside normal ranges. You do not need to challenge every visitor. You need to challenge the session making its ninth attempt in three minutes.

3D Secure

Authentication shifts chargeback liability to the issuer and adds a step most automated tools cannot complete. It costs you some conversion, so consider triggering it by risk score instead of applying it everywhere.

Gateway fraud tools

Most processors ship rules and scoring built for exactly this pattern. Turn them on, then tune the thresholds against your own data instead of leaving defaults in place.

Checkout details attackers exploit

Instant, specific decline reasons help a tester sort live cards from dead ones. Keep customer-facing messages vague, log the detail on your side, and avoid confirming which field failed. Unlimited retries on the same session give a script free attempts, so cap them. If your payment flow can be driven without a session token tied to a real browser session, bind it.

A short response plan

1. Block the source: IP, device fingerprint, email domain, or BIN range.
2. Close the path they used, even if that means temporarily requiring authentication or a challenge.
3. Void or refund authorizations that have not settled yet.
4. Call your processor's fraud desk and report it. They see patterns across merchants that you cannot.
5. Log everything and review the run afterward for signals you should have caught earlier.

What not to do

Do not lean on a single signal, because testers rotate IPs and emails constantly. Do not ignore small-ticket attempts just because the dollar amount is trivial. Do not block a whole country as your first move when velocity rules and CVV enforcement will handle most of it. And do not leave test mode credentials or an unprotected payment endpoint exposed anywhere in production.