What are Stripe test card numbers?

Stripe test card numbers are fake card values that run through Stripe's payment flow in test mode. They pass the same format checks as real cards, but they move no money and belong to no bank account. Stripe publishes them so developers can build and check checkout, subscription, and refund logic before going live.

They work with test API keys, the ones starting with pk_test_ and sk_test_. Sending a real card number into a test environment is the mistake to avoid, not the other way around.

Which Stripe test card numbers should you start with?

Start with 4242 4242 4242 4242. It succeeds on every charge type and covers most quick checks.

  • 4242 4242 4242 4242: Visa, charge succeeds
  • 4000 0566 5566 5556: Visa debit
  • 5555 5555 5555 4444: Mastercard
  • 5200 8282 8282 8210: Mastercard debit
  • 3782 822463 10005: American Express
  • 3714 496353 98431: American Express
  • 6011 1111 1111 1117: Discover
  • 3056 9300 0902 0004: Diners Club
  • 3566 0020 2036 0505: JCB
  • 6200 0000 0000 0005: UnionPay

What expiry date, CVC, and postal code should I use?

Use any future expiry date, any three-digit CVC (four digits for American Express), and any five-digit postal code. Most test cards accept 12/34, 123, and 12345.

Several test cards reject specific CVC or postal values so you can check your validation path. Stripe prints the failing values next to each card in its testing docs.

How do you use a Stripe test card, step by step?

  1. Switch the Stripe dashboard to test mode.
  2. Copy a test publishable key and test secret key into your environment file.
  3. Load your checkout with a test number, a future expiry, any CVC, and any postal code.
  4. Confirm the PaymentIntent status in the dashboard.
  5. Repeat with a decline card and check that your app shows the right error.

How do you test declined payments in Stripe?

Stripe ships cards that always fail, each mapped to one decline code. Swap your success card for one of these and your error handling gets exercised.

  • 4000 0000 0000 0002: generic decline
  • 4000 0000 0000 9995: insufficient funds
  • 4000 0000 0000 9987: lost card
  • 4000 0000 0000 9979: stolen card
  • 4000 0000 0000 0069: expired card
  • 4000 0000 0000 0127: incorrect CVC
  • 4000 0000 0000 0119: processing error
  • 4000 0000 0000 0101: CVC check fails, charge still succeeds
  • 4000 0000 0000 0341: the card attaches to a customer, the charge fails

Map each code to a message a customer can act on. A generic decline and an insufficient funds decline call for different copy and different retry advice.

Which Stripe test cards trigger 3D Secure?

3D Secure cards force an authentication step before the charge completes. You need 3D Secure turned on in your Radar rules or PaymentIntent settings to see the challenge.

  • 4000 0000 0000 3220: authentication required, then succeeds
  • 4000 0000 0000 3055: authentication required, then succeeds
  • 4000 0000 0000 3063: authentication required, then fails
  • 4000 0000 0000 3091: authentication required, then fails

Test both outcomes. A customer who abandons the challenge and a customer who fails it land in different places in your billing flow.

Do Stripe test cards work in live mode?

No. Test numbers pass with test keys only, so a live key rejects them. That is why you can keep them in a repo without risk.

Test mode skips real issuer behavior too. No bank checks the address, no network round trip happens, and nothing settles. A green test run proves your integration works. It says little about your live approval rate.

How do you force refunds, disputes, and Radar outcomes?

Stripe publishes extra numbers for those paths. The set includes cards that open a dispute right after the charge, cards that trip Radar rules, and cards that fail on the first attempt and succeed on the second.

That list grows as Stripe adds cases, so the docs page is the source of truth. Copy numbers from there instead of from blog posts that go stale.

Common mistakes when testing with Stripe test cards

  • Mixing test keys and live keys in one environment file
  • Leaving a test number hard-coded in production code instead of a config value
  • Testing the success path only and shipping with no decline handling
  • Assuming test mode copies every issuer rule (it does not)
  • Borrowing a test number from another processor and expecting the same result

FAQ

Are Stripe test card numbers real credit cards?

No. They are reserved fake numbers that no bank issues. A charge made with one in test mode creates no debt and no settlement record.

Is it fine to use Stripe test card numbers?

Yes, in test mode. Stripe publishes them for that purpose. The risky move is putting a real card number into a test or staging system, which PCI DSS forbids.

Do the same numbers work on other payment processors?

No. Stripe's decline mapping and 3D Secure behavior are its own. Use each processor's published test list.

Where is the official Stripe test card list?

On Stripe's documentation site, on the Testing page. It lists every card, every decline code, and the exact scenario each one creates.

Can I test subscriptions and trials with these cards?

Yes. Attach a test card to a customer, create the subscription in test mode, and use test clocks to push the billing cycle forward instead of waiting weeks.