The short answer

A card enumeration attack guesses card numbers the attacker does not hold, then watches authorization responses to learn which numbers are live. Card testing validates card data the attacker already holds. A BIN attack is enumeration narrowed to one issuer range. Credential stuffing replays leaked logins against a site. The split comes down to what the attacker already knows and what the response tells them. Enumeration creates new numbers, testing spends stolen ones, and stuffing never touches the card field at first.

related article

What each attack guesses

  • Card enumeration: the primary account number itself, usually built from a known BIN plus a generated suffix, checked against an expiry and CVV guess.
  • Card testing: whether a full set of stolen card details still authorizes, often with a small-value purchase.
  • BIN attack: the same method as enumeration, but limited to a single issuer identification number so the attacker can harvest one portfolio.
  • Credential stuffing: whether a leaked username and password pair opens an account, with card data reached only after login.

Enumeration and BIN attacks produce a wide spread of decline reasons across many numbers. Card testing produces a narrow set of numbers hit many times. Stuffing produces login failures, not authorization failures.

card enumeration attack compared to

Classify the traffic in six steps

  1. Pull the authorization log for the window and group requests by the first six digits.
  2. Count distinct full card numbers per BIN. A high distinct count with a low repeat rate points to enumeration.
  3. Count attempts per single card number. A high repeat rate with a small number of cards points to card testing.
  4. Check the response mix. Enumeration shows a high share of invalid-account and no-such-issuer declines.
  5. Compare the request source. Enumeration usually arrives from scripted clients on shared address ranges with near-identical timing.
  6. Review the account and login layer for failed password attempts on the same addresses before you label the event.

Controls that map to each attack

  1. Set velocity limits per card number, per BIN, and per client address, then alert on each threshold.
  2. Block or challenge requests that fail the issuer verification check more than a set number of times from one client.
  3. Require the card verification value and a matching billing address on first-time customers.
  4. Add device fingerprinting so a single device cannot rotate through hundreds of card numbers.
  5. Rate limit login endpoints separately from checkout endpoints to catch stuffing before it reaches the card field.
  6. Route high-risk authorization attempts to a step-up challenge rather than a silent decline.

Where teams misclassify

Most errors come from reading decline counts without grouping. A spike in declines looks like a single event, but the BIN breakdown tells you whether one issuer range is under enumeration or a batch of stolen cards is being tested. Another common error is treating a low-value purchase burst as harmless. Small amounts are chosen to keep the attempt under review thresholds. Review the full request pattern, not the ticket size. Keep an approval-rate baseline by BIN so a slow enumeration run stands out against normal traffic instead of hiding inside routine decline noise.

more on this topic