For every Stripe test card, the CVV is any 3-digit number. Type 123, 000, or 999 and the sandbox accepts it. The card number controls the outcome, not the security code you type. The default pick is 4242 4242 4242 4242 with any future expiry date, any 3-digit CVC, and any postal code. This guide covers which numbers pair with which test scenario, how to trigger a CVC check failure on purpose, and where the sandbox stops behaving like production. Criteria used here: match with Stripe's published test data, coverage of CVC-specific failure cases, and usefulness in automated test suites.
What a test card CVV actually is
Stripe test cards only work with test mode API keys, the ones that start with pk_test_ and sk_test_. No request leaves for a real card network. Because of that, the CVV field is not verified against an issuer. Stripe's own documentation states that test cards should be used with any 3-digit CVC unless a specific card is listed as producing a check failure. That is why a card like 4242 4242 4242 4242 accepts 123 as readily as 987.
The CVV check result shows up later on the charge or PaymentIntent as cvc_check, with values such as pass, fail, unchecked, or unavailable. For most test cards the value is pass. For the failure cards below it is fail, regardless of the digits you entered. That distinction matters: you cannot force a CVV failure by typing the wrong three digits on a normal test card.
Top pick: 4242 4242 4242 4242 with any CVC
This is the card Stripe uses in its own examples and the one most developers should reach for first. Any future expiry works. Any 3-digit CVC works. Any postal code works.
- Pros: succeeds in every payment flow, works for saved cards, subscriptions, and setup intents, produces a cvc_check of pass, requires no special handling in fixtures.
- Cons: never exercises an error path, so it tells you nothing about how your checkout behaves when a card is declined or a check fails.
Use it when: you need a guaranteed successful charge to test order creation, webhook handling, receipts, or subscription billing logic.
Card that fails the CVC check: 4000 0000 0000 0127
This number returns a decline attributed to an incorrect CVC. The failure comes from the number itself, not from the three digits in the form. Enter 123 and it still fails.
- Pros: the only reliable way to confirm your UI surfaces a CVV-specific error, and to confirm your code branches on cvc_check rather than on a generic decline code.
- Cons: easy to misuse, because developers often assume the typed CVV is what triggers the failure and then write a test that proves nothing.
Use it when: you are building error copy, retry logic, or a Radar rule that reacts to failed verification checks.
3D Secure card: 4000 0025 0000 3155
This card requires authentication before the payment completes. In test mode Stripe presents an authentication page where you choose whether the attempt succeeds or fails.
- Pros: covers the redirect or modal branch that a plain success card never reaches, and lets you test both the authenticated and abandoned paths.
- Cons: needs a browser-driven test rather than a plain API call, so headless test suites need extra tooling.
Use it when: your account has 3D Secure enabled, or you are testing SCA flows for European customers. Pair it with any 3-digit CVC as usual.
Other decline numbers to keep in a fixtures file
These behave like the CVC failure card in one respect: the card number alone decides the result, and the CVC you type is irrelevant.
- 4000 0000 0000 0002 returns a generic decline.
- 4000 0000 0000 9995 returns a decline for insufficient funds.
- 4000 0000 0000 0069 returns a decline for an expired card.
A small fixtures file with these numbers lets you assert that every decline reason maps to something a human can read on the checkout page instead of a blank error.
American Express test card and the 4-digit CID
Amex uses a 4-digit card identification number instead of a 3-digit CVV. Use 3782 822463 10005 with any 4-digit CID, for example 1234, plus any future expiry. The same rule applies: the digits are not validated, so 0000 passes just as well. Add one Amex case to your suite if you accept the brand, because the input field length and the validation message both differ from Visa and Mastercard.
Checklist before you ship CVV handling
- Confirm your test keys are loaded and no live key is present in the test environment.
- Run one success case with 4242 4242 4242 4242 and a CVC of 123.
- Run one failure case with 4000 0000 0000 0127 and the same CVC of 123, then confirm the message references the security code.
- Run one authentication case with 4000 0025 0000 3155, including the abandoned path.
- Check the cvc_check field on the resulting object and make sure your code reads it.
Recommendation by scenario
Use 4242 4242 4242 4242 with CVC 123 for the happy path, 4000 0000 0000 0127 when you need a verification failure, and 4000 0025 0000 3155 when authentication is in scope. Keep those three in your test fixtures and the remaining decline numbers as secondary cases. If you accept Amex, add 3782 822463 10005 with a 4-digit CID.
Mistakes that waste time
Typing 999 hoping to force a CVV failure does nothing on a card that is not built for it. Using test numbers against a live key produces real declines and can trip account monitoring. Storing a CVC after authorization is prohibited by PCI DSS even in production, so do not build a database column for it just because the test value looks harmless. Finally, do not hardcode a real card number anywhere in a repository, not even in a comment.