Card testing is an automated attack that pushes many card numbers through a checkout to find the ones that still authorize. You spot it by reading rate and ratio signals instead of single orders: authorization attempts per minute per IP, a decline rate that jumps from a 10 percent baseline to 40 percent or more, and clusters of attempts that share one device fingerprint while spanning many card BINs. A real customer fails once and calls support. A testing script fails two hundred times in four minutes and never opens a chat window.

card testing indicators for attack

Prerequisites

  • Authorization logs with millisecond timestamps, response codes, and decline reason codes
  • IP address, ASN, and device fingerprint captured at checkout
  • Card BIN metadata stored with each attempt, including funding type and issuing country
  • Threshold alerts on your gateway or processor dashboard, not just daily reports
  • A named on-call owner for fraud escalations

Indicators to monitor

  • Decline rate spike. Compare the current 15 minute window against the same hour on the prior week. A jump of three times baseline or more is the strongest single signal.
  • Attempt velocity per identifier. Count authorizations per IP, per device fingerprint, and per email. Scripts exceed normal human checkout speed within seconds.
  • Many cards, one device. Ten or more distinct card numbers from a single fingerprint in an hour has almost no legitimate explanation.
  • Generated card numbers. Scripts walk sequential numbers or Luhn-valid ranges. Watch for cards that differ by one or two digits in the same burst.
  • Uniform ticket values. Repeated $1.00 or $0.00 authorization attempts, or identical cart totals across unrelated sessions.
  • Geography mismatch. Billing country, IP geolocation, and issuing country that disagree on a high share of attempts.
  • Failure stacking. The same card number retried with different CVV or expiration values, or many cards failing AVS with the same address.
  • BIN drift. A burst where most cards come from issuers outside your normal customer base.

How to review a suspected burst

  1. Pull every authorization attempt in the burst window, including declines and reversals.
  2. Group the attempts by IP address, ASN, and device fingerprint.
  3. Compare the window decline rate against the same hour from the prior week.
  4. Count distinct card BINs per grouped identifier to separate testing from a shared office network.
  5. Measure the gap between attempts. Sub-second spacing across unrelated cards confirms automation.
  6. Inspect any approved transactions in the burst for shipping and billing mismatches.
  7. Hand the grouped data to fraud operations with the shared identifiers listed for blocking.

Response actions

  • Apply velocity rules to the shared IP, ASN, and device fingerprint before the next burst.
  • Step up authentication on sessions that trip more than one indicator.
  • Void or refund the small authorizations that approved, then notify your acquirer with the timestamps.
  • Record the identifiers and outcome in an incident log so repeat attackers are matched later.

False positives to rule out

  • A legitimate promotion that sends traffic to one office IP through a corporate proxy.
  • Procurement teams running several cards from a single workstation.
  • Subscription retries after a gateway outage, which produce decline spikes without BIN drift.
  • Shared kiosk or field-sales devices that legitimately present many cards from one fingerprint.

Review the indicator list monthly against your own traffic. Baselines shift with seasonality, and a threshold that caught a burst in December may stay quiet through a slow February while a smaller attack slips under it.

more on this topic