Card testing in one paragraph

Card testing is the practice of pushing many card numbers through a payment form to learn which ones are still active. Sellers of stolen card data hold large lists and cannot tell live accounts from closed ones, so they fire small charges and watch the authorization response. The merchant sees a spike in attempts, most of them declined, often within a short window and often from a narrow set of IP addresses. The cost lands in processor fees, chargebacks on the few approvals that slip through, and a damaged fraud score.

What you need before you start

  • Gateway access with raw authorization logs, not just settled orders
  • Response codes for AVS and CVV on each attempt
  • IP, device fingerprint, and email data tied to each attempt
  • Your processor's fraud desk contact

The card testing procedure

  1. Export all authorization attempts from the last 24 hours, including timestamp, amount, response code, AVS result, CVV result, IP address, and card BIN.
  2. Sort the export by IP address and device fingerprint to find clusters of attempts that share one source.
  3. Compare your decline rate for the day against the trailing 30-day average for the same checkout path.
  4. Flag any cluster where one source generated more than ten attempts, or where amounts repeat at the same small figure.
  5. Scan the flagged clusters for approvals. A single approved attempt confirms the attacker found a live card and a working endpoint.
  6. Build an evidence file: BIN ranges hit, timestamps, IP addresses, endpoint paths, and dollar totals for both approvals and declines.
  7. Add rate limiting to the checkout endpoint, capping attempts per IP, per device, and per card BIN per hour.
  8. Turn on a challenge step, such as a CAPTCHA or a one-time code sent to the cardholder, for any session that trips the velocity cap.
  9. Set authorization rules to require a CVV match and an AVS match, and to decline country pairs that do not match between the IP and the billing address.
  10. Send the evidence file to your processor and acquirer, then void or refund any approved orders that came from the flagged clusters.
  11. Re-run the same export 48 hours later to confirm the burst has stopped and the decline rate has returned to baseline.

Signals that separate testing from normal decline traffic

Ordinary declines come from real shoppers who mistyped a digit or used an expired card. They arrive at a normal pace, spread across many IP addresses, and often end with the customer retrying and succeeding. Testing looks different. The attempts arrive in bursts, hit the same endpoint, use a fixed amount, and produce a decline rate that runs far above your baseline. The BINs in a single burst often sit inside a narrow range because the attacker is working through a purchased list in order.

Why the challenge step matters more than the block

Blocking an IP address or a BIN range only moves the attacker to the next one. A challenge step raises the cost of each attempt, because the attacker now needs a working phone number or a human to solve the puzzle for every card in the list. That is the point where testing stops being profitable and the traffic moves on to a softer target.

After the attack

Log the BIN ranges and IP blocks in a standing deny list, review whether any approvals turned into chargebacks, and keep the evidence file for at least 12 months. Processors ask for the same data on every dispute, and having it ready shortens the response cycle.