A card testing pattern is the recognizable trail of behavior left behind when stolen card numbers are pushed through a payment form to find out which ones are still active. The person behind it is not shopping, they are validating. A small charge that gets approved proves the card works, and a decline tells them to discard that number. Because the goal is verification rather than a purchase, the activity arrives in clusters of small, fast, near-identical transactions that do not look like normal buying.

card testing patterns

How card testing works

Card testing, sometimes called carding or account enumeration, depends on volume. An attacker holds a list of card numbers, often bought in bulk after a data breach, and needs to know which ones a bank will still authorize. Running a large authorization in a store risks a decline and draws attention, so the attacker starts with tiny amounts on a merchant with weak verification.

common card testing patterns

The usual sequence looks like this:

more on this topic

  • A batch of card numbers is loaded into a script or a botnet.
  • Each number is submitted for a low-value purchase or a donation-style charge.
  • Approvals are kept and declines are dropped.
  • The verified numbers are sold or used later for larger fraudulent purchases.

The merchant may only notice weeks later, when chargebacks and fraud reports arrive for orders that were never going to be legitimate.

common card testing patterns

What a card testing pattern looks like

No two attacks are identical, but the signatures repeat often enough to be useful. A card testing pattern usually includes several of these traits at once:

  • A sudden spike in order volume from a small set of IP addresses or devices.
  • Many different card numbers submitted from the same session or browser.
  • Repeated low-value attempts, often the same amount over and over.
  • Card numbers that fall inside a narrow range of bank identification numbers.
  • An unusually high decline rate mixed with a few approvals.
  • Billing details that do not match the card, the IP location, or the shipping address.
  • Orders placed in bursts at odd hours, then silence, then another burst.
  • Disposable email addresses and free or proxy phone numbers.
  • Retries on the same card after a decline, with only the expiration date changed.

Each item alone is weak evidence. Several together, especially inside a short time window, is what turns noise into a card testing pattern.

Why the pattern matters more than a single charge

One small charge is easy to ignore. The pattern is what carries the cost. Merchants absorb chargeback fees, lose the goods when they ship, and pay higher processing rates after a fraud spike. Card networks also monitor merchants for excessive fraud and dispute ratios, which can lead to reserve requirements or account reviews. That is why detection has to look at behavior across transactions rather than judging each order on its own.

Signals that separate card testing from real shoppers

  • Timing. Real customers browse before buying. Testers submit fast, often within seconds of each other.
  • Cart contents. Testers pick cheap items or the default cart, while genuine buyers show normal browsing history.
  • Repeat attempts. A shopper who fails once may retry with the same card. Testers retry with a different card each time.
  • Identity consistency. Device, IP, email, and billing data usually line up for real customers and often contradict each other during testing.
  • Volume per identity. One device submitting many cards is a strong sign of automated validation.

How merchants detect card testing patterns

Detection combines rules, scoring, and a few controls at checkout. Common tactics include:

  • Velocity limits per IP, device, email, and card fingerprint.
  • Monitoring decline rates and low-value authorization spikes in real time.
  • Requiring the card verification value and a matching billing address on first orders.
  • Using a CAPTCHA or bot challenge when traffic looks automated.
  • Applying 3D Secure, which shifts liability and adds a step that scripts struggle with.
  • Blocking known bad IPs, proxies, and disposable email domains.
  • Flagging orders where several cards share one device or one delivery address.

Steps to reduce card testing exposure

  1. Set a minimum order value or require additional verification below a threshold.
  2. Turn on address and CVV checks for every new customer.
  3. Add rate limiting to the payment endpoint, not just the site.
  4. Alert on anomalies, such as a jump from a handful of declines to dozens in an hour.
  5. Review and refund suspicious micro-charges before they turn into chargebacks.
  6. Log device and network data so patterns can be reconstructed after an attack.

Frequently asked questions

Is one small charge enough to call it card testing?

Not on its own. A card testing pattern needs repetition, usually several low-value attempts from related devices or networks within a short period.

Do chargebacks always follow card testing?

Not always. Some testers never complete a purchase. The cost still appears, through processing fees, network monitoring, and the fraud that follows on the validated numbers.

Can small merchants be targeted?

Yes. Testers often prefer smaller sites because verification controls are lighter and automated scripts are less likely to be blocked.