Checkout.com Test CVV: Which CVV to Use in Sandbox

Short answer

In Checkout.com test mode the CVV field accepts any three-digit number. The published test cards are listed with CVV 100, so 100 is the value most integrations use. No issuer validates that number, because a sandbox request never reaches a card network. If you need a specific outcome, change the test card number, not the CVV.

Prerequisites

• A Checkout.com account with sandbox access
• Test API keys that start with pk_test_ and sk_test_
• A test card number taken from the Checkout.com test card list
• A future expiry date, for example 12/2030
• A test webhook endpoint if you plan to inspect asynchronous events

Run a test payment with a CVV

1. Open the Checkout.com dashboard and switch the environment selector to test mode.
2. Copy the test public key and the test secret key into your integration or the hosted payment page.
3. Enter a success test card number, such as 4242 4242 4242 4242 for Visa.
4. Type a future expiry date in the MM/YY field.
5. Enter 100 in the CVV field. Any three digits are accepted, but 100 matches the documentation.
6. Submit the payment and open the response object.
7. Read the response code. A success card returns an authorized or approved status.
8. Repeat the run with a decline test card to confirm your error handling path.

What the CVV value does and does not do

The CVV field exercises your form validation, your request payload, and the way your code stores the response. It does not exercise issuer verification. Checkout.com decides the outcome from the card number, so the same CVV of 100 can produce an approval on one test card and a decline on another. Treat the CVV as a required three-digit string in your payload and nothing more.

Testing a CVV failure

Simulating a mismatch works through the card number, not the CVV. Select a test card that carries a decline or a verification-required result, submit it with CVV 100, and inspect the error code that comes back. Do not try to force a CVV error by guessing random digits. That adds noise to your logs without changing the sandbox behavior.

Rules that keep test data clean

• Use test keys only. A live key turns the request into a real charge attempt.
• Never enter a real card number or a real CVV, even to check formatting.
• Do not store CVV values after authorization in any environment, including sandbox copies of production schemas.
• Wipe test card data from screenshots, fixtures, and shared logs before you pass them to another team.