CVV Attack Detection: Spot Card Testing on Your Checkout

CVV attack detection in short

CVV attack detection is the practice of spotting automated attempts to test stolen card numbers and their card verification values against a live checkout. A CVV attack, often called card testing or carding, shows up as a burst of authorization requests in a short window. Most of those requests fail, a small number succeed, and the successful cards get used for real purchases later. Detection works by logging every authorization attempt, grouping attempts that share an IP address, device, or card BIN, and alerting when decline volume breaks the baseline for your store.

What a CVV attack looks like

• A high volume of low-value orders in minutes instead of hours.
• Many declines from one IP address or one device fingerprint.
• Card numbers that share a bank identification number and run in sequence.
• Billing address and ZIP mismatches paired with CVV no-match responses.
• Cheap items, digital goods, or donations used as the test target.
• Email addresses on disposable domains, or a fresh account for every attempt.

Prerequisites

• Gateway access with transaction-level reporting.
• CVV and AVS checks set as required fields, not optional ones.
• Log retention covering at least 90 days of authorization data.
• A rule engine, fraud tool, or scripting access to your transaction logs.

How to detect a CVV attack

1. Turn on CVV and AVS verification for every card-not-present transaction in your gateway settings.
2. Record the full result of each attempt: CVV response code, AVS response code, card BIN, last four digits, amount, IP address, device fingerprint, email, and timestamp.
3. Calculate your normal decline rate per day and per card brand across the past 90 days to establish a baseline.
4. Set an alert threshold at two to three times that baseline decline rate for any one-hour window.
5. Build a velocity rule that flags any IP address, device, or email producing more than five authorization attempts in an hour.
6. Group flagged attempts by card BIN and check whether the last four digits appear in sequence.
7. Match flagged sessions against your internal blocklist of known fraudulent IPs, emails, and device IDs.
8. Add a challenge step, such as a CAPTCHA or a 3-D Secure prompt, for any session that trips a rule.
9. Review CVV response codes on flagged sessions. A high share of no-match results paired with small order values points to testing rather than a customer typo.
10. Suspend the accounts, emails, and IPs tied to confirmed testing, and void any authorization that was approved.
11. Tune the rules every two weeks so repeat customers and gift buyers do not get blocked.
12. Record the incident window and the affected card range, then send the report to your acquirer.

Response actions after detection

Blocking the session is only half the job. Refund or void every authorization tied to the attack so settle­ment never posts. Force password resets on any customer account that was created or touched during the window. Notify your processor fraud desk with the timestamps and card BINs you captured. If the attack produced chargebacks, file a report with the FBI Internet Crime Complaint Center and keep the case number with your incident file.

Why you cannot store CVV data

PCI DSS classifies the CVV as sensitive authentication data. Merchants may not store it after authorization, including in encrypted form. Detection therefore has to run on the response code your processor returns, not on the CVV value itself. Keep the result code, discard the value, and build your rules around behavior instead of card data.