If you are integrating Checkout.com, the test CVV you need comes from the sandbox test card table in the official developer documentation, not from a shop, a forum, or a reseller. Test CVV values exist for one purpose: to make the sandbox return a specific CVV response code, such as match, no match, or not processed. They are free, they are published openly, and they only work with test API keys. Pick the test card whose number matches the network and outcome you want to simulate, then pair it with the sandbox CVV listed for that outcome. Anything advertised as a fresh or high balance live CVV is stolen payment data. It cannot be charged lawfully, it will fail against live authorization rules, and holding it exposes a business to card network fines and criminal liability.
What a Checkout.com test CVV actually is
A CVV is the 3 digit code on Visa, Mastercard, and Discover cards and the 4 digit code on American Express cards. On a live transaction, that code is sent to the issuer for verification and is never stored by the merchant after authorization. In the Checkout.com sandbox, no issuer is involved. The gateway reads the test card number and the test CVV, compares them to its internal test rules, and returns the response code you asked it to return.
That means a sandbox CVV is a switch, not a secret. Its only job is to tell the mock authorization engine which branch of logic to run.
Test CVV compared with live CVV
- Source. Live CVV is printed on a real card that an issuer gave to an account holder. Test CVV is published in gateway documentation for developers.
- Validity. Live values authorize against a real funding account. Test values authorize against nothing.
- Storage. Live CVV must not be retained after authorization under PCI DSS requirements. Test values carry no cardholder data, so storage rules do not apply to them in the same way.
- Keys. Test values work only with public and secret test keys. Live keys route to the card networks, where a test card is not a valid account number.
What to look for when you set up sandbox testing
Before you write any integration code, collect the following from the current Checkout.com test documentation.
- A card number for each brand you accept, at minimum Visa and Mastercard, plus Amex if you take it.
- The CVV value the documentation pairs with a CVV match and the value it pairs with a CVV mismatch.
- Cards that produce common declines, such as insufficient funds, expired card, and do not honor.
- Cards built for 3D Secure flows, including a frictionless path and a challenge path.
- Test BINs issued in the countries you sell into, so your routing and currency logic gets exercised.
Parameter bands that matter during testing
Think in terms of the ranges your production system must survive, then choose test inputs that sit at the edges of each range.
- CVV length. Test both 3 digit and 4 digit inputs so your form validation and your API payload mapping both hold.
- Expiry dates. Use a future month for approvals and a past month for expiry declines. Never hardcode a single date.
- Amounts. Start at the smallest unit your account supports, then test one amount in a mid band and one large amount to see how risk rules respond.
- Currencies. Test the presentment currency, the settlement currency, and at least one currency that requires conversion.
- Response codes. Cover approved, soft decline, hard decline, and CVV mismatch as separate branches in your error handling.
Pitfalls to avoid
- Mixing test credentials with live keys. The result is a confusing error that looks like a card problem but is a configuration problem.
- Treating every decline as a bug. Some test cards are designed to decline so you can verify your messaging.
- Storing CVV anywhere in your own logs or database. This applies to test data habits too, because habits ship to production.
- Testing one card brand and assuming the others behave the same. Field lengths, response text, and 3DS prompts differ.
- Borrowing test values from another gateway. Each provider maintains its own table and its own mapping.
- Leaving test card logic in production code paths. Gate it behind environment checks before launch.
FAQ
Is any CVV accepted in the Checkout.com sandbox?
For many test cards the sandbox returns a match for a broad range of CVV inputs, but specific documented values simulate a mismatch or an unprocessed check. Always confirm against the current test card table because providers update these rules.
Do test CVV values cost anything?
No. They are published for free as part of developer documentation, and no legitimate source charges for them.
Can I use a test CVV on a live site?
No. Live keys route to real networks, and test card numbers are not valid accounts. The attempt returns a decline or an error, and repeated attempts can trip fraud monitoring.
Why did my sandbox payment fail with a CVV error?
Check three things: that the CVV length matches the brand, that you are sending the value the documentation pairs with the outcome you want, and that your request includes the correct test card number alongside it.
Does Checkout.com store the CVV I send?
Authorization uses the value in transit. Retention of the verification code after authorization is restricted by PCI DSS, so store tokens and reference numbers instead.