Blog Productivity Tools Stripe Test Card Numbers: Comp...
Stripe Test Card Numbers: Complete Guide for Developers
Productivity Tools Dec 04, 2025 4 min read 1,412 views

Stripe Test Card Numbers: Complete Guide for Developers

Every Stripe test card number you need for development, plus scenarios for declined cards, 3D Secure, and international payments. Copy-paste ready.

A
Alex
Author

Every payment integration starts with test cards. You can't use real credit cards during development (nor should you), so Stripe provides a set of special card numbers that only work in test mode.

I've implemented Stripe on maybe 30 projects at this point. Still keep a cheat sheet of test cards because nobody memorizes 16-digit numbers. Here's everything you need, organized by scenario.

The Cards You'll Use 90% of the Time

These handle most development scenarios:

Card Number Brand Behavior
4242424242424242 Visa Succeeds
4000056655665556 Visa (debit) Succeeds
5555555555554444 Mastercard Succeeds
378282246310005 American Express Succeeds
6011111111111117 Discover Succeeds
Developer testing payment integration

For any test card: Use any future expiration date (12/34 works), any 3-digit CVC (123 is fine), and any 5-digit ZIP code. These values aren't validated in test mode.

The 4242 Visa card is burned into every Stripe developer's memory. It's the default happy path card.

Testing Declined Payments

Your app needs to handle failures gracefully. These cards simulate various decline scenarios:

Card Number Decline Reason
4000000000000002 Generic decline
4000000000009995 Insufficient funds
4000000000009987 Lost card
4000000000009979 Stolen card
4000000000000069 Expired card
4000000000000127 Incorrect CVC
4000000000000119 Processing error

Test each decline type. Your error messages should be helpful without revealing sensitive information. "Card declined" is fine. "Card reported stolen" might not be appropriate to display to users.

3D Secure / Strong Customer Authentication

3D Secure (3DS) is that popup asking for additional verification. European regulations (PSD2) require it for many transactions. Test it:

Card Number 3DS Behavior
4000002500003155 Requires 3DS, authentication succeeds
4000002760003184 Requires 3DS, authentication fails
4000008260003178 3DS required, already authenticated
Various credit cards for payment testing

If you're selling to European customers, 3DS testing is mandatory. The popup flow needs to work smoothly or you'll lose sales to confused customers.

Subscription and Recurring Payment Testing

Subscriptions introduce complexity. The initial charge might succeed, but what about renewals?

Card Number Behavior
4242424242424242 All charges succeed
4000000000000341 Attaching succeeds, first charge fails
4000008260000000 First charge succeeds, future charges fail

That last card (4000008260000000) is crucial for subscription businesses. It tests your failed renewal handling - emails, grace periods, service suspension. Many developers skip this and then scramble when real customers have payment failures.

International Card Testing

Cards from different countries can behave differently:

Card Number Country
4000000276000030 Germany (DE)
4000000826000004 United Kingdom (GB)
4000000360000006 Australia (AU)
4000001240000000 Canada (CA)
4000004840000008 Mexico (MX)
Mobile payment checkout testing

International cards help test address validation rules, which vary by region. Some countries require postal codes, others don't.

Generating Test Data Beyond Cards

Sometimes you need more than just card numbers. For testing form validation or generating sample data, test credit card generators can create Luhn-valid numbers for various card brands.

These generated numbers won't work with Stripe's API - only Stripe's designated test cards do. But they're useful for:

  • Testing client-side form validation
  • Populating demo environments
  • UI testing with realistic-looking data
  • Training materials and documentation screenshots

Common Testing Mistakes

Testing only the happy path. Real users enter wrong numbers, have expired cards, and hit limits. Test failures as thoroughly as successes.

Forgetting to switch to live mode. I've seen launches delayed because someone forgot to swap test keys for live keys. Build a deployment checklist that includes API key verification.

Not testing webhooks. Stripe sends events for payment outcomes. Your webhook handler needs to work correctly. Use Stripe CLI's webhook forwarding for local testing.

Ignoring idempotency. Users double-click. Networks retry. Without idempotency keys, you might charge customers twice. Test what happens when the same request hits your server multiple times.

Testing with round numbers only. Test with amounts like $47.93, not just $100.00. Decimal handling has caused real bugs in payment systems.

Testing Checklist Before Launch

Run through this before going live:

  • ✅ Successful payment (4242424242424242)
  • ✅ Declined payment (4000000000000002)
  • ✅ Insufficient funds (4000000000009995)
  • ✅ 3D Secure flow (if targeting Europe)
  • ✅ Webhook receives events correctly
  • ✅ Error messages are user-friendly
  • ✅ Receipts/confirmations send correctly
  • ✅ Refund process works
  • ✅ Subscription renewal failure (if applicable)
  • ✅ API keys swapped to live mode

Payment integrations are unforgiving. A bug means lost revenue or angry customers. Test thoroughly.

Quick Reference

Keep this handy:

  • Always works: 4242424242424242
  • Always declines: 4000000000000002
  • 3DS required: 4000002500003155
  • Expiry: Any future date (12/34)
  • CVC: Any 3 digits (123)
  • ZIP: Any 5 digits (12345)

Bookmark Stripe's test cards documentation too - they add new scenarios periodically. But for day-to-day development, the cards in this guide cover 99% of testing needs.