A mock CVV is a fake card verification value that pairs with a test card number inside a payment sandbox. It mimics the three or four digit security code printed on a real card, but it validates only in test mode, and it exists so developers can simulate card payments without touching live cardholder data.
What a mock CVV is used for
Payment processors publish sets of test card numbers. Each one comes with a matching mock CVV, an expiry date, and often a postal code. When you run a transaction in sandbox mode, the gateway checks those values against its own test data instead of contacting a card network. That lets a team run hundreds of test payments without moving real money and without handling real card data.
Why test CVVs look like 123, 000, or 999
Test values are picked to be easy to type and easy to spot in logs. Many providers use 123, 000, or 999 as the default mock CVV for their standard test cards. Some go further and map specific values to specific outcomes, so one code forces a CVV mismatch and another returns a generic authorization failure. That behavior is what makes a mock CVV useful for testing error handling rather than only happy paths.
Mock CVV compared with a real CVV
- Source: a mock CVV comes from a vendor's public test documentation. A real CVV comes from the card itself.
- Validity: a mock CVV is accepted only by a sandbox or test endpoint. A real CVV is checked by the issuer during authorization.
- Storage rules: real verification values must not be stored after authorization under PCI DSS. Test values carry no such sensitivity.
- Consequences: a mock CVV in live mode simply fails. Someone else's real card data is fraud.
Where accurate test card data comes from
Pull test numbers from the documentation of the processor you actually integrate. Stripe, Adyen, Braintree, and most large gateways each publish their own test cards with matching values. Numbers from one provider often fail on another, because the test logic lives in the gateway, not on a card network. Random "cvv generator" pages and shops that advertise a way to buy CVV online are not selling test data, so treat any test value you find there as unusable.
What developers test with a mock CVV
- Form validation, including length checks for three digit and four digit codes
- Luhn checks on the card number and how they interact with the CVV field
- Decline flows, retries, and the exact message shown to a customer
- 3D Secure challenges and the return path after authentication
- Refunds, voids, partial captures, and webhook delivery
Common mistakes
- Mixing live API keys with test card data, or the reverse
- Assuming a test CVV from one gateway works on another
- Hardcoding test values into production configuration
- Treating a successful sandbox payment as proof that a live integration is ready
- Assuming every test card passes a Luhn check, since some are built to fail on purpose
Legal and compliance notes
A mock CVV is a testing tool, and real card verification values are not a product. Buying, selling, or trading real CVV data is illegal in the United States and most other countries, and card networks treat it as fraud. The only legitimate way to handle a verification value is inside a compliant payment flow, where it goes straight to the processor. PCI DSS, maintained by the PCI Security Standards Council, forbids storing CVV or CVC data after authorization, which is why no honest business needs a database of them.