A CVV attack pattern is the fingerprint a card testing campaign leaves on a payment gateway: a run of small authorization requests that checks which card numbers and CVV codes still work. Criminals test in bulk because stolen card lists go stale, and a verified live card is worth more than a dead one. Merchants see the pattern as bursts of tiny charges, a spike in declines, and hundreds of unique cards hitting one checkout page in a short window.
The pattern matters to store owners because card testing brings chargebacks, network fees, and account reviews. It matters to fraud teams because the same signals that catch testing also catch stolen-card checkout fraud.
What a CVV Attack Pattern Looks Like in Gateway Logs
Card testing is loud in transaction data even when it hides behind proxies. The shape of the traffic, not any single order, gives it away.
Volume and timing
- Dozens to thousands of authorization attempts on one merchant account in minutes or hours.
- Attempts spaced a few seconds apart, with no browsing before checkout.
- Traffic that starts and stops in blocks instead of following a normal daily curve.
Amounts
- Small totals, often under $5, chosen to slip past issuer scrutiny.
- Identical amounts repeated by unrelated cards, a sign of scripted requests.
- A test charge followed by a much larger order on the same card within minutes.
Card and BIN spread
- Hundreds of card numbers drawn from one bank identification number (BIN) range.
- Sequential or near-sequential card digits, which real customers do not produce.
- Cards issued in countries where the store has no customers.
Decline codes and responses
- A wall of "do not honor" or "insufficient funds" replies, then a handful of approvals.
- CVV mismatch declines at a rate far above the store's normal level.
- Address verification failures paired with approvals, which points to card data without matching billing details.
Why Card Testing Happens
Stolen card data decays. Issuers cancel compromised cards, and lists traded in bulk carry a large share of dead numbers. Testing separates live accounts from dead ones before a criminal commits to a bigger purchase or resells the list.
Some campaigns aim at the gateway itself. A tester learns how a store reacts to declines, whether it enforces CVV, and how fast its fraud rules fire. That knowledge shapes the next wave of attempts.
Signals That Separate Card Testing from Normal Decline Traffic
Every store has failed payments. Card testing differs in concentration, not in kind.
- Decline rate far above the store's own baseline for the same hour of the week.
- Many cards, few customers: hundreds of card numbers sharing one device fingerprint, IP block, or email domain.
- One email address paired with dozens of different cards.
- Failures that cluster on the CVV field while billing address and ZIP checks pass.
- User agents and screen sizes that repeat across attempts coming from different IP addresses.
How to Detect and Stop a CVV Attack Pattern
- Set velocity rules. Cap attempts per IP, card, email, device, and hour. Block a visitor after a fixed number of failures.
- Require CVV and AVS on every authorization. Bulk card lists often lack matching CVV or ZIP data, so the checks turn live-card tests into declines.
- Add bot defenses to the payment step. CAPTCHA, proof-of-work, or a bot management tool makes scripted runs costly.
- Send risky transactions through 3D Secure. An issuer challenge stops scripts that cannot pass authentication and shifts liability on the orders that do.
- Alert on decline spikes. A threshold that fires when declines pass your baseline gives you minutes instead of days.
- Block disposable emails and known bad IPs. Keep your own lists and pull in gateway or network blocklists.
- Review chargebacks on a set schedule. Card testing shows up as fraud reason codes on small orders, or as unauthorized-use disputes on items you never shipped.
- Document and report. If an attack lands, tell your processor, keep the logs, and ask about the card testing and account enumeration programs run by the networks.
What a Card Testing Attack Costs a Merchant
The direct cost starts with authorization fees. Declined attempts can still bill, and high-volume testing burns those fees by the thousand.
Chargebacks add more. Fee schedules for a single chargeback often fall in the $15 to $100 range, and networks can move a merchant into a monitoring program when fraud ratios climb. Monitoring programs bring fines, extra reporting, and the risk of losing the ability to accept cards at all.
Indirect costs are harder to total: staff hours on disputes, blocked good customers from rules that fire too wide, and the drop in sales when real shoppers get declined.
Frequently Asked Questions
Is a CVV attack pattern the same as carding?
Carding covers the whole chain of buying, testing, and using stolen card data. A CVV attack pattern is the testing stage as it appears in merchant and gateway data.
Does requiring CVV stop card testing?
It cuts it down. Most bulk card lists hold numbers without matching CVV codes, so a CVV check turns many test attempts into declines. It does not stop attackers who already hold full card details.
How fast can an attack run?
Scripts can push hundreds of attempts per minute, while manual operators work slower. Detection rules that trigger on the first ten failed attempts in one minute catch most runs at the start.
Do attacks always use stolen cards?
No. Some testers run their own valid cards first to map a gateway's rules before they burn stolen numbers. Those early probes look like odd but legal purchases.
Quick Reference: Red Flags to Watch
- Many cards, one device or one email.
- Small amounts repeated across unrelated BINs.
- Declines that cluster on CVV or AVS while approvals stay rare.
- Traffic bursts that ignore normal shopping hours.
- Chargebacks filed on orders that never generated a support ticket.