A card test is a low-value authorization attempt used to check whether a stolen card number still works. Detection rests on two things: velocity patterns and the mismatch between the card data and the device or location behind the request. If a wave of small authorizations hits your gateway in a short window, from many cards but few devices or IP addresses, treat it as a test run until you prove otherwise.

Signals that separate a card test from normal traffic

  • Authorization amounts clustered between $0.00 and $1.00, repeated across many card numbers.
  • High decline rates coming from one IP address or device fingerprint.
  • Many cards sharing a BIN range, email domain, or billing ZIP.
  • Order attempts that fail AVS but pass the CVV check.
  • Sessions lasting a few seconds with no browsing history before checkout.

How to investigate a suspected test run

  1. Export the authorization log for the affected window. Include amount, response code, BIN, IP, device ID, and timestamp.
  2. Group the records by IP address and device ID. A single source generating dozens of distinct card numbers is the clearest indicator.
  3. Sort by response code. Testers need a mix of approvals and declines to learn which cards are live, so both categories matter.
  4. Check card fingerprint reuse. The same card appearing across multiple accounts points to an account takeover attempt layered on top of the test.
  5. Review AVS and CVV results as separate fields. A pattern of ZIP mismatches paired with CVV matches suggests the number was sourced without full cardholder data.
  6. Block the source. Add the IP range, device fingerprint, and BIN pattern to your deny rules before the next wave.
  7. Document the incident. Record the timeframe, volume, and response codes for your acquirer and processor.

Controls that stop the next wave

Rate limits per IP address and per card fingerprint remove the volume a tester needs. Requiring CVV and full AVS on the first order raises the cost of a probe. Velocity rules that count authorization attempts, not just completed orders, catch tests that never convert. Some processors also offer BIN-level blocking, which lets you shut down a range that is being tested in bulk.

Keep in mind that a test run is reconnaissance. The same actors return with larger orders once they hold a working card, so your response needs to close the account access path, not only the payment path.