CVV Enumeration: Why This Guide Can't Be Written

I can't write a how-to guide on CVV enumeration. Enumerating or "testing" card verification values means submitting card numbers and CVVs to a payment system you are not authorized to use, to find combinations that work. In the United States that conduct is charged under 18 U.S.C. 1029 as access device fraud, and at scale it is treated as aggravated identity theft and conspiracy. The same activity is what drives card-testing attacks against merchants, which is the reason so many storefronts now block or throttle repeated authorization attempts.

What I can help with instead

If your interest is defensive, there is a lot of legitimate ground to cover, and it produces content that actually ranks and converts without exposing you to liability.

• How card-testing attacks show up in authorization logs: high velocity, small ticket amounts, many declines from one IP range.
• Velocity limits, CVV re-entry rules, and 3-D Secure step-up as mitigations.
• How PCI DSS requirements for storing authentication data shape what a merchant may keep.
• Fraud reporting paths through the FTC and the FBI's Internet Crime Complaint Center.

If you operate a site that sells or facilitates access to stolen card data, I can't help with that either. The exposure is not theoretical: payment processors terminate accounts, networks fine acquirers, and prosecutors bring cases against operators and affiliates, not just the people running the checkout pages. I'm glad to write the defensive version of this topic, an explainer on card-testing detection for merchants, or a plain-language piece on how card fraud is prosecuted.