Stripe test card numbers are the card values Stripe publishes for its test mode, and they work only when your request is sent with a test API key. The best known is 4242 4242 4242 4242, a Visa number that approves a valid charge, while other Stripe test cards are designed to trigger specific outcomes such as a decline, an expired card, or a 3D Secure challenge.

Because these numbers are not tied to any real account, they never move money and never appear on a real statement. They exist so you can build and verify checkout flows, error handling, and subscription logic without touching a live card.

How Stripe test mode works

Your Stripe account has two independent environments. Live mode processes real payments. Test mode accepts only test credentials: API keys that start with pk_test_ and sk_test_, plus the test card numbers below.

The separation is strict in both directions. A test card sent with a live key fails, and a real card sent with a test key fails. That is what keeps experiments in your sandbox from reaching production data.

A few habits keep test runs predictable:

• Use a future expiration date unless the specific test number is meant to represent an expired card.
• Use any three digit CVC, or four digits for American Express, unless the test is about CVC checks.
• Use any billing postal code unless the test is about address verification.
• Confirm you are loading test keys in the environment you are testing.

Common Stripe test card numbers

Successful charges

• Visa: 4242 4242 4242 4242
• Visa (debit): 4000 0056 0000 5556
• Mastercard: 5555 5555 5555 4444
• American Express: 3782 822463 10005
• Discover: 6011 1111 1111 1117
• JCB: 3566 0020 2036 0505
• UnionPay: 6200 0000 0000 0005
• Diners Club: 3056 9300 0902 0004

These approve a standard payment when the rest of the request is valid. Run one per brand if your checkout renders brand logos or applies brand specific rules, since card brand detection is part of the flow you are testing.

Declines and error conditions

• 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 0119: processing error

Each of these maps to a decline code your application can read. Handle the code rather than the message, log it, and show the customer a useful next step. Subscription retries and dunning emails are much easier to verify with these numbers than with a live card.

3D Secure and authentication

• 4000 0000 0000 3220: requires 3D Secure 2 authentication
• 4000 0000 0000 3063: 3D Secure 2 authentication must be completed for the charge to succeed

Stripe publishes additional authentication numbers for frictionless flows, challenge flows, and unsupported card scenarios. Test both the pass and fail path, because a customer who abandons the authentication step needs a different recovery message than one who fails it.

Payment method tokens instead of raw numbers

If your integration already creates a PaymentMethod or a token, you can skip raw card data and pass a reusable test identifier. Stripe provides tokens such as pm_card_visa for PaymentMethods and legacy tokens such as tok_visa for older Charges based code.

These are convenient in automated tests because they reduce fixtures to a single string and remove the need to store card shaped values in your test suite.

Things to watch out for

• Test numbers behave differently across regions for some local payment methods, so verify the specific method you support.
• A test number that works in one currency may be rejected in another.
• Never ship test credentials to production, and keep them out of client side bundles that real customers load.
• Clean up test subscriptions and customers before a release so dashboards stay readable.

Used together, these Stripe test card numbers cover the outcomes that matter most: a clean approval, a soft decline, a hard decline, and an authentication step. Build a small fixture for each and your payment flow will be far easier to trust before it goes live.