CVV attempt monitoring is the practice of logging every authorization where the CVV or CVC check fails, then reading those failures as a pattern across cards, devices, and IP addresses instead of judging one order at a time. One mismatch is a typo. Fifteen mismatches across fifteen different cards from the same session in ten minutes is somebody testing a stolen list. Volume, timing, and the number of distinct cards behind one fingerprint separate the two.
What a CVV attempt looks like in your logs
The authorization response carries a CVV result field that is separate from the approved or declined flag. Visa returns CVV2 codes such as M for match, N for no match, P for not processed, S for should have been present, and U for issuer unable to verify. Mastercard's CVC2 field follows the same shape. Stripe exposes the same idea as a verification check with values like pass, fail, unavailable, and unchecked.
Pull that field out of the response and store it. A decline labeled CVV mismatch and a decline labeled insufficient funds are different animals. Bundle them into one decline rate and the signal you wanted disappears.
Why failed attempts matter more than approvals
Card testing is cheap and loud. Someone buys a list, runs small authorizations to learn which numbers are alive, and then keeps or resells the survivors. Those probe attempts mostly fail. If you only watch successful transactions, you learn nothing until fraud chargebacks land weeks later, the BIN is burned, and your acquirer starts asking why your fraud rate tripled.
Failed CVV checks are the earliest visible trace of that run. They show up while the attacker is still guessing.
The metrics I watch
- CVV failures per card BIN per hour. A sudden spike on one six-digit prefix is the classic enumeration tell.
- Distinct card numbers with a CVV failure behind one device fingerprint. Five or more in an hour deserves a look.
- Distinct card numbers per IP or ASN in a short window, especially cloud hosting ranges.
- Ratio of CVV failures to CVV matches per session. Clean shoppers sit near zero. Testers run high.
- Ticket size clustering. Probes are often small, round, and repeated.
- Time gaps between attempts. Human checkout has pauses. Scripts do not.
Rules that hold up in practice
- Block outright when one device or IP produces more than three CVV failures on distinct cards within ten minutes.
- Require 3D Secure step-up when a CVV failure is paired with a new device and a mismatched billing address.
- Freeze the whole BIN range for an hour if failure counts cross a threshold you set from your own baseline, not from a vendor blog post.
- Alert, do not block, on a single CVV failure from a returning customer with a clean history. People fat-finger the code.
What to do when a run shows up
Block the source, then write it down. Send the timestamps, BINs, and device data to your acquirer and your gateway. Most acquiring banks have a fraud desk that wants to know, and reporting a card testing wave early protects your account when the chargebacks arrive later. Turning on 3D Secure for the affected traffic segment buys time while you tune rules.
Mistakes worth avoiding
Watching only declines instead of CVV-specific results is the big one. Ignoring P and U codes is the second. Those mean the check never ran, so they neither clear a customer nor prove a card is bad, yet people count them as passes. Not joining the result code to device and IP data is the third. A CVV failure with no context is noise.
Storage and compliance
You monitor the result, not the value. PCI DSS forbids retaining the CVV itself after authorization, so keep the outcome code and the surrounding metadata, never the three digits. Retain the logs long enough to match a chargeback, and keep card data out of whatever table your analysts read.