Top pick: Checkout.com's own sandbox, using the test card numbers published in its developer documentation. That sandbox is the only place where a CVV can be "tested" against Checkout.com. The criteria used here are narrow: the test runs in an isolated environment, the card data comes from the provider's published list, the CVV field accepts a documented test value, and the integration can be forced into a decline so you can see how your code reacts. A live account cannot be tested with a CVV, and purchased card data has no role in any test.

What a "test CVV" means at Checkout.com

Payment providers run a sandbox that mirrors the production API but never reaches a card network. Checkout.com publishes test card numbers for that sandbox, and each number maps to an outcome such as approval, CVV mismatch, insufficient funds, or expired card. In the sandbox the CVV field is a fixed-length input that accepts a test value, and documentation states which value or which card number produces which response. Where a scenario needs a specific CVV, that value sits next to the card number in the docs. Treat the documentation as the source of truth because test card lists change.

  • Pros: no real cardholder data, repeatable results, safe to run on every commit.
  • Cons: sandbox behavior does not fully match live issuer rules, and lists get updated without notice.

Use case: a developer wiring up tokenization, the payment form, and error handling before go-live.

Option 1: Published sandbox test cards

The standard route. You copy a test card number from the docs, enter any documented CVV, and submit through your sandbox keys. The response tells you whether your form submits, whether your server handles the token, and whether your UI renders the result.

  • Pros: matches the production request shape, needs no special tooling, resets with a new sandbox key.
  • Cons: you must read the docs for each scenario, and stale numbers produce confusing failures.

Recommendation: start here for every new integration.

Option 2: Forced decline and CVV mismatch scenarios

A payment integration that only sees approvals is untested. Checkout.com's test cards let you trigger declines, including a CVV mismatch, so your code path for a failed verification gets exercised.

  • Pros: proves your error messaging and retry logic work, catches silent failures before customers see them.
  • Cons: response code mappings are provider-specific, so the same scenario may need a different card number at another gateway.

Recommendation: run at least one mismatch and one hard decline in staging before every release.

Option 3: 3DS and authentication test flows

Cardholder authentication needs its own test path. Sandbox 3DS uses test credentials and a simulated challenge page, which is separate from the CVV field.

  • Pros: covers frictionless and challenge outcomes, catches redirect bugs.
  • Cons: needs a browser session and extra setup, and results can differ from live issuer behavior.

Recommendation: test 3DS after the basic card and CVV flows pass.

Not an option: purchased CVVs or "fullz"

A real CVV cannot be validated as a test. Any seller advertising "100% validity" test CVVs is either reselling stolen card data or running a scam, and both outcomes land on you. Card testing against live endpoints is fraud, it triggers chargebacks, and it gets merchant accounts terminated. PCI DSS also forbids retaining the CVV after authorization, so storing test or live CVV values in logs or databases breaks compliance.

  • Pros: none.
  • Cons: criminal exposure, account loss, fines, and no useful test signal.

Recommended checklist

  1. Switch the SDK to sandbox keys and confirm no live key is loaded.
  2. Pull current test card numbers from the provider documentation, not from a forum post.
  3. Run one approval, one CVV mismatch, and one hard decline.
  4. Log response codes only, never the CVV.
  5. Repeat with a 3DS test card before release.