What a card testing attack is

A card testing attack is a fraud pattern in which someone submits a large batch of stolen card numbers to a merchant's payment form to learn which numbers are still active. The attacker has no interest in the product. The checkout page is being used as a sorting tool: valid numbers get separated from dead ones, then resold or used for larger purchases elsewhere.

Because each test charge is small, often under a few dollars, the pattern is easy to miss until the chargebacks and processor fines arrive. Purchasing or using stolen card data is a federal crime in the United States under 18 U.S.C. 1029, and merchants absorb much of the cost when their gateway is used as the testing ground.

Why attackers target small merchants

High-volume retailers run strict fraud screening, so testers move to smaller storefronts with looser rules. Common targets include donation buttons, gift card purchases, digital downloads, and any checkout that approves an order without a shipping address. Free trials and subscription signups attract the same traffic because a valid card number can be confirmed with a zero-dollar authorization.

Warning signs to watch for

  • A spike in declined authorizations, especially many declines from one IP address or device
  • Dozens of orders placed within minutes, each for the same low-priced item
  • Card numbers that share a bank identification number and fail one after another
  • Email addresses built from random strings, or disposable inbox domains
  • Billing addresses that do not match the cardholder country
  • Orders placed through a proxy, VPN, or hosting provider IP range
  • A sharp rise in disputes weeks after a quiet sales period

Detection steps

  1. Open your gateway dashboard and sort transactions by timestamp for the last 24 hours.
  2. Group the failed attempts by IP address and count how many distinct card numbers came from each one.
  3. Flag any IP that produced more than five declines in an hour.
  4. Pull the order list for the same window and look for repeated SKUs, quantities, or device fingerprints.
  5. Compare your approval rate for the day against your 30-day average.
  6. Export the suspicious orders and check the BIN country against the billing country for each one.
  7. Send the batch to your acquiring bank or processor with the timestamps attached.

Controls that stop the traffic

  1. Enable a challenge on the checkout page, such as a CAPTCHA or a bot-detection script.
  2. Set a velocity limit that caps the number of payment attempts allowed per IP, per card, and per email in a rolling hour.
  3. Turn on address verification and require the card verification value to match.
  4. Block the offending IP range and autonomous system number at the web application firewall.
  5. Reject orders where the billing country and the IP country do not match your normal customer base.
  6. Add a minimum order value or require account creation before purchase for high-risk product lines.
  7. Hold flagged orders for manual review and do not ship until the payment clears settlement.
  8. Log every blocked attempt so you can show your processor what you did when disputes arrive.

After an attack

Expect chargebacks to land 30 to 90 days later even if you blocked the orders. Contest them with the logs you kept: the IP addresses, the velocity data, and the delivery records for any goods that shipped. If the dispute rate crosses the threshold set in your merchant agreement, contact your processor before they contact you. A documented response plan usually matters more than the size of the attack.