What card testing is

Card testing is a fraud pattern where someone submits many small authorization requests to find out which stolen card numbers are still open. The attacker scripts those attempts against a checkout, donation page, or subscription endpoint. From the merchant side it shows up as a burst of tiny orders, a spike in declines, or hundreds of attempts from a small set of IP addresses. The goal is not the merchandise. The goal is a list of cards that authorize, which the attacker resells or uses later for larger purchases.

read more

Prerequisites

  • Admin access to your payment gateway and fraud rules
  • At least 30 days of authorization logs for a baseline
  • A named contact on your acquirer or processor risk team
  • Ability to deploy bot protection or CAPTCHA on the checkout page

How to detect card testing

  1. Export the last 24 hours of authorization records from your gateway, including card BIN, amount, response code, IP address, and email.
  2. Group the records by BIN and count attempts per BIN. A normal merchant does not see hundreds of attempts on one BIN in a day.
  3. Group the same records by IP address and count attempts per hour. Flag any address above your normal ceiling.
  4. Sort by amount. Card testing runs cluster at small round numbers, often under a few dollars.
  5. Check the customer email field for patterns: random strings, sequential numbers, or one domain with many aliases.
  6. Compare that day's approval and decline rates against the 30 day baseline. A decline rate that triples inside an hour is the strongest single signal.

How to stop an attack in progress

  1. Turn on AVS and CVV verification as hard decline rules so mismatches fail before authorization.
  2. Set velocity limits: a maximum number of attempts per IP, per card, and per email inside a rolling window.
  3. Deploy CAPTCHA or a bot-detection script on the checkout and on any guest purchase path.
  4. Require 3D Secure or an equivalent challenge for transactions that trip your risk rules.
  5. Block the IP ranges and user agents you identified, and keep the block list active for at least two weeks.
  6. Call your acquirer risk team the same day. They can watch for follow-on attempts across other merchants on the same BIN range.
  7. Void or refund the small charges that approved. Left alone, they turn into chargebacks and fees.

What to fix afterward

Card testing does not stop after one block. Attackers rotate IPs and endpoints, so the durable fix is friction at the point of sale: verified card data, a challenge on suspicious traffic, and limits that make scripted attempts expensive. Review your rules each month against your own decline data, and keep the acquirer contact current.

Card Test: What It Is and How Merchants Spot It