What CVV code do you use with a Stripe test card?
For a standard Stripe test card, the Stripe test CVV code can be any three digits, such as 123, and American Express test cards accept any four digits, such as 1234. Stripe does not send test transactions to a real issuer, so the CVC field is not validated against a cardholder record while you are in test mode. Values like 000, 111, or 999 behave the same as 123. The CVC only becomes meaningful when you deliberately use a test card that Stripe has configured to return a failed CVC check.
In other words, the answer is simple: type any three digits, pair them with any future expiration date, and the payment will succeed if the card number itself is a success test card.
Why the CVC field accepts almost anything in test mode
Test mode runs against Stripe's sandbox rather than the card networks. That means there is no issuer to ask whether the CVC matches, no authorization hold, and no money moved. Stripe's test cards are documented placeholders, not real account numbers, so the security rules that apply to live transactions do not apply here.
Stripe Test CVV Example: Test Card Numbers and CVV Values
This is why developers can build and test a checkout flow without requesting a working card from anyone. The sandbox is designed for that purpose, and it is also why a test key and a live key are kept strictly separate.
Test cards that actually check the CVV result
Stripe publishes a small set of test cards that simulate specific declines, including CVC failures. If your integration reads the CVC check status, these are the ones to reach for:
- 4000 0000 0000 0127: declines with an incorrect CVC error. Use any CVC you like; the card is hardcoded to fail.
- 4000 0000 0000 0101: fails the postal code check instead, useful for testing address verification.
- 4000 0000 0000 0002: a generic decline, unrelated to CVC.
- 4000 0000 0000 9995: declines with insufficient funds.
- 4000 0000 0000 0069: declines because the card is expired.
Standard success cards such as 4242 4242 4242 4242, 5555 5555 5555 4444, and 3782 822463 10005 complete without complaint, and the CVC check comes back as passing.
Reading the CVC check result
After you create a test charge or PaymentIntent, the response includes a checks object. Inside it, cvc_check returns one of a few values:
- pass: the value matched what was expected.
- fail: the CVC check was rejected, as with 4000 0000 0000 0127.
- unavailable: the check could not be run.
- unchecked: no CVC check was requested.
You can also configure Radar rules or payment intent settings to require a CVC before a payment is allowed to proceed. Testing that branch of your logic is the main reason to care about which code you enter.
When to enter a specific value
Enter a deliberate, non-123 code in these cases:
- You are testing form validation rules in your own front end, for example rejecting fewer than three digits.
- You want to confirm that a zero-filled value such as 000 is stored and displayed correctly.
- You are verifying that a four-digit CVC is accepted for Amex and rejected for other brands.
In every other situation, any three digits will do.
Important limits of test cards
Test cards, test CVC values, and test expiration dates work only with test API keys in a sandbox. Presenting one to a live endpoint will be rejected, and no real payment can be completed with a documented test number. Never mix live keys into a testing environment, and never store CVC data from a real card, since PCI rules prohibit retaining it after authorization.
The short version: the Stripe test CVV code is any three digits you want, and the specific number only matters when you are testing a decline path.