Answer

A CVV attack is a run of authorization attempts that guess the card verification value for a card number. The CVV is 3 digits for Visa, Mastercard, and Discover, and 4 digits for American Express. One card number has up to 1,000 CVV combinations, so an attacker can walk the full range against a merchant that places no limit on attempts. Mitigation rests on four controls: attempt caps per card number, velocity limits per device and IP, 3-D Secure step-up, and decline-rule tuning with monitoring.

How the attack shows up in your data

Card testing looks like a decline spike, not a sales spike. Watch for these signals:

• Rise in declined authorizations with CVV mismatch response codes.
• Many card numbers tried from one device fingerprint or IP range.
• Many declines on a single card number across a short window.
• Small order values, guest checkout, and mismatched billing address data.
• Email domains that expire or addresses with random strings.
• Authorization rate drop of a few points against baseline.

Controls that work

1. Per-card attempt caps. Count CVV failures per card number and block the card after 3 failures in 24 hours. Key the counter to a hash of the card number, not the number itself.
2. Velocity limits. Set ceilings on attempts per IP, per device fingerprint, per BIN, and per email in a rolling window.
3. 3-D Secure. Step up to 3DS2 after a failed attempt. Issuer challenges stop most runs built on stolen data, and liability shifts on authenticated transactions.
4. Address verification. Score AVS results with the CVV result. A CVV match with an AVS fail is a weaker signal than both matching.
5. Processor decline rules. Ask your acquirer for rules on CVV mismatch counts and BIN attack patterns. Review reason codes each week.
6. Checkout friction. Add CAPTCHA or a challenge page after the first failure. Set a minimum order value. Restrict guest checkout for high-risk BINs.
7. Acquirer alerts. Card networks and processors notify merchants about card testing on their accounts. Route those alerts to a named owner.

What does not work

• Removing or hiding the CVV field. Card-not-present authorization needs it.
• Blocking one IP address. Attackers rotate source addresses and devices.
• Storing the CVV to compare later. PCI DSS forbids retention of sensitive authentication data after authorization.
• Relying on the CVV alone. It is one signal among several.

Measurement

Track three numbers: CVV mismatch decline rate, attempts per card number per day, and the ratio of declines to completed orders. Set an alert threshold at twice the 30-day baseline. Report card testing to your acquirer and keep the case number. Sustained attack traffic can damage authorization rates on the whole account, so treat a two-day decline spike as an incident.