A Checkout.com test CVV is the verification value attached to a sandbox test card. The sandbox never contacts a real issuer, so it does not compare your CVV with a cardholder account. It matches the number you send against the test card you selected and returns a simulated result. Generic success cards accept any three or four digits, while designated test cards return a CVV mismatch so you can exercise your decline path.

checkout.com test cvv vs 2checkout

Prerequisites

  • Sandbox secret key and public key from the Checkout.com dashboard
  • Access to the test card table in the Checkout.com developer documentation
  • A client that can post card details or a card token to the payments endpoint
  • A way to read the full response body, including the card verification fields

Steps

  1. Open the Checkout.com dashboard and confirm the account selector shows sandbox, not live.
  2. Open the test card reference table in the developer documentation and keep it beside your client.
  3. Choose the test card whose documented outcome matches the case you want to cover, for example a plain approval or a CVV mismatch decline.
  4. Copy the card number, the expiry month and year, and the CVV exactly as the table lists them.
  5. Send a payment request from your client using those values and the sandbox key.
  6. Read the response and record the status, the response code, and the card verification result field.
  7. Repeat the request with a different test card from the table to cover the opposite outcome.
  8. Store both responses as fixtures so your integration tests can assert on them later.

What the sandbox actually checks

The sandbox validates format and routing, not cardholder data. A card number must pass the Luhn check and carry a plausible length, the expiry must be in the future, and the CVV must have the right digit count for the brand. Once those rules pass, the sandbox returns the outcome assigned to that test card. A CVV mismatch is a scripted response, which is why the same digits can approve on one test card and decline on another.

related article

Common mistakes

  • Sending a live key by accident, which turns a harmless test into a real authorization attempt.
  • Mixing a test card number with the CVV of a different card, which produces a format or decline error unrelated to the case under test.
  • Using an expiry date in the past, which fails validation before the CVV logic runs.
  • Testing only the approval card and never the mismatch card, which leaves the decline branch untested.
  • Reusing real cardholder data in the sandbox. Test values exist so production data never touches a test environment.

Housekeeping

Keep test keys, test cards, and fixtures in a separate configuration profile from live credentials. Rotate the sandbox keys when a team member leaves the project, and delete captured response logs that contain full card numbers after you finish debugging.

Checkout.com Test CVV Synonyms: CVV2, CVC, CSC Explained