CVV attack detection is the practice of spotting automated attempts to check stolen card numbers by reading transaction patterns instead of card codes. The clearest signals are bursts of small authorizations, one device or IP address trying many cards, and a sudden rise in declines. PCI DSS blocks merchants from storing the CVV after authorization, so detection has to come from behavior, not from the three-digit value.
This guide covers the signals that show up in logs, the systems that score them, and the steps a risk team takes once an attack starts.
What is a CVV attack?
A CVV attack (card testing, or card enumeration) is an attempt to learn which stolen card numbers are live by pushing them through a payment form. Each attempt returns an authorization response, and the attacker sorts the results into working and dead cards. The CVV field matters because most gateways reject a transaction when the code fails to match.
Attackers move between stores. A merchant may see a few hundred attempts in one night, then nothing for weeks. That stop-start rhythm is why a single day of clean traffic proves nothing.
Why does card testing cost more than the orders lost?
Test transactions are small, so the direct revenue loss looks minor. The damage lands elsewhere. Each approved test can turn into a chargeback with fees attached, and a decline rate that climbs past a few percent invites scrutiny from the acquirer.
- Chargeback fees per disputed test order
- Higher processing costs or a reserve on the merchant account
- Fines from the card networks for excessive fraud ratios
- Lost sales when broad blocks catch real customers
Which signals reveal a CVV attack?
No single signal proves an attack. Detection improves when several weak signals line up in the same window.
- Small authorization amounts. Test transactions often sit between $0.00 and $1.00 because the attacker wants a cheap yes or no.
- Card velocity. One IP, device fingerprint, or account trying five or more card numbers in an hour.
- Shared data across cards. The same billing address, email, or phone number paired with different card numbers.
- Decline clusters. A checkout page that declines about 5% of orders in a normal week jumping to 40% or higher.
- Card number patterns. Sequences that share a bank identification number (BIN) or run in order.
- Checkout speed. Form fill times under two seconds, which no human produces.
- Disposable identity markers. Random-string emails, throwaway domains, and phone numbers in a country that does not match the IP.
- Network concentration. A large share of checkout traffic from one data center ASN, one VPN range, or one proxy pool.
How do detection systems spot the pattern?
Most risk stacks layer four methods and let each one cover the blind spots of the others.
Velocity and rule engines
Rules count events in a time window: cards per device, attempts per IP, declines per BIN. They are cheap to run and easy to explain to an auditor. Their weakness is that a slow attack stays under the threshold.
Device and network fingerprinting
Fingerprints tie attempts together even when the attacker rotates card numbers and email addresses. Look for mismatches between the device time zone, the IP geolocation, and the billing country.
Authorization response analysis
Issuer response codes carry useful detail. A run of CVV mismatch replies followed by one approval is the standard test-then-buy sequence. Visa and Mastercard both publish decline-code references that map to specific failure reasons.
Machine learning scoring
Models trained on past fraud label each session with a risk score. They catch attacks that rules miss, but they need labeled data and monitoring, since fraud patterns shift.
What should you track on a dashboard?
Pick a handful of numbers and chart them over time. Trends tell you more than any single reading.
- Authorization rate by hour, split by card BIN
- Decline reasons, with CVV mismatch separated from insufficient funds
- Cards attempted per device and per IP
- Share of orders under $1.00
- Checkout sessions per account in a rolling 24 hours
- Block rate next to false positive rate
Alert on rate of change, not on absolute values alone. A store that handles 10,000 orders a day and a store that handles 50 need different thresholds for the same pattern.
How do you respond when detection fires?
- Raise the risk threshold for the affected BINs, ASNs, and device IDs.
- Require 3D Secure for sessions that score above the new cutoff.
- Block the source ranges behind the burst, then watch for the attack to move.
- Send the acquirer timestamps and response codes so they can flag the account.
- Review false positives the next day and loosen any rule that caught real customers.
What mistakes weaken detection?
Storing CVV values to check them later breaks PCI DSS and creates a breach target. Turning off decline logging hides the exact data you need to spot a test run. Blocking by country alone pushes attackers to residential proxies and leaves the pattern intact.
A blocked attack is not the end of the story. Attackers retry with new infrastructure, so the rules need a review every few weeks.
FAQ
Does a CVV mismatch always mean fraud?
No. Typos and freshly issued cards cause legitimate mismatches. The signal matters when mismatches cluster on one device or arrive faster than a person can type.
How fast should detection act?
Seconds matter. Test batches can finish in minutes, and each approved test becomes a chargeback candidate later. Manual review runs too slow for this job, so rules and scoring do the first pass.
Can a small store run CVV attack detection without a fraud vendor?
Yes, within limits. Velocity rules, decline monitoring, and 3D Secure cover the common cases. A store that ships physical goods can also hold fulfillment on high-risk orders until the payment settles.