CVV Attack Defense Measures: Stop Card Testing Fraud

A CVV attack is a burst of authorization attempts that test guessed card verification values against stolen card numbers. The attacker already holds a working card number and expiration date, usually from a breach or a purchased dump, and needs the 3 or 4 digit verification code to complete a card not present purchase. The defense is to make guessing expensive: cap how many times a code can be tried, track velocity across card, IP, device, and email, and force step up authentication when a pattern looks like a script rather than a shopper.

Why the attack works

The CVV space is small. A 3 digit code gives 1,000 possible values, and a motivated operator spreads attempts across many merchants, so no single store sees the full run. Many gateway setups decline a bad code but keep the card number live, which lets the attacker return with another guess. Without a retry cap, a script can grind through a card in minutes.

Prerequisites

• Access to your gateway or processor risk settings, including retry and velocity controls.
• AVS and CVV response codes flowing into your order records.
• Order logs that capture IP address, device identifier, email, and phone.
• A named person who reviews fraud alerts each business day.

Defense measures, in order of impact

1. Set a hard retry cap per card number on your merchant account, commonly three attempts, then block that card from further authorization requests.
2. Enforce a per IP ceiling on failed authorization attempts, such as five in an hour, and reject requests past the ceiling.
3. Require a full billing address and postal code on every order, and decline when AVS returns no match on the street number or ZIP.
4. Turn on 3-D Secure for first time customers and for any order your rules score as elevated risk, so the issuer authenticates the cardholder.
5. Cap order attempts per email address, phone number, and shipping address over a rolling 24 hours.
6. Insert a challenge page after the second failed attempt on the same session, which breaks most scripts.
7. Log every decline with the response code, the card BIN, the IP, and the device fingerprint.
8. Alert on spikes in the specific decline codes that mean bad CVV or failed AVS, since those spikes mark card testing.
9. Block the source ranges, device identifiers, and email domains tied to a confirmed testing run, then recheck your caps.

Signals that you are under attack

• Hundreds of small dollar orders or authorization attempts in a short window.
• Many different card numbers from one IP range or one device fingerprint.
• A high ratio of CVV mismatch declines to approvals.
• Orders that ship to an address unrelated to the billing record.

What not to do

Do not store the CVV or CVV2 value after authorization, and do not write it into order notes, tickets, or exports. Do not weaken your retry cap to reduce false declines without adding another control, such as 3-D Secure or address verification, in its place. Review caps each quarter, because fraud tools that work now will drift as attackers adapt.