CVV Attack Mitigation Guide: Stop Card Testing

What a CVV attack is

A CVV attack is a scripted attempt to confirm that stolen card numbers are live. The attacker submits many small transactions across a merchant checkout, guessing the three or four digit verification code for each card. A mismatch means the card data is stale or wrong. A match, or even a specific decline response, tells the attacker the number is worth keeping. The goal is not to buy goods. The goal is to sort a list of card numbers into working and dead records.

cvv attack mitigation guide

Merchants see the damage in authorization fees, chargeback risk, processor penalties, and a checkout that slows down for real customers. The same traffic pattern also shows up before a larger fraud run, so treating it as a nuisance is a mistake.

cvv attack mitigation process

Prerequisites

• Access to gateway logs, including response codes, timestamps, IP addresses, and device fingerprints
• Permission to edit fraud rules and checkout configuration in your payment stack
• A named contact at your acquirer or payment processor for escalation
• A baseline of your normal authorization volume by hour and by country

Mitigation steps

1. Confirm the attack. Look for a sharp rise in authorization attempts, high decline rates, many distinct card numbers from one IP or device, repeated low dollar amounts, and traffic from datacenter ranges rather than residential networks.
2. Turn on CVV verification and set mismatches to decline, not review. Pair it with address verification service checks so a single matching field is not enough to approve.
3. Rate limit the checkout endpoint. Cap attempts per IP, per session, per device fingerprint, and per card BIN within a rolling window.
4. Add velocity rules. Block or challenge when one card is tried more than a set number of times per hour, or when one email or phone number is reused across many cards.
5. Insert a challenge on suspicious sessions. A CAPTCHA or a short verification step raises the cost of automation and rarely affects normal buyers.
6. Block or slow known bad sources. Deny traffic from proxy services, hosting providers, and ASNs with no customer base in your market.
7. Require 3-D Secure for high-risk orders. Step-up authentication shifts liability and stops most scripted attempts before authorization.
8. Tune thresholds weekly. Track false positives and loosen any rule that rejects legitimate repeat customers.
9. Preserve evidence. Keep full request logs, rule changes, and timestamps in case your acquirer or card network asks for a report.
10. Report the incident. Notify your processor and follow their instructions on blocking compromised card ranges.

Ongoing monitoring

Set alerts on decline rate per hour, unique cards per IP, and the ratio of failed to successful authorizations. Review the alerts each business day. Attackers rotate infrastructure, so a rule that works this month may need new thresholds next month. Keep a short written record of every rule change and the reason for it.

cvv attack mitigation details

What not to do

• Do not store the CVV, CVC, or CID after authorization. PCI DSS forbids retaining this data in any form.
• Do not rely on a single control. Rate limits alone fail against distributed botnets.
• Do not approve transactions just to keep the decline rate low. That converts a cheap attack into chargebacks.