Short answer
A 2Checkout test CVV is not a real security code and it is not tied to any bank. In sandbox mode the gateway only checks the format: three digits for Visa, Mastercard, and Discover, four digits for American Express. Type 123 or 1234 and the checkout will accept it as long as the card number itself is a valid test card. Nothing is authorized against an issuer, nothing settles, and no money moves.
If you were hoping for a magic value that unlocks something, there isn't one. The CVV field in a sandbox is a form validator, not a security layer.
How the sandbox actually treats that field
When you send a test transaction, 2Checkout's sandbox parses the payload the same way live mode does — length, numeric characters, matching card brand — then short-circuits before it ever reaches a processor. That is why almost any well-formed code works. I look for two things when a test payment fails on CVV: a four-digit code sent with a Visa test card, or a stray space pasted in from a spreadsheet. Both produce the same generic decline, which is why people assume the CVV value itself matters more than it does.
Test cards that pair with those CVVs
These are the standard sandbox numbers published by payment providers. They pass the Luhn check, so the gateway accepts them as structurally real.
- Visa — 4111 1111 1111 1111, CVV 123
- Mastercard — 5555 5555 5555 4444, CVV 123
- American Express — 3782 822463 10005, CVV 1234
- Discover — 6011 1111 1111 1117, CVV 123
The expiry date matters more than the CVV here. Sandbox cards usually need a future date, and an expired one will fail before the CVV is even evaluated.
Forcing a decline on purpose
You still need to test the unhappy path. 2Checkout lets you trigger specific responses through sandbox parameters rather than through card data, so you can simulate a CVV mismatch, an insufficient-funds response, or a processor timeout without hunting for a special code. Use the API's response override for that. Randomly typing wrong digits in the CVV box is not a reliable way to reproduce a decline, because the sandbox does not run real verification.
Mistakes I see most often
- Testing with a live card number in sandbox. It will not charge, but it also will not prove anything about your integration.
- Assuming a sandbox CVV rule carries over to production. Live gateways verify against the issuer; sandboxes do not.
- Hardcoding 123 into your test fixtures and forgetting to strip it before release.
- Logging the CVV field anywhere in your app. That is prohibited under PCI rules regardless of environment.
Sandbox versus live
In production, the CVV is checked by the issuing bank and the result comes back as a match, no-match, or not-processed code. You receive that result, you act on it, and then you must not store the code. The PCI Security Standards Council is explicit on this: sensitive authentication data cannot be retained after authorization, even encrypted. So a sandbox is the only place where a test CVV is harmless to keep around in a fixture file.
About sites selling "real CVVs"
Sellers advertising working card verification values are dealing in stolen card data. Those numbers are frequently dead on arrival, and buying them is a federal offense in the US, not a shortcut around your integration. If your goal is to test a 2Checkout checkout, the sandbox cards above do the job for free.