Stripe Test Cards: The Complete 2026 Cheat Sheet for Developers
Stripe test cards let you simulate real payments without moving a cent. They're the fastest way to check that your checkout, subscriptions, and webhooks actually work before you flip the switch to live mode. If you're wiring up payments and need a card number that triggers a success, a decline, or a 3D Secure challenge on demand, this is the reference you want open in a second tab.
Here's the full cheat sheet, the gotchas that trip people up, and how to test the same flows when you're selling through a merchant of record instead of raw Stripe.
TL;DR
- Stripe test cards only work in test mode, with test API keys. They never charge a real card.
- The card you'll use most: 4242 4242 4242 4242 (Visa, always succeeds).
- Use any future expiry date, any 3-digit CVC, and any postal code.
- Specific numbers trigger specific outcomes: declines, 3D Secure prompts, disputes, and country-specific cards.
- Testing matters most for the flows that break silently: failed renewals, webhook handling, and tax calculation. If you sell through a merchant of record like Creem, you test the same lifecycle but the tax and compliance edge cases are already handled for you.
What Stripe test cards are
Stripe runs in two modes: test and live. In test mode, you use test API keys (they start with sk_test_ and pk_test_) and a set of special card numbers that behave like real cards without touching a bank. You can run a full checkout, create a subscription, trigger a refund, and watch the webhooks fire, all without a real charge.
The moment you switch to live keys, these test numbers stop working and return an error. That's by design. It keeps test data out of your real books.
The essential Stripe test cards
These are the numbers you'll reach for daily. For all of them, use any future expiry (like 12/34), any 3-digit CVC (any 4-digit for Amex), and any postal code (like 42424).
Successful payments:
4242 4242 4242 4242— Visa, the default success card. Use this 90% of the time.4000 0566 5566 5556— Visa (debit).5555 5555 5555 4444— Mastercard.2223 0031 2200 3222— Mastercard (2-series).3782 822463 10005— American Express.6011 1111 1111 1117— Discover.
Declines (the ones that matter for error handling):
4000 0000 0000 0002— generic decline.4000 0000 0000 9995— insufficient funds.4000 0000 0000 9987— lost card.4000 0000 0000 0069— expired card.4000 0000 0000 0127— incorrect CVC.4000 0000 0000 0119— processing error.
3D Secure / authentication:
4000 0027 6000 3184— requires 3D Secure 2 authentication on every transaction.4000 0000 0000 3220— 3D Secure 2 challenge flow.4000 0000 0000 3055— 3D Secure 2 supported but not required.
Testing declines, disputes, and 3D Secure
The success card is the easy part. The flows that actually break in production are the ones people forget to test.
Declines. Your checkout should handle a declined card gracefully, showing the user a clear message instead of a stack trace. Run 4000 0000 0000 0002 and confirm your UI recovers. Then test 4000 0000 0000 9995 (insufficient funds) separately, because the error code differs and you may want different messaging.
Disputes and chargebacks. Use 4000 0000 0000 0259 to create a charge that's immediately disputed as fraudulent. This lets you test your dispute webhook handling and your internal alerts. Chargebacks are expensive and time-sensitive in production, so the handling path is worth getting right.
3D Secure. European cards increasingly require Strong Customer Authentication. Card 4000 0027 6000 3184 forces a 3D Secure challenge so you can confirm your integration completes the authentication step instead of silently failing. Skip this test and you'll lose European customers to a checkout that dead-ends.
Testing subscriptions and failed renewals
Here's the silent revenue killer: a subscription renews, the card fails, and nobody notices until churn spikes.
To test it, create a subscription with 4242 4242 4242 4242, then use the Stripe dashboard or API to swap the customer's card to a decline number like 4000 0000 0000 0341 (attaches fine, fails on the next charge). Advance the test clock and watch what happens. Does your dunning logic retry? Does the customer get an email? Does access get revoked at the right time?
This is where most payment integrations are weakest, and it's the hardest thing to test by hand. Stripe's test clocks help, but you're still building and maintaining the whole retry-and-recover system yourself.
The webhook testing trap
Test cards confirm the charge. Webhooks confirm your app reacted to it. These are two different things, and the gap between them is where orders go missing.
When a payment succeeds, Stripe sends a payment_intent.succeeded or checkout.session.completed event to your webhook endpoint. Your app is supposed to catch it and fulfill the order, grant access, or send the license key. If your endpoint is down, slow, or mishandles the event, the customer pays and gets nothing.
Test the full loop: run a test card, then confirm the webhook arrived, was verified with your signing secret, and triggered the right action. Use the Stripe CLI (stripe listen and stripe trigger) to replay events locally. For a deeper webhook workflow, a tool like webhook.site helps you inspect raw payloads before you write handler code.
How this works with a merchant of record
Everything above assumes you're integrating Stripe directly, which means you own the entire payment lifecycle: declines, disputes, 3D Secure, dunning, webhooks, and the tax layer on top.
If you sell through a merchant of record like Creem, you still test your integration with sandbox payments, but a lot of the hardest edge cases are handled for you. Creem is the legal seller, so it owns chargeback handling, 3D Secure compliance, and tax calculation across every jurisdiction. You test that your product gets fulfilled when a payment succeeds; Creem handles what happens when a French customer's bank demands SCA or a buyer disputes a charge six weeks later.
The practical difference: with raw Stripe you build and maintain the decline-recovery and compliance machinery yourself. With an MoR, you wire up fulfillment and let the platform own the messy parts. For a solo founder or small team, that's fewer test cases you have to think about and fewer ways to lose revenue silently. See the pricing page for what that costs.
Common mistakes with Stripe test cards
- Using test cards in live mode. They'll fail. Test numbers only work with test keys.
- Real card in test mode. It won't charge, but it also won't behave like the test cards, so you won't get predictable outcomes.
- Only testing the success path. The
4242card passing doesn't mean your integration is done. Declines, disputes, and failed renewals are where production breaks. - Forgetting webhooks. A successful charge with a broken webhook means the customer paid and got nothing.
- Skipping 3D Secure. If you sell to Europe and don't test SCA, you'll silently lose those customers at checkout.
FAQ
What is the Stripe test card number?
The main one is 4242 4242 4242 4242 (Visa), which always succeeds. Use any future expiry date, any 3-digit CVC, and any postal code.
Do Stripe test cards charge real money? No. Test cards only work in test mode with test API keys and never move real funds. They're built to simulate outcomes safely.
How do I test a declined payment in Stripe?
Use 4000 0000 0000 0002 for a generic decline, or 4000 0000 0000 9995 for insufficient funds. Confirm your checkout shows a clear error and recovers.
How do I test 3D Secure with Stripe?
Use 4000 0027 6000 3184, which forces a 3D Secure authentication challenge on every transaction so you can verify your integration completes the step.
Why does my Stripe test card fail in production? Because test cards only work in test mode. Once you switch to live API keys, those numbers return an error by design. You need a real card in live mode.
Do I still need test cards if I use a merchant of record? Yes, you test your own integration with sandbox payments, but the merchant of record handles the harder compliance and chargeback edge cases, so there's less for you to build and test.
Ship a checkout that actually works
Stripe test cards are the difference between "it worked on my machine" and a checkout that survives real customers. Bookmark the numbers, test the decline and 3D Secure paths, and never trust a 4242 success as proof you're done.
If you'd rather not build the entire decline-recovery, dispute, and tax-compliance stack yourself, Creem handles the payment lifecycle as your merchant of record so you can focus on shipping product. Wire up your first product in under 30 minutes and test it end to end.
Stop guessing. Start testing.
