What a card testing pattern is
A card testing pattern is a run of authorization attempts made to learn which stolen card numbers still work. The run shows up in payment logs as many small-ticket requests, often from one device fingerprint or IP range, inside a short window. Each attempt is cheap for the attacker. A declined authorization costs nothing, and an approved one confirms a live card. Merchants see the result as chargebacks, processor fees, and a rise in decline rates rather than as one obvious fraud order.
Common card testing patterns
Low-value bursts
Dozens or hundreds of authorizations for amounts between one cent and one dollar land within minutes. The amounts repeat, one merchant account absorbs them, and the approval rate sits below the baseline for that store.
Understanding Credit Card Check Format: A Guide
BIN attacks
Attempts sweep through sequential numbers inside a single bank identification number. The first digits stay constant, the last digits climb, and expiration dates cycle through a small set of values. A BIN attack can generate thousands of attempts before any order ships.
Card Verification Pattern Set: What It Is and How It Works
Distributed retries
The same card number appears across many IP addresses, many customer emails, and many shipping addresses. Attackers rotate proxies and user agents to keep each single attempt under velocity limits.
Signals to monitor
- Approval rate for low-ticket transactions dropping below the store baseline.
- Repeated card numbers paired with one-time email addresses.
- Many declines from one customer ID or device fingerprint.
- Address verification and CVV mismatch rates climbing on small orders.
- Verification checks disabled on card-not-present authorizations, which removes the main rejection signal.
- Authorization volume rising while completed orders stay flat.
How to respond
Prerequisites: read access to gateway authorization logs, your processor fraud report, and permission to change rules in the payment stack.
- Pull the last 30 days of authorization records and filter for transactions under one dollar.
- Group those records by card BIN, device fingerprint, and IP address to find clusters.
- Compare each cluster approval rate against the store average for the same period.
- Enable CVV and address verification on all card-not-present authorizations.
- Set velocity limits on attempts per card, per IP, and per customer ID.
- Add a block rule for BINs that produce repeated declines across multiple cards.
- Send the clustered data to your acquiring bank and to the card network fraud reporting channel.
- Review the rule set after two weeks and adjust thresholds against the new baseline.
Card testing stops when the attempts become unprofitable. Rate limits, verification checks, and fast reporting raise the cost of each attempt, and that cost is the lever merchants control.