The short answer
There is no such thing as a v4 CVV on a Stripe test card. When you drop a test number into Stripe's test mode, the CVV field accepts any three digits, or four if you picked the Amex number. Type 123, 000, or 999 and the charge goes through the same way. Stripe has nothing to check the value against, because there is no issuer and no real account behind the number. The v4 in your search almost certainly refers to the card number family. Visa numbers start with 4, and copied test card tables tend to group rows that way.
Where the v4 label comes from
Test card lists get passed around developer forums, gists, and old blog posts, and whoever formats them often sorts by prefix. You end up with rows labeled v4 for Visa, v5 for Mastercard, v3 for Amex or JCB depending on who made the list. It is shorthand for the issuer range, not a version number and not a CVV format. If a form or a tutorial is asking you for a v4 CVV, the person who wrote it mixed up two columns of their own table.
Numbers that behave predictably
These are the ones I reach for, because each one triggers a specific response instead of a vague failure.
- 4242 4242 4242 4242 is the plain Visa success case. Any future expiry, any three digits, any postal code.
- 4000 0000 0000 0002 gives you a generic decline.
- 4000 0000 0000 9995 fails as insufficient funds.
- 4000 0000 0000 0069 comes back as an expired card.
- 4000 0000 0000 0127 returns an incorrect CVC decline.
- 3782 822463 10005 is the Amex case and wants a four digit code.
Stripe publishes the rest of the set, including the ones that fail on postal code checks and the ones that trigger 3D Secure, and the list changes as they add cases. Bookmark the current page rather than the version someone screenshotted two years ago.
Stripe Test Card CVV: What to Enter and Which Numbers Behave How
What to type in the CVC field
For a success path, anything works. Three digits for Visa, Mastercard, and Discover, four for Amex. The reason is simple: test mode short-circuits the issuer step, so there is no authorization message going anywhere that could carry a verification result. If you want a CVC failure, you cannot get it by typing the wrong digits on 4242. You have to use the card number that is hard-coded to return an incorrect CVC decline.
The mistake I see most often
Someone pastes a test number into a form that is running on live keys, then wonders why it declines or why their dashboard shows a charge attempt. Test numbers exist only in test mode. Swap your publishable and secret keys, reload the page, and the same digits will fail. The reverse is also worth checking: a form full of test numbers pointed at production is a sign your environment variables got crossed somewhere in deployment.
Keep the test data test data
A test card is not a card. It has no balance, no holder, and no CVV to leak. Real card verification values are a different category entirely, and the PCI rules are blunt about them: they cannot be stored after authorization, and they should not be sitting in your logs, your database, or a spreadsheet someone emails around. If a workflow depends on holding on to a CVC, the workflow is wrong. Test mode is where that kind of logic gets exercised safely, which is the whole point of having these numbers in the first place.