Checkout.com Test CVV: Sandbox Test CVV Values Explained

A Checkout.com test CVV is a sandbox-only security code that you pair with a test card number to simulate card verification results without touching a real card. Checkout.com publishes these values in its test card tables, and they only work against the sandbox environment. A test CVV has no value on a live account, and it cannot be used to authorize a real payment.

What the CVV field does in a test transaction

The card verification value is the short code printed on a physical card, three digits for Visa, Mastercard, and Discover, and four digits for American Express. In production, the issuer checks that code against its records. In the Checkout.com sandbox, no issuer is involved, so the platform simulates the check for you.

When you post a payment request, the sandbox compares your test card number and test CVV against its internal test card table. The pair determines the response you get back, such as an approved authorization, a soft decline, or a specific CVV mismatch error. That lets you build and test decline handling before you ever connect live keys.

Where to find Checkout.com test CVV values

Test CVV values are not secret and they are not unique to your account. They live in documentation and dashboards:

• The Checkout.com developer documentation test card page, which lists card numbers alongside their expected CVV, expiry, and outcome.
• The sandbox area of your Checkout.com dashboard, where test cards and their behavior are summarized.
• The API reference for payments and card verification, which explains response codes for CVV checks.
• Release notes and status updates, which occasionally add new test cards for new scenarios.

Read the outcome column, not just the number. Two test cards can share the same CVV and still return different results because the card number drives the scenario.

Test cards that simulate CVV failures

Some test card numbers are built to fail the CVV check on purpose. They let you confirm that your checkout shows the right message, that your order status does not flip to paid, and that your retry flow behaves correctly. Others simulate expired cards, insufficient funds, or blocked cards.

Keep this mapping in a configuration file or a fixture rather than scattering raw values through your code. When you add a new provider scenario, you update one list instead of hunting through test suites.

Rules for handling test CVV values

• Use sandbox test values only in the sandbox. Never enter real card details into a test environment.
• Never store a CVV, test or real, after authorization. Storing sensitive authentication data violates PCI DSS requirements.
• Tokenize card data so your servers handle a token instead of the raw number and code.
• Expect sandbox behavior to differ from production. A test CVV proves your integration handles a response, not that a live issuer will approve it.

Troubleshooting usual sandbox problems

If a test payment fails for unexpected reasons, check three things first. Confirm you are sending your sandbox secret key and not a live key. Confirm the expiry date on the test card is still in the future. Confirm the CVV matches the specific test card number you used, since the table pairs them one to one. If the response mentions authentication, the test card may be wired for a 3D Secure simulation that needs an extra step in your flow.

Bottom line

A Checkout.com test CVV exists to make sandbox testing realistic. Pull the current values from the official test card table, pair each one with the matching card number, and keep real card data out of the test environment entirely.