Answer
A CVV test number is a fixed card verification value that a payment processor publishes for sandbox testing. It is not a real card code. The value returns a set result in a test environment: approval, a named decline, or a 3-D Secure challenge. Test CVC values work with test API keys. A live account rejects them.
Test cards and their CVC values
Processors publish the card number, the CVC value, and the result each test card returns.
- Stripe Visa: 4242 4242 4242 4242, CVC 123, any future expiry date.
- Stripe American Express: 3782 822463 10005, CVC 1234. Amex uses 4 digits.
- Stripe CVC decline card: 4000 0000 0000 0127. Any 3-digit CVC returns an incorrect CVC error.
- Visa test PAN 4111 1111 1111 1111 with a 3-digit CVC appears in sandbox lists from several gateways. The fixed CVC value differs by processor.
Why a fixed CVC works in a sandbox
The sandbox does not contact an issuer. The gateway holds a table of test card numbers and the response each one produces. The CVC arrives as a string in the API request. The gateway compares that string to the table entry. Test PANs pass the Luhn checksum, so client-side validation does not block them.
Test CVC compared with a real CVC
- A real CVV has 3 digits on Visa, Mastercard, and Discover. It has 4 digits on American Express.
- The code is printed on the card. PCI DSS Requirement 3.2 bars storage of sensitive authentication data after authorization.
- A test CVC is a constant in vendor documentation. No issuer issued it and no account sits behind it.
Limits
Test numbers fail on production endpoints. Card networks do not route them. Use of a live card number that belongs to another person is card fraud under 18 U.S.C. 1029 in the United States. Test values carry no such risk because the accounts do not exist.
What a sandbox CVC does not prove
A test approval does not predict a live issuer response. Real declines come from issuer rules, balance checks, and risk scores. Real 3-D Secure flows run through the cardholder bank. No test card models those steps.