The short answer
There is no special "v5" CVV in Stripe. When a Stripe test card asks for a CVC, you type any 3 digits. Amex test cards take any 4 digits. The "v5" part of your search comes from third-party test card lists and API version labels, not from a Stripe field or a card property.
I look at it this way: the card number drives the outcome in test mode, and the CVC is mostly there so your form validation runs the same way it will in production.
How Stripe handles CVV in test mode
Stripe's test mode does not check the CVC against anything. There is no issuer, no authorization network, and no stored value. Type 123, 000, or 999 and the charge behaves the same way. That is deliberate. Developers need a passing value that is obviously fake so nobody mistakes a test card for a real one.
The exception is a small set of dedicated test cards built to simulate CVC failures. Those return a specific decline code so you can test your error handling. Card 4000 0000 0000 0127, for example, produces an incorrect CVC response no matter what digits you enter.
Test cards I keep on hand
- 4242 4242 4242 4242 Visa, plain success. Any future expiry, any 3-digit CVC.
- 5555 5555 5555 4444 Mastercard, plain success.
- 3782 822463 10005 Amex, plain success. Use a 4-digit CID.
- 4000 0000 0000 0002 Generic decline.
- 4000 0000 0000 9995 Insufficient funds.
- 4000 0000 0000 0069 Expired card.
- 4000 0000 0000 0127 Incorrect CVC.
- 4000 0000 0000 3220 3D Secure 2 authentication required.
Every one of those is public documentation. If a list you find online mixes in numbers that look like real customer cards, close the tab. Real PANs do not belong anywhere near a test account.
Where "v5" comes from
Two places, mostly. First, API version pinning: Stripe lets you lock an account to a dated API version through the Stripe-Version header, and tutorials label their pinned examples loosely as v1 through v5 depending on how old the write-up is. Second, blog authors version their own test card lists. A "v5" list is just the fifth revision of somebody's cheat sheet, not a Stripe concept.
So if a guide tells you to use card X with CVV "v5", it is wrong about the CVV. The CVC field is digits only, and in test mode the digits do not matter unless you picked a failure-simulation card on purpose.
Practical setup notes
- Use your test publishable key (pk_test_) in the front end and the matching secret key on the server. Live keys will reject these numbers.
- Pass a future expiry date. "Any future date" is the documented answer, and an expired date will trip your own client validation before Stripe ever sees it.
- Keep the CVC field required in your form. Testing a flow where the field is optional teaches you nothing about the real one.
- Log the PaymentMethod ID, not the card number. Test PANs are harmless, but the habit should be the same as production.
- Re-run the CVC failure card after any change to your decline messaging. It is the fastest way to catch a swallowed error.
One caution
Test card numbers are safe because they cannot be charged. That is the whole reason Stripe publishes them. Treat any other card number as regulated data: it falls under PCI DSS scope the moment it touches your systems, and storing it without a documented business need creates liability you do not want.