The short answer
Stripe test card numbers are fake card numbers that Stripe publishes for test mode. They pass the Luhn check, they authorize against Stripe's test infrastructure, and they never reach a real bank. The key detail is the key itself: these numbers only work with a test API key, the ones that start with pk_test_ and sk_test_. Paste one into a live checkout and the charge is rejected.
If you only remember a single number, make it 4242 4242 4242 4242. It is a Visa that succeeds every time. Expiry can be any future date, CVC any three digits, ZIP any value.
Question: Where Can I Find Stripe Test Card Numbers?
Test cards that approve
- 4242 4242 4242 4242, Visa, standard success
- 4000 0566 5566 5556, Visa debit
- 5555 5555 5555 4444, Mastercard, standard success
- 2223 0031 2200 3222, Mastercard, standard success
- 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
Test cards that decline on purpose
These are the ones I reach for when I want to see how the checkout UI handles failure, or when I need a specific decline code to show up in a webhook.
- 4000 0000 0000 0002, generic decline, card_declined
- 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, decline that arrives after a successful 3DS step
3D Secure and authentication numbers
- 4000 0000 0000 3220, 3DS2 required, authentication succeeds
- 4000 0000 0000 3063, 3DS2 required, authentication fails
- 4000 0000 0000 3055, 3DS2 required, challenge flow
- 4000 0000 0000 3097, 3DS2 challenge, succeeds
- 4000 0025 0000 3155, 3DS required, challenge flow
- 4000 0084 0000 1629, CVC check fails even though the charge goes through
Raw tokens for server-side tests
When you would rather skip the card form, Stripe hands you single-use tokens. tok_visa, tok_mastercard, tok_amex, tok_discover, tok_visa_debit, tok_mastercard_debit and tok_mastercard_prepaid all represent successful payments, and there are matching decline tokens such as tok_chargeDeclined and tok_chargeDeclinedInsufficientFunds. Building a PaymentIntent from a token removes the client step entirely, which is useful in integration tests and in scripts that run on every commit.
Rules worth committing to memory
- Test numbers are inert outside test mode. A live key plus 4242 produces an error, not a free payment.
- Expiry must be in the future. A past date triggers expired_card before the number is even considered.
- CVC is three digits, four for Amex. Anything shorter fails client-side validation and you never see a Stripe response.
- ZIP and postal code accept any value, so do not build a test around a specific one unless the address check is the thing you are verifying.
- Test data is separate. Charges, customers and subscriptions created with a test key live in their own sandbox and stay out of your live dashboard.
When a test card refuses to work
Most of the time it is one of four things. A live key got pasted into the environment file. The number picked up a space in the wrong place. The expiry year is the current year and the month already passed. Or 3DS was required and the test flow never came back. Read the decline code in the API response rather than the message on screen. The code says what actually happened, and the on-screen string is often your own generic copy.
One note on scope: test numbers are published, public, and useless to anyone trying to move real money. If you are building or debugging an integration, that is the whole point, and it is all you need.