What a card testing pattern is

A card testing pattern is the set of signals left behind when someone pushes many card numbers through a payment form or payment API to learn which ones authorize. The most reliable single pattern is a burst of low-value authorizations across many card numbers from a small set of devices or IP addresses. The criteria used below to tell one pattern from another are: amount size, attempt velocity, spread across BINs and issuers, device and network reuse, and the ratio of declines to approvals.

card testing pattern detection

Card testing, sometimes called card checking or enumeration, is not shopping. The person submitting the numbers does not intend to buy the item. The goal is information: a valid number, a working expiration date, a CVV that matches. What a merchant sees afterward is a shape rather than a single event. One declined charge means little. Two hundred declines across two hundred card numbers in six minutes means a great deal.

Card Testing Pattern Detection: How to Spot Card Testing Attacks

The pattern lives in authorization logs, not in the order queue. Most test charges are small, many are declined before settlement, and the ones that succeed often come back later as refunds or disputes. That is why the pattern has to be read from payment data: amounts, response codes, timing, and the identifiers attached to each attempt.

what is a card testing pattern

Signals that make up the pattern

Amount signature

Testers favor amounts large enough to trigger a real authorization but small enough to avoid notice: one dollar, fifty cents, a few cents, or the price of a cheap digital item. A cluster of low-value attempts that does not match your normal order value is the clearest single signal.

common card testing patterns

Velocity

Real customers move at human speed. Scripted attempts do not. Watch for many attempts per minute from one IP, one device fingerprint, or one customer account, and for the same card being tried several times with small variations.

BIN and issuer spread

A single shopper usually pays with one or two cards. A tester cycles through dozens or hundreds of numbers, often drawn from a narrow set of BIN ranges. A high count of distinct cards sharing a BIN, paired with near-zero repeat use of any one card, points to enumeration.

Device, network, and identity reuse

Look at what stays constant while the card numbers change: the same IP address or proxy pool, the same device fingerprint, the same email naming pattern, a blank shipping field, the same user agent. Constancy on one side and churn on the other is the signature.

Timing and session shape

Scripted traffic arrives in tight clusters with near-identical gaps between requests. Human sessions include hesitation, navigation, and cart edits. A checkout that jumps straight to the payment step with no browsing deserves a second look.

Rule-based detection

Rule-based detection turns the signals above into fixed thresholds: more than X attempts per minute, more than Y distinct cards per device per hour, any attempt below a set amount from a new account.

  • Pros: fast to deploy, easy to explain to a support team, and predictable in what it blocks.
  • Pros: inexpensive to run at high volume and simple to audit after an incident.
  • Cons: rigid thresholds misfire during legitimate spikes such as a flash sale or a gift card promotion.
  • Cons: testers adapt by slowing down and spreading attempts, which slides activity under the thresholds.

Use rules when you need a first line of defense today, when your volume is modest, or when you want a clear audit trail for one specific abuse case.

Behavioral scoring and velocity models

Scoring models weigh many signals at once, including past behavior tied to a device or account, the relationship between card BIN and billing country, and how a session compares with your normal traffic.

  • Pros: catches slow, distributed testing that fixed thresholds miss.
  • Pros: reduces friction for known good customers, since one odd signal does not force a block.
  • Cons: needs labeled data and ongoing tuning, so it takes time to become useful.
  • Cons: scores are harder to explain to a customer whose order was held.

Use scoring once you have enough transaction history to train and validate it, and keep rules in place for the patterns you already know.

Response playbook

  1. Rate limit the payment endpoint by IP, device, and account, separate from your general site limits.
  2. Require a challenge such as a CAPTCHA or a 3-D Secure step-up when a session crosses a velocity threshold.
  3. Hold the attempt, not the customer record, until the pattern is confirmed.
  4. Void or refund confirmed test charges fast to limit dispute exposure.
  5. Log the full attempt set, including response codes and identifiers, for your own review and for your acquirer.
  6. Review the rule or score that missed, then adjust that threshold instead of stacking a new rule on top of it.

What the pattern is not

Not every cluster of declines is card testing. Expired cards on file, a bank outage, a mistyped ZIP code, or a customer retrying after an address error all produce multiple failed authorizations. Check whether the attempts come from one identity or many, whether the amount fits your store, and whether the same card is retried with small corrections. Retries with corrections suggest a real customer. Fresh card numbers with no corrections suggest enumeration.