Card testing prevention means cutting off the small authorization attempts criminals use to check whether stolen card numbers still work. Stop those probes at checkout and you avoid chargebacks, card brand fines, and a damaged merchant account. A working program blends transaction limits, bot detection, address and CVV rules, and daily review of decline patterns.

How does card testing work?

A card tester buys a list of stolen numbers and needs to know which ones are live. Your checkout is the cheapest place to find out, because an authorization request costs the attacker nothing when a card is dead.

The flow is short:

  1. The attacker collects card numbers from a breach, a phishing kit, or a dark web market.
  2. Software fires thousands of low-value orders or authorization attempts at many merchants at once.
  3. Approved cards get marked as live and resold or used for larger fraud.
  4. Declined cards drop off the list.
  5. The merchant eats the chargebacks, fees, and any fraud monitoring penalties that follow.

Why card testing hurts more than the stolen order value

The average test charge is small, often under five dollars. The damage shows up later.

  • Chargebacks: each fraudulent test purchase can return as a dispute with a fee attached.
  • Fraud ratios: Visa and Mastercard track the share of fraudulent transactions a merchant processes. High ratios trigger fines and monitoring programs.
  • Processor risk: acquirers warn, then freeze funds, then close accounts.
  • Operational cost: refunds, support tickets, and inventory shipped to drop addresses.
  • Data exposure: attackers also use test traffic to probe your checkout for other weaknesses.

Warning signs your store is under a card testing attack

  • A spike in declined authorizations, often in the hundreds within an hour.
  • Many orders from one IP address, one device fingerprint, or one email domain.
  • Orders for the cheapest item in your catalog, repeated with different cards.
  • Billing addresses in one country, IP addresses in another.
  • Cards from the same BIN range used over and over.
  • New accounts created minutes apart with similar usernames.
  • Heavy traffic to the checkout page while cart size sits at the minimum.
  • Messages from real cardholders asking about charges they do not recognize.

Card testing prevention tactics that work

Set velocity limits

Cap the number of payment attempts from a single IP, device, email, or card in a short window. Example rules: five attempts per IP per hour, two attempts per card per day, one order per new account in the first hour. Block the session once a limit trips instead of letting it retry.

Turn on bot defenses at checkout

CAPTCHA, JavaScript challenges, and device fingerprinting raise the cost of automation. Place the check before the payment step so bots never reach your processor. Keep the challenge light for returning customers to protect conversion.

Tighten address and CVV rules

Require CVV and reject mismatches. Use AVS rules that decline when the street number and ZIP do not match the card. These checks block testers who hold only a card number and no cardholder data.

Require 3D Secure for high-risk orders

3DS shifts liability for fraud chargebacks to the issuing bank when authentication passes. Apply it to orders that trip risk rules rather than to all traffic, so good customers keep a short path to purchase.

Watch BIN, country, and email patterns

Block or flag prepaid and gift card BINs if your business does not serve them. Reject orders where the IP country and billing country differ and no purchase history exists. Flag disposable email domains.

Use a fraud tool with network data

Stripe Radar, Adyen RevenueProtect, and similar tools score orders against attack data from many merchants. A tool that sees the same card hit several stores catches testers your own logs cannot.

What should you do if attackers already hit your store?

  1. Pull the list of declined and approved transactions from the attack window.
  2. Block the offending IPs, emails, device IDs, and BIN ranges at the edge and in your payment rules.
  3. Refund or void test charges before they settle where you can, and cancel unshipped orders.
  4. Contact your acquirer to explain the spike and show your fixes.
  5. Answer each chargeback with evidence before the deadline.
  6. Add the new rules you learned from the attack and review them again in a week.

Card testing prevention checklist

  • Rate limits on payment attempts per IP, card, and account.
  • CAPTCHA or device check before the payment form.
  • CVV required, AVS set to decline on mismatch.
  • 3DS triggered by risk rules, not applied to everyone.
  • Alerts when declines pass a threshold in one hour.
  • Daily review of orders under a set amount.
  • Blocked BIN, country, and email lists kept current.

FAQ

Does a small test transaction matter?

Yes. One probe confirms a stolen card works and marks your store as a soft target. A burst of small probes does the real damage through fees and fraud ratios.

Will more checkout friction cost me sales?

Some friction does. Target the rules: apply strict checks to new accounts, mismatched geographies, and odd velocity, and keep the path short for known customers.

How long does a card testing attack last?

Most bursts run from minutes to a few hours, then stop once the block holds. Testers return with new IPs, so review your rules after each wave.

Treat card testing prevention as an ongoing loop rather than a one-time setup. Watch your decline data, tighten rules when patterns shift, and keep a written log of what you blocked and why.