CVV attack defense means treating every CVV retry as a risk signal, not a customer convenience. The core control is simple: never store the CVV, cap failed CVV attempts per card and per session, and route suspicious retries to step-up authentication or manual review. Add velocity checks across IP, device, email, and BIN, then review small authorization failures in bursts. No single rule stops card testing. Layered controls do.
What CVV attacks look like
A CVV attack is card testing with the card verification value as the target. An attacker submits stolen card numbers with guessed or purchased CVV values across many low-value orders. The goal is to find cards that authorize before using them for larger fraud. Common signs include many cards from one device, repeated failed CVV results, new email addresses, mismatched billing data, and short bursts of checkout attempts.
What to look for in a defense stack
- CVV non-storage and tokenization: confirm that CVV is used for one authorization and never written to logs, databases, or support notes.
- Retry controls: keep separate counters for card, session, device, IP, and account. Reset counters only after successful 3DS or verified cardholder action.
- Velocity and BIN monitoring: track failed CVV attempts by BIN range, issuer country, and merchant endpoint. Watch for many cards from one device.
- Step-up authentication: trigger 3DS or an issuer challenge after a small number of CVV failures, not after ten.
- Address and identity checks: pair AVS and CVV results with device fingerprint, email age, and shipping consistency.
- Alerting and case review: queue bursts of failed CVV attempts for review within the same day.
Parameter bands to start with
- Per card: 3 to 5 failed CVV attempts per hour before block or step-up. Lower to 2 for high-risk BINs.
- Per session: 1 to 3 CVV failures before challenge. Do not let one session cycle through many cards.
- Per IP or device: 10 to 20 failed CVV attempts per hour as a starting review band. Adjust to your traffic baseline.
- Per account: 2 to 4 failed CVV attempts per day before manual review, especially if email or device is new.
- Burst detection: 5 or more failed CVV attempts from one device within 10 minutes should open a case, not only a block.
Pitfalls that weaken CVV defense
- Storing CVV for customer support or recurring billing. This violates card data rules and turns a breach into a crisis.
- Counting only IP address. Attackers rotate proxies. Use device, session, card BIN, email, and behavior.
- Setting one global retry limit. High-value and low-value transactions need different thresholds.
- Ignoring successful small charges. Card testing often starts with low-value authorizations that pass.
- Blocking without review. Silent blocks hide attack volume and leave fraud rings active on other endpoints.
FAQ
Does CVV verification stop card testing?
No. CVV checks raise the cost of an attack, but stolen card data often includes the CVV. Use CVV checks with velocity, device, and issuer authentication controls.
Can I store CVV if it is encrypted?
No. PCI DSS prohibits retaining sensitive authentication data after authorization, even if encrypted. Use a payment token instead.
What is a good first rule for a small merchant?
Start with a per-card cap of 3 failed CVV attempts per hour, a per-session cap of 2 failures, and an alert for 5 failures from one device in 10 minutes. Review weekly and tune to your baseline.
How do I tell card testing from a forgetful customer?
Look at the pattern. One customer may mistype a CVV once. Card testing shows many cards, rapid retries, shared devices, and small amounts. Require step-up authentication when the pattern appears.