You do not buy a Stripe test card. Stripe publishes test card numbers for free, and every one of them works only in test mode with a test API key. The real decision is which published number to use: one that always approves, one that returns a specific decline code, or one that forces a 3D Secure challenge. Match the number to the payment outcome you need to reproduce, keep that mapping next to your test fixtures, and never place card data from a real account into a test request.

What to look for before you choose a number

• Mode lock. Test numbers resolve only against test keys, meaning pk_test_ and sk_test_ credentials. A test number sent with a live key produces a genuine decline instead of a simulated one.
• Outcome coverage. Choose numbers that cover the branches your code handles: approval, generic decline, insufficient funds, expired card, incorrect CVC, processing error, and authentication required.
• Authentication path. If you accept cards in regions where 3D Secure is common, use the numbers that force a challenge so you can exercise the redirect and the return handler.
• Token shortcuts. Stripe also exposes test values such as tok_visa and pm_card_visa, which skip raw card entry and are simpler to wire into server side tests.
• Clock control. For subscriptions and trials, pair the card with test clocks so billing cycles advance on demand instead of in real time.

Parameter bands that matter in test mode

Test cards are forgiving on most fields. Expiry can be any future date, CVC can be any three digits, and postal code can be any value, unless the number is built to fail that specific check. The band that carries real meaning is the decline behavior baked into the number.

• Approval: 4242 4242 4242 4242 for Visa returns a successful charge.
• Generic decline: 4000 0000 0000 0002.
• Insufficient funds: 4000 0000 0000 9995.
• Expired card: 4000 0000 0000 0069.
• Incorrect CVC: 4000 0000 0000 0127.
• Processing error: 4000 0000 0000 0119.
• Authentication required: 4000 0025 0000 3155 and 4000 0027 6000 3184 for 3D Secure flows.

Card brand changes the length rules. Amex test numbers use a four digit CVC, so build form validation around brand detection rather than a fixed three digit field.

Pitfalls that waste time

• Testing against live mode. Test numbers are not valid live cards. Send one to a live endpoint and you get a decline and a log entry, not useful coverage.
• Assuming portability. Each processor publishes its own test numbers. A Stripe test number has no guaranteed behavior on another gateway.
• Treating a random Luhn valid number as a test card. It passes the checksum and nothing else.
• Leaving test objects behind. Test mode writes real records into your dashboard. Clean up customers, subscriptions, and payment intents before you hand a project over.
• Mixing environments. A test publishable key joined to a live secret key fails in ways that look like a card problem but are a configuration problem.
• Using real cardholder data. Production PANs and CVVs should never be copied into a development request, and buying card data is illegal when free published test numbers cover the same paths.

FAQ

Do Stripe test cards cost anything?

No. They are published numbers, and test mode traffic is not billed.

Can I use a Stripe test card in live mode?

No. Live mode rejects them. Keep test numbers on test keys only.

Which test card should I start with?

4242 4242 4242 4242 for the happy path, then add one decline number and one 3D Secure number to your automated suite.

What expiry date and CVC should I enter?

Any future date and any three digits work unless the number is built to fail that check. Amex numbers expect four digits.

Do I need a real card to test Stripe?

No. The published test numbers cover approvals, declines, and authentication without touching a real account.