Answer first: Stripe has no "CVV v6." Test cards accept any three-digit CVC, or four digits for Amex, and any future expiry date. The "v6" in that search is a card-shop label, not a Stripe field, version, or validation rule. Test card numbers only work against test-mode API keys, so nothing you type in the CVC box reaches a real issuer.
Where "v6" comes from
Resellers of stolen card data like to tag listings with batch numbers, BIN ranges, and version suffixes to make a dump look fresh. "V6" is that kind of tag. It maps to nothing in Stripe's documentation, nothing in the EMV spec, and nothing in the payment networks' test suites. If a listing claims a card has a "v6 CVV," it is marketing copy attached to stolen data, and buying or using it is a federal offense in the US under 18 U.S.C. § 1029.
What actually matters when you test a checkout flow is the card number, the expiry format, and whether your integration reads the decline code correctly.
The test numbers I keep on hand
- 4242 4242 4242 4242 — Visa, straight approval. The default for smoke tests.
- 4000 0566 5556 5556 — Visa debit.
- 5555 5555 5555 4444 — Mastercard credit.
- 2223 0031 2200 3222 — Mastercard 2-series.
- 3782 822463 10005 — Amex. This one takes a four-digit CVC.
- 6011 1111 1111 1117 — Discover.
- 3056 9309 0259 04 — Diners Club.
- 3530 1113 3330 0000 — JCB.
CVC and expiry rules in test mode
Any three digits pass on Visa, Mastercard, Discover, Diners, and JCB. Amex wants four. Expiry can be any month and year in the future, and the postal code field accepts anything reasonable when your Radar rules ask for it. Stripe does not validate the CVC against an issuer because there is no issuer in test mode.
The one time the CVC value matters is when you deliberately want a CVC failure. Card 4000 0000 0000 0127 returns an incorrect CVC error regardless of what you type, which is how you exercise that branch of your error handling.
Decline cards worth wiring into your tests
- 4000 0000 0000 0002 — generic decline.
- 4000 0000 0000 9995 — insufficient funds.
- 4000 0000 0000 9987 — lost card.
- 4000 0000 0000 9979 — stolen card. Useful for confirming you surface the right message without leaking detail.
- 4000 0000 0000 0069 — expired card.
- 4000 0000 0000 0119 — processing error.
- 4100 0000 0000 0019 — blocked as fraudulent by Radar.
Each of these returns a specific decline_code. Log it. Your support team will ask for it the first time a real customer fails a charge.
3D Secure test cards
Authentication flows need their own numbers. 4000 0025 0000 3155 triggers a 3DS challenge and succeeds when you complete it. 4000 0027 6000 3184 also requires authentication. 4000 0038 0000 0446 supports 3DS2. Run these against a test clock if you are checking how the challenge behaves on renewal.
Why test numbers stay in test mode
Stripe separates the two environments at the key level. A pk_test_ or sk_test_ key routes card data to a sandbox with no settlement, no acquirer, and no stored value. A live key with a test card number simply declines. There is no trick, no BIN, and no "v6" that bridges the two.
PCI DSS also forbids retaining the CVV after authorization, even in test logs. If your application writes the CVC field to a database or a debug log, strip it before you ship.
A short setup checklist
- Confirm you are on test keys in the dashboard before you type anything.
- Use 4242 for the happy path, then one decline card per error branch.
- Add the 3DS cards to your authentication tests.
- Verify your logs never contain a CVC value.
- Delete test customers and PaymentMethods before you point the same code at live keys.
That covers the whole of it. The CVC in test mode is a formatting exercise, not a secret.