CVV Attack Defense Techniques for Merchants

The Short Answer

A CVV attack is an automated run of authorization attempts that tests stolen card numbers against a merchant's payment form by guessing the card verification value. Defense rests on four layers: verify the CVV on every authorization, throttle repeat attempts by card, IP, device, and email, challenge suspicious traffic with 3-D Secure or a bot check, and monitor authorization logs for the decline patterns these runs produce. No single control stops an enumeration attack on its own. Stacked controls do.

How the Attack Shows Up in Your Data

Card testing runs leave a signature. You see a burst of authorizations from a small set of IP addresses or devices, many with mismatched CVV or AVS responses, small order values, sequential or near-sequential card numbers, and a high decline rate on one payment gateway. The attackers are not trying to buy anything. They are checking which cards still work before they resell them or use them elsewhere. That is why the first order in a run can succeed and the next hundred fail.

Prerequisites

• Gateway access with CVV and AVS response codes visible in your transaction log
• Rule tools for velocity limits, blocklists, and custom decline logic
• A fraud scoring service if you process meaningful card-not-present volume
• An owner for alerts, with authority to block traffic during an active run

Defense Techniques

1. Turn on CVV verification in your gateway and send the value with every authorization request. A merchant that skips the check gives up the strongest single signal available.
2. Set your rule engine to decline on a CVV mismatch, response code N, and route not-processed responses, code U, into a review queue. Issuers that return U do not support the check, so treat those transactions as higher risk.
3. Pair CVV with address verification. A mismatch on both the CVV and the street address is a strong fraud signal and a common basis for a decline rule.
4. Apply 3-D Secure to transactions above your risk threshold or from new devices. The added authentication step stops most automated runs because bots cannot pass the issuer challenge.
5. Cap attempts per card, per IP, per device fingerprint, and per email address inside a rolling window. A limit of three to five failed attempts per hour on a single card blocks guessing without harming real shoppers.
6. Block or flag traffic from data centers, proxies, and known bot networks. Residential proxies are harder to catch, so combine IP rules with device and behavioral signals.
7. Add a CAPTCHA or a lightweight bot challenge to the payment step when a session shows no browsing history, an empty cart path, or a direct POST to the checkout endpoint.
8. Set a minimum order value. Many runs test cards with one-dollar charges, and a floor removes the cheapest path to validation.
9. Score transactions with a fraud tool that learns from your own chargeback data, then write rules from its output rather than from intuition alone.
10. Alert on volume spikes in your authorization log. A jump in declined attempts from one BIN or one subnet is the earliest sign of an active run.
11. Never store the CVV after authorization. PCI DSS requirement 3.2.1 forbids retaining sensitive authentication data, and a breach that exposes stored CVVs multiplies your liability.
12. Report confirmed enumeration activity to your acquirer and the card networks. They run their own detection programs and can act on the source.

Signals Worth Watching

• Decline rate by BIN, IP, and device over a one-hour window
• Ratio of authorization attempts to completed checkouts
• Count of distinct cards used from one IP or device
• Share of orders under your minimum threshold

After an Active Attack

1. Block the source IPs, subnets, and device fingerprints in your gateway.
2. Void or refund any orders that slipped through during the run.
3. Raise your velocity limits for 24 to 48 hours, then relax them once traffic returns to normal.
4. File a report with your acquirer and keep the logs for the full chargeback window.
5. Review which control failed first and close that gap before the next run.