Stripe Test Card Numbers, and What Each One Does

Use 4242 4242 4242 4242 for nearly every test you run. It is Stripe's default Visa success card in test mode. Any future expiration date works, any three digit CVC works, and any billing postal code works. No funds move. When you need a failure instead of a success, swap in a card built to fail in one specific way, and the lists below cover the ones worth keeping close.

What makes a test card different from a real one

Test numbers are published by Stripe and recognized only inside test mode. Your integration behaves the same way it does in production. You still create a PaymentIntent, your server still handles the response, and your webhooks still fire. The difference sits behind the API.

  • They work with test API keys only, the ones starting with pk_test_ and sk_test_. Paste one into a live flow and the charge fails.
  • Nothing settles and nothing is charged. You can run the same payment a hundred times without a fee.
  • The expiration date must be in the future. A past year gets rejected before the card logic ever runs, so you never see the error you were trying to reproduce.
  • Success cards ignore CVC and postal code checks. Stripe also publishes cards that fail specific verification checks when you need to test that branch.

The success cards

  • 4242 4242 4242 4242 (Visa): the default. Start here.
  • 4000 0566 5566 5556 (Visa debit): same result, different funding type. Handy when your checkout branches on debit.
  • 5555 5555 5555 4444 (Mastercard).
  • 5200 8282 8282 8210 (Mastercard debit).
  • 3782 822463 10005 (American Express): note the four digit CVC.
  • 6011 1111 1111 1117 (Discover).
  • 3056 9300 0902 0004 (Diners Club).
  • 3566 0020 2036 0505 (JCB).

Cards that decline on purpose

Each of these returns a distinct decline code, which matters if your UI shows a tailored message or your retry logic keys off the reason.

  • 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.
  • 4000 0000 0000 9987: lost card.
  • 4000 0000 0000 9979: stolen card.

Authentication and 3D Secure

Card authentication is where most test suites get thin. 4000 0025 0000 3155 requires authentication, so Stripe shows a test page where you pick whether the customer authorizes or fails. 4000 0000 0000 3220 triggers a 3DS2 challenge instead. The return trip is the part that breaks in real integrations, so run both and confirm your webhook handles the final status rather than trusting the redirect alone.

Disputes and refunds

Two cards exist purely to open disputes: 4000 0000 0000 0259 for a fraudulent charge and 4000 0000 0000 2685 for a product not received. They take a few days to appear in the Dashboard, which is expected. Refund testing does not need a special number. Charge any success card and refund it.

Tokens, if you use the older Tokens API

tok_visa, tok_mastercard, tok_amex, and tok_visa_debit are prebuilt tokens created with a test key. They skip the card entry step and work anywhere a card source does. Newer integrations should use PaymentMethods instead, but you will still see tokens in older codebases.

Mistakes I see most often

  1. Testing with live keys. Test numbers are rejected outright in live mode, and the error looks nothing like a real decline.
  2. Using 4242 to test a failure path. It always succeeds, so the error handler never runs.
  3. Typing an expiration year that already passed, then chasing a bug that does not exist.
  4. Skipping webhooks. Test mode still emits events, so verify signatures and status transitions before you ship.
  5. Assuming a live checkout preview accepts test numbers. Only test mode does.

A habit worth keeping

Stripe adds and retires test numbers over time. Check the official testing page before hardcoding anything into a suite, and keep a short scratch file with the dozen numbers you actually use. That beats searching the docs in the middle of a failing build.