Common card testing patterns are the small, repeated authorization attempts that fraudsters use to check whether stolen card numbers still work. They appear as bursts of low-value charges, sweeps across a single issuer range, mismatched billing details, and rotating devices, all aimed at a checkout page in a short window.
These patterns matter to merchants because every test creates a real authorization request. One run can generate thousands of them, and the fees, chargebacks, and network penalties land on the business that accepted the traffic.
Why do card testers use small amounts?
A test charge is not meant to make money. It is meant to return one answer: approved or declined.
Small amounts lower the chance the real cardholder notices, and they stay under the velocity limits many processors apply to larger transactions. A 50-cent attempt that approves tells the attacker the card is live and worth using for a bigger purchase later.
card testing pattern detection
That is why the first sign of an attack is often a spike in transactions under a dollar, not a jump in total volume.
What are the most common card testing patterns?
Micro-charge velocity bursts
A large number of tiny authorizations hit the same merchant account in minutes. The average ticket drops while the transaction count climbs, so revenue can look normal while the count looks wrong.
BIN and issuer-range sweeps
Testers group cards by the first six or eight digits, which identify the issuing bank and card product. A sweep walks one range after another, which is why declines cluster around a handful of BINs at a time.
Sequential or patterned card numbers
Some attempts use card numbers that run in order, share a prefix, or differ by a single digit. Real customers do not arrive in numerical order, so an ordered sequence inside a short window is a strong signal.
Identity mismatch clusters
Billing names, ZIP codes, emails, and IP locations disagree with each other. The same email may appear with dozens of card numbers, or one card may be tried against several addresses.
Card-on-file and zero-dollar probes
Testers target saved-card flows and verification endpoints that return an approve or decline without moving money. Zero-dollar or one-dollar authorizations on stored cards appear as failed verification attempts rather than sales.
Distributed IPs and device rotation
A single script may rotate proxies, user agents, and device fingerprints to dodge per-IP limits. The traffic looks spread out until you group it by card range, email, or timing, and one shared shape appears.
Trial and low-tier plan abuse
Free trials and the cheapest subscription tier offer a low-cost way to confirm a card works. Many signups from one domain, each with a different card and no follow-up activity, fit this pattern.
Decline spikes followed by approvals
Attackers keep going until something approves. A wall of declines with a few scattered approvals in the same minute, sent from the same device block, is a common fingerprint. Real shoppers do not retry 40 times in 60 seconds.
What signals do these patterns share?
- Volume: many attempts inside a short window.
- Low value: tickets far below the normal average.
- Concentration: activity grouped by BIN, email, or device.
- Mismatch: billing, shipping, IP, and email data that do not fit together.
- Repetition: the same card tried with different addresses, or the same address with different cards.
How do merchants detect card testing?
- Track authorization counts per minute, not just revenue, and set alerts on count spikes.
- Segment by BIN and watch for one range taking a large share of attempts.
- Score each order on email age, IP reputation, device fingerprint, and address match.
- Flag repeated declines from one device or IP block within a short window.
- Review orders under a dollar that come from new accounts with no history.
How do you stop card testing at checkout?
Most controls add friction for scripts and none for real buyers. The goal is to make the payment step costly to automate, not annoying to use.
- Require CVV and full address verification on first orders.
- Rate limit per IP, device, and card range, with a short cooldown after repeated declines.
- Place a bot check on the payment step, where scripts must interact.
- Block disposable email domains and known proxy ranges.
- Route high-risk orders to manual review instead of auto-approving them.
- Ask the processor for velocity rules tuned to your average ticket.
Frequently asked questions
What is the difference between card testing and carding?
Carding is the broader effort to use stolen card data for purchases or cashout. Card testing is the validation step inside it, where someone checks which numbers are still active before spending them.
How long does a card testing attack last?
Some runs last seconds and others continue for days. Scripts often pause after a block and resume from new IP ranges, so a merchant may see several waves from the same campaign.
Does card testing always use small amounts?
No. Low-value charges are the most common, but testers also use gift cards, digital goods, and recurring donations. Any flow that returns a fast approve or decline can validate a card.
What does card testing cost a merchant?
Every test attempt is a real authorization, and processors charge for them. A high decline rate can also raise a merchant's risk score and processing fees.
Chargebacks from the successful tests arrive weeks later, and card networks track fraud ratios by merchant. A sustained attack can lead to a reserve requirement, an account freeze, or loss of the account.
The fix is cheap by comparison. Rate limits, address verification, and count-based alerts catch most runs before the first fraudulent purchase clears.