What a card testing attack is

A card testing attack is a burst of low-value payment attempts run with stolen card numbers to learn which accounts are still open. The attacker scripts a checkout page, a donation form, or a payment API, submits numbers in sequence, and logs the ones that authorize. Working numbers get used for larger purchases or sold on. For a merchant, the fallout arrives as a wave of declines, chargebacks, processor fees, and in bad cases a frozen account.

The attack is cheap to run and easy to hide, which is why it hits small merchants hardest. A site with no velocity rules and no verification can process thousands of attempts before anyone notices.

Prerequisites

  • Access to your payment gateway's fraud and velocity tools
  • Authorization logs covering at least the past 30 days
  • An alert channel for traffic spikes (email, chat, pager)
  • Contact details for your acquiring bank's fraud desk

How to spot an attack in progress

  1. Open your gateway's authorization log and sort by timestamp.
  2. Group the attempts by IP address, device fingerprint, and email domain.
  3. Flag any IP that produced more than ten declined attempts within one hour.
  4. Check whether many attempts share a single bank identification number (BIN) range.
  5. Review order values. Card testing leans toward amounts near the minimum your gateway allows, often under one dollar.
  6. Compare customer email domains. Disposable domains and long random strings are a signal.
  7. Read the decline codes. Bulk issuer responses such as "do not honor" mean the numbers were guesses.

How to stop it

  1. Turn on address verification (AVS) and decline on a full mismatch.
  2. Require the card verification value and decline on any mismatch.
  3. Set velocity limits per card, per IP, per email, and per billing address over rolling 10-minute, 1-hour, and 24-hour windows.
  4. Add a CAPTCHA or proof-of-work challenge at the payment step, not only at login.
  5. Block or challenge traffic from data center IP ranges, open proxies, and Tor exit nodes.
  6. Require 3D Secure for any transaction that trips a risk rule.
  7. Enable fraud scoring from your gateway or a third party and route borderline orders to manual review.
  8. Alert when declines cross your baseline, such as a threefold jump over the same hour last week.

What to do after an attack

  1. Do not fulfill any order tied to the flagged attempts.
  2. Export the affected card numbers, IP addresses, and timestamps.
  3. Report the incident to your acquiring bank and processor through their fraud desk.
  4. File a complaint with the FBI Internet Crime Complaint Center.
  5. Void authorizations that have not settled and document each chargeback response.
  6. Retain the logs for at least a year. Disputes can arrive months after the fact.

The goal is not to catch every attempt. It is to make your checkout expensive enough to probe that attackers move to an easier target, while your real customers complete a payment without friction.