CVV Test for PCI DSS: Rules, Steps, and Common Findings
A CVV test for PCI DSS confirms your payment flow verifies the card verification value and never stores it. Steps, requirements, and common audit findings.
CVV Attack Pattern: Signals in Card Authorization Data
Definition
A CVV attack pattern is a series of payment authorization requests that tests card numbers against card verification values. The goal is to separate live accounts from dead ones. A test charge of $0.50 to $2.00 confirms the number, the expiry date, and the 3-digit or 4-digit code. The attacker then sells the data or runs a larger purchase. The test charge is not the profit.
Pattern 1: Low-value authorization bursts
Hundreds of requests arrive within minutes. Amounts sit between $0.10 and $3.00. Many share one merchant account or one payment gateway. The approval rate is low and the decline rate is high. A working card gets one small charge and then goes quiet, because the attacker moves it to a second stage.
Pattern 2: BIN attacks
An attacker takes one bank identification number and generates numbers in sequence. The first 6 to 8 digits stay fixed. The remaining digits change. Expiry dates come from a short guessed list. CVV values cycle through 000 to 999. This produces high volume against one issuer and one card range.
Pattern 3: CVV mismatch clusters
Issuers return a CVV result code with each authorization. A mismatch appears as an "N" or as decline code 05 in many gateway response maps. A cluster of mismatches on one merchant account over a short window points to enumeration with bad verification data. Normal mismatch rates sit in the low single-digit percentages at most merchants.
Pattern 4: Distributed sources
Requests arrive from many IP addresses, often residential proxies or cloud hosts in several countries. Device fingerprints repeat. The same email domain or the same shipping ZIP appears across separate cards. Session length is short. Cart size is identical across attempts.
Signals to monitor
- Authorization attempts per card per hour
- Ratio of attempts to approvals
- Average ticket size against the merchant baseline
- CVV and AVS response codes grouped by account
- Count of distinct cards per device or IP in 24 hours
- Share of attempts from new accounts with no history
Why CVV checks are the target
PCI DSS Requirement 3.2 bars storage of the card verification value after authorization. A merchant cannot keep the CVV2 and cannot compare a new attempt with an old one. The value passes to the issuer and then leaves the system. That rule protects cardholders. It also means a merchant cannot block a repeat attempt by matching a stored code, so throttling and velocity rules carry the load.
Controls that alter the pattern
- Require the CVV on every card-not-present transaction
- Set velocity caps per card, per device, and per IP
- Send high-risk requests to 3-D Secure
- Hold approval on a first attempt when the amount is below a floor and the account is new
- Track decline code 05 and CVV "N" rates by merchant ID
- Share test-card and proxy lists across acquirers
Legal status in the US
Sale or purchase of stolen card data is a crime under 18 U.S.C. 1029. Convictions carry fines and prison terms. Payment networks also fine acquirers for high fraud and chargeback ratios, which pushes the cost of test traffic back to the merchant account. Merchants that knowingly process test traffic risk loss of card acceptance.