CVV Test Values for PCI DSS: Guide for Test Cards
CVV test values are fake codes used with test card numbers in sandboxes. PCI DSS bans CVV storage after authorization. Processors publish the values.
A CVV attack is a card testing run in which someone submits batches of card numbers with security codes to a payment page to learn which ones authorize. CVV attack defense means spotting that pattern in your authorization data and cutting it off before it burns your approval rate and buries real orders. Verifying the security code on its own does not stop the attack.
A CVV attack targets the 3-digit card verification value printed on the back of most cards (4 digits on the front of American Express). Attackers pair card records from breach dumps with matching security codes and push them through merchant checkout forms or payment gateways.
Each attempt costs almost nothing. Approvals tell the attacker which records are live, and those records get resold on underground markets as verified data. That is why the attacker keeps going after a wall of declines.
A BIN attack generates card numbers from a known bank identification number with no real account data behind them, then tests the results. A CVV attack starts with stolen card records and checks the security code against the issuer.
Both fall under the umbrella of card testing. The distinction matters for detection because the traffic signatures differ: BIN attacks show long runs of one BIN prefix, while CVV attacks show many unrelated cards hitting the same device or IP.
None of these signals proves fraud alone. Three or four of them inside one hour on the same infrastructure is a strong tell.
When a breach exposes full card data, the security code comes with it. A matching CVV proves the code is correct, not that the person typing it owns the card. Fraud teams that lean on the CVV check alone still approve stolen-card orders.
Add checks that measure the person instead of the number: device reputation, IP history, account age, order consistency, and issuer authentication.
Count authorization attempts per IP, per device, per email, and per BIN. Block or challenge once a threshold trips inside a 10-minute or 1-hour window. Attackers rotate cards but reuse infrastructure, so per-device limits catch them when per-card limits fail.
EMV 3-D Secure asks the issuer to authenticate the cardholder during checkout. A failed challenge kills the test transaction, and a passed challenge shifts chargeback liability to the issuer. You can run it on all orders or step it up when your risk score rises.
Card testing is automated, so a challenge on the pay button removes most of it. Rate-limit the payment endpoint itself, not just the product page. Attackers who script the API never touch your storefront.
A healthy gateway sees declines spread across many issuers. A spike on one BIN within one hour is the clearest signal of an enumeration run. Alert on that ratio and cap it before it reaches your acquirer's monitoring threshold.
Most card testing traffic comes from data center IPs and anonymizing proxies rather than residential connections. Blocking those ranges cuts volume without touching most real customers.
Acquirers track your decline and chargeback ratios and can flag or close an account. Report an attack while it happens. The record you keep shapes how they treat you afterward.
Keep the block in place for a few days after the traffic stops. Attackers who found live cards come back to test the same merchant.
Failed authorizations can carry per-attempt fees, and each fraudulent approval brings a chargeback plus the acquirer's chargeback fee. A high decline rate can push a store into a card network monitoring program with fines and remediation deadlines.
There is also the labor. Analysts spend hours sorting real orders from test orders while chargeback clocks run. Small stores rarely have spare hands for that.
Cardholders who catch a test charge early often stop the larger fraudulent purchase that follows it.
Yes. Attackers prefer merchants with weak controls and simple checkout flows, and smaller stores often lack a dedicated fraud team. Low order volume also hides the attack from anyone who is not watching decline ratios.
No. PCI DSS prohibits storing the CVV or full track data after authorization. Keeping it creates breach liability that outweighs any convenience at checkout.
A single script can push thousands of attempts in an hour. Without a rate limit, most merchants learn about it from the acquirer rather than from their own order log.
No. It confirms the code matches the account, not that the buyer is the cardholder. Pair it with 3-D Secure, velocity rules, and device checks for real coverage.
CVV test values are fake codes used with test card numbers in sandboxes. PCI DSS bans CVV storage after authorization. Processors publish the values.
Learn how to conduct a CVV test for compliance when selling CVVs online.
How to test CVV verification safely in your own checkout, why the code is never stored, and how to spot card-testing attacks against your store.
Learn how to effectively use a CVV test to detect fraud in online transactions and protect your business. This guide provides essential steps and best practices for implementing CVV tests.
Stay informed on the risks of a CVV attack and how to protect your personal information online.
Learn how to identify and defend against CVV attacks with this comprehensive guide.
Learn about the CVV attack pattern and how to protect your online transactions.
Learn how to effectively analyze CVV attack logs and protect your online marketplace.
CVV attack IOCs explained: enumeration patterns in web logs, gateway signals, client fingerprints, and a triage order for fraud teams.