How to Mitigate a CVV Attack: Merchant Fraud Guide

How to mitigate a CVV attack

A CVV attack is card testing. Someone scripts your payment form and fires hundreds or thousands of submissions at it, either many card numbers with one guess each or one card number with many three-digit guesses. The point is to find combinations that authorize, then use or resell those cards. You mitigate it by making each guess cost the attacker something: time, a challenge, or a dead card.

The short version: rate limit by IP, card fingerprint, and device; require CVV and address verification on every order; kill the session after a small number of declines; add a challenge when velocity spikes; and watch your authorization rate for the pattern while it is happening.

Know the pattern you are looking for

Test traffic rarely looks like shopping. It shows up as a burst of small orders from one IP or one subnet, often at odd hours. You will see many declines on the same card, or many different cards drawn from the same BIN range. Checkout times come in at two or three seconds with no browsing before them. Email addresses look generated, or one address shows up across dozens of cards. The clearest signal is a jump in authorization requests paired with a falling approval rate.

Put hard limits on velocity

• Cap attempts per IP per minute and per hour. Count declines, not just approvals, or you will miss the whole attack.
• Throttle per card number and per device fingerprint as well. Attackers rotate IPs faster than they rotate devices.
• Slow down specific BINs. Testers usually work one range at a time, so a temporary limit on that BIN buys you hours.
• Set a global ceiling on payment attempts your gateway accepts in a rolling window, so a flood never reaches the processor.
• Return a generic failure message. Do not tell the attacker whether the number, the expiry, or the CVV was the problem.

Require the checks that are expensive to fake

Make CVV and AVS mandatory on every transaction, including repeat customers. Stolen card numbers often come without the printed code, so a hard CVV requirement removes a large slice of viable test cards before any money moves. Decline mismatches instead of flagging them for review; a review queue is exactly what an attacker wants to fill.

3-D Secure adds a bank-side step. It raises cost per attempt and shifts liability on covered transactions. For high-risk categories or known carding targets, forcing it on first-time buyers is a reasonable trade.

Add friction where it is cheap for you

You do not need a challenge on every order. Trigger one when behavior looks automated: first order from a new device, mismatched billing and shipping country, disposable email domains, or any session that hits the velocity cap. A challenge served at that moment stops scripts cold while leaving normal buyers alone.

Watch, alert, and respond

Build a dashboard for authorization rate, decline rate by BIN, and attempts per minute. Set alerts at thresholds you can act on. When an attack starts, the first moves are tightening the rate limit, blocking the offending ASNs and proxies, and notifying your processor so they can filter upstream. Keep a written runbook, because the decision has to be made in minutes, not next week.

Keep CVV out of your systems

PCI DSS forbids storing the CVV or CVC after authorization, even encrypted. If your logs, support tools, or order database ever hold that value, you have turned a payment page problem into a breach problem. Tokenize the card through your processor and let the sensitive data stay outside your scope.