A card testing pattern is the observable trail left when someone runs a batch of card numbers through a checkout to learn which ones still authorize. The tell is not a large order. It is a cluster of small, repeated authorization attempts where the card number keeps changing but the rest of the session stays oddly similar. Merchants catch it by reading authorization outcomes and request metadata together, not by watching order value alone.

What the pattern looks like in a payment log

Card testing shows up as volume without customers. You see many attempts per minute from one IP range, a high share of declines with a few scattered approvals, and almost no carts that turn into normal shopping behavior. The attempts often land on the cheapest item, a donation field, or a stored card form, because the goal is a cheap authorization check rather than a purchase.

Because the authorizing bank answers in under a second, the attacker learns something from every response. That feedback loop is the part that separates testing from ordinary fraud. Ordinary fraud wants goods. Testing wants information.

Micro-authorization bursts

This is the classic shape. Dozens of attempts in a short window, each for a small amount, often the same amount, from a small set of IP addresses or devices.

Signals that support it

• Attempt rate far above your normal peak for that hour or channel.
• Same amount repeated across different card numbers.
• High decline ratio with a small number of approvals mixed in.
• Requests arriving with no page views, no cart changes, and no time spent on site.

What it gets confused with

• Legitimate retry loops from a broken checkout that resubmits on timeout.
• Subscription dunning, where one customer retries the same card many times.
• Promotional spikes where a small fixed price drives real volume.

Distributed attempts across many issuers

More mature testing spreads the load. One attempt per IP, one attempt per card, and the bank identification numbers change on nearly every request. Velocity rules keyed to a single address miss it entirely, because no single source looks busy.

What stays constant is usually something less obvious: a shared device fingerprint, a reused email pattern, a shipping address that repeats, or a narrow window of time. Correlating across those fields is what exposes the cluster.

Identity churn on the checkout form

Card testers often burn through identities faster than cards. Watch for disposable email domains, mismatched billing and card country, addresses that fail verification at a rate well above your baseline, and account creation that happens seconds before the first attempt.

• Strong indicator: new account plus first attempt within the same minute plus a failed address check.
• Weak indicator: a foreign billing address on its own, which is normal for many honest cross-border shoppers.

Signals that confirm the pattern and signals that mislead

No single field proves testing. Weight the evidence.

Evidence that holds up

• Attempt volume that scales with decline volume, meaning the attacker is iterating.
• Sequential or near-sequential card numbers appearing in one session.
• Approvals that never convert to a shipped order.
• Traffic that ignores the product pages and hits the payment endpoint directly.

Evidence that produces false positives

• Shared corporate IP addresses, which can look like one source but represent hundreds of buyers.
• Gift card or prepaid card use, which is legitimate and also common in testing.
• Mobile carrier address changes, which shift IP mid-session without any fraud.

Which controls fit which situation

Match the control to the pattern you actually see, then measure the effect on approval rates.

1. Burst traffic from few sources: rate limits on the payment endpoint, plus a temporary block on the source range.
2. Distributed low-value attempts: device and behavioral signals, plus velocity rules keyed to card fingerprint rather than IP.
3. Identity churn: step-up verification at account creation and before the first payment.
4. Authorization abuse: use the issuer and network tools built for it, and keep a decline reason on record so you can review clusters later.

Two operational habits matter more than any single rule. Log every authorization attempt with its outcome and request metadata, and review clusters weekly rather than only after a chargeback lands. Testing is cheap for the attacker because most attempts are declined. Your cost is not the declined transaction. It is the interchange fees, the fraud scoring damage, and the risk of losing card acceptance if the volume goes unnoticed.

One last point on framing. Card testing is a payment security problem, not a sourcing problem. Blocking the pattern at the endpoint removes the value of the exercise, which is the only durable fix.