The short answer
If you sell online and you are comparing services that touch card verification values, pick the option that keeps the CVV out of your own systems. That means a hosted payment page or tokenization service from a PCI DSS Level 1 provider, paired with 3-D Secure step-up authentication for high-risk orders. Price, dashboard design and reporting matter, but they come after that one requirement. Any service that offers to store CVVs for you, or that trades in card data, is not a shortcut. Selling or buying card verification values is carding, and it is a crime in the US and in most other jurisdictions. The guidance below treats this as a merchant-side buying decision: which protection stack to choose so that CVV data never becomes a liability on your balance sheet.
What to look for
- Hosted fields or a full redirect checkout, so the CVV is entered in the provider's frame and never hits your servers or logs.
- Tokenization that replaces the card number and CVV with a token you can reuse for refunds and subscriptions without holding the original value.
- PCI DSS Level 1 attestation from the payment provider, plus a clear statement of which SAQ you qualify for.
- 3-D Secure 2 support with risk-based exemption logic, so low-risk buyers skip the challenge.
- Address Verification System and CVV result codes exposed in your reporting, so you can build rules on mismatch outcomes.
- Chargeback and fraud tooling in the same contract, since card-not-present fraud rarely shows up as a single problem.
- Written data-retention terms naming CVV explicitly, with a deletion schedule you can audit.
Parameter bands worth checking
Use these ranges to compare proposals side by side. Numbers shift by acquirer and region, so treat them as screening questions rather than fixed limits.
- Monthly card-not-present volume: under 5,000 transactions, 5,000 to 50,000, and above 50,000. Onboarding scrutiny and pricing tiers usually change at each step.
- Chargeback ratio: keep it under 0.9 percent of transactions and under 100 chargebacks in a month, the levels Visa uses in its dispute monitoring programs.
- Authentication coverage: aim for 3-D Secure on 60 to 100 percent of card-not-present orders in the first year, with exemptions for trusted repeat buyers.
- Retention window for authorisation logs: 90 to 180 days is common, and no configuration should retain the CVV itself after authorisation.
- Fraud review queue: a manual review rate of 1 to 3 percent of orders keeps staffing sane while catching the noisy cases.
Common pitfalls
- Assuming a plugin handles compliance. The plugin may pass data through your server, which pulls you into a heavier PCI scope than the marketing page suggests.
- Storing CVV results in the order notes. Result codes are fine; the value itself is not, and support staff should never ask for it by email or chat.
- Buying on price alone. A cheaper gateway that stores card data or lacks tokenization shifts the cost to breach response and fines.
- Ignoring refunds and chargeback workflows. If the token cannot support a partial refund, your team will end up handling raw card numbers again.
- Treating 3-D Secure as a silver bullet. It shifts liability on some transactions, but it does not stop friendly fraud or account takeover.
FAQ
Can my store save a customer's CVV for faster checkout?
No. PCI DSS forbids storing the card verification value after authorisation, in any form, even encrypted. Use tokenization if you want repeat purchases to be one click.
What does the search term "CVV shop" actually refer to?
It is used in two ways. Legitimate merchants use it loosely when discussing checkout and payment tooling. Criminal forums use it for marketplaces that trade stolen card data. This guide covers only the first meaning, and no legitimate provider sells CVVs.
Is a hosted checkout enough on its own?
It removes the CVV from your environment, which is the biggest single win. Add authentication, address verification rules and chargeback monitoring to cover the rest of the card-not-present risk.
How do I compare two providers with similar features?
Ask each one for the SAQ you would file, the exact fields they return to your systems, and a sample refund flow. The answers expose scope differences that feature lists hide.