CVV Attempt Monitoring: How Card Testing Gets Caught

CVV attempt monitoring is the practice of logging every card verification value check a payment system handles, then flagging the patterns that look like guessing. It targets card testing, the step where someone holding a list of card numbers tries to find which ones still work. Done well, it stops fraud before a stolen number turns into a paid order.

Why do fraudsters need so many CVV attempts?

Card numbers leak in bulk. The three- or four-digit code on the card does not, because PCI rules bar merchants from storing it after authorization. So a bulk list of numbers arrives with a gap, and the person holding it has to guess or buy the codes from a second source.

Guessing is cheap to try and hard to hide. A card has 1,000 possible three-digit codes, and attackers spread attempts across merchants, IP addresses, and small amounts to stay under per-site limits. Each failed check leaves a record. That record is what monitoring systems read.

How does card testing look in CVV attempt logs?

Card testing has a shape. Single cards draw repeated checks in a short window, and one device or IP address touches far more cards than a real shopper would in a day.

• Several authorization attempts on the same card within minutes, often across different merchants.
• Card numbers that climb in sequence, which points to a generated BIN range.
• Dozens of cards tried from one IP address, device fingerprint, or shipping address.
• Small order values, often under a dollar, chosen to keep the hold cheap.
• High decline rates followed by a single approval, the classic hit.
• A billing country on the card that does not match the IP location.

No single signal proves fraud. Two or three together, inside a short window, is a strong reason to step up verification or block.

What does a monitoring system measure?

Monitoring counts attempts, not just outcomes. A decline is data. So is the response code, the time between tries, and the amount tested.

• Attempt velocity per card number and per BIN range.
• Attempt velocity per device, IP, email, and shipping address.
• Ratio of CVV mismatches to approvals on the same account.
• Response codes grouped by issuer, to see which banks are being probed.
• Time gaps between attempts, since scripts retry on a fixed interval.

Thresholds should come from your own baseline. A store selling $5 items sees different normal traffic than one selling furniture. Set the limit above real customer behavior and below script behavior.

How do you build CVV attempt monitoring for a store?

1. Log every authorization request and response with the full reason code, the card BIN, the amount, and the device identifier.
2. Group attempts by card, BIN, device, and IP, then set a ceiling for each group over a 10-minute and a 24-hour window.
3. Send traffic near the ceiling to step-up authentication such as 3-D Secure, which shifts liability and forces a cardholder challenge.
4. Block once a card fails the code check several times, and flag the device that sent it.
5. Feed confirmed fraud cases back into the rules. A fixed rule set ages fast.

Issuers run a parallel process. Card networks track failed verification attempts at the card level, and a card that fails too often can be blocked or reissued by the bank. That helps the cardholder, but it does nothing for a merchant already hit with chargebacks.

What are the limits of CVV attempt monitoring?

Monitoring reads patterns, and patterns can be diluted. A botnet with thousands of residential IPs can send one attempt per address and stay invisible to per-IP rules.

False positives cost money too. A shared corporate card, a customer who mistypes the code twice, or a family using one device can trip a rule built for scripts. Keep a manual review path for blocked orders that look real.

The bigger gap sits outside the merchant. If a breach captures the code along with the number (skimming devices and some malware do this), the check passes. Monitoring cannot catch a correct code used by the wrong person. Address verification, device history, and velocity rules carry that load.

Which metrics should you watch each week?

• CVV mismatch rate by BIN, to spot a probed range.
• Cards attempted per device, and how many of those were first-time cards.
• Share of orders under $1 that ship to a new address.
• Chargeback rate split by card verification result.
• Blocked attempts that converted after review, a sign your thresholds are too tight.

FAQ

How many CVV attempts are too many?

Two failed checks on one card within an hour is worth a closer look. Four or more from the same device is a block in most rule sets. Use your own order data to set the line.

Does CVV monitoring stop chargebacks?

It cuts the number of fraudulent approvals, which cuts chargebacks. It does not remove liability on a transaction where the code matched but the buyer was not the cardholder.

Can you store the CVV to compare later?

No. PCI DSS prohibits storing the code after authorization. Monitoring works on the authorization response, not on the number itself.

Is card testing the same as account takeover?

No. Card testing validates stolen numbers. Account takeover uses stolen logins. The two often meet, since a validated card funds purchases made through a hijacked account.