Start with 4242 4242 4242 4242 as your default test Stripe card. It is a plain Visa success case: use any future expiry date, any three digit CVC, and any postal code, and the charge returns as succeeded with no authentication challenge. Every card below was judged on four points: whether it returns a predictable result on every run, whether it exercises a failure path your checkout has to handle, whether it supports 3D Secure, and whether it works in the browser, in Checkout, and in direct server side API calls.
4242 4242 4242 4242: the baseline success card
This is the number Stripe uses in its own quickstart examples, and it is the one to keep in a saved fixture.
- Pros: Succeeds in Payment Intents, Checkout, Elements, and the mobile SDKs. No 3D Secure interruption, so a failing redirect cannot mask a bug in your code. Accepts any future expiry, any CVC, and any ZIP, which keeps test fixtures short.
- Cons: It only covers the happy path. A checkout that only ever sees 4242 will never render a decline message, so broken error UI ships unnoticed. It is Visa only, so it says nothing about how your form handles a four digit Amex CVC.
Use it for: smoke tests, CI pipelines, demo environments, and any first pass after wiring up a new integration.
4000 0000 0000 0002: the generic decline
This card returns a generic decline. Stripe also publishes cards that map to specific decline codes, which matters because your UI should say something different for a lost card than for insufficient funds.
- Pros: Fast way to confirm that a failed Payment Intent surfaces the error object and that your front end shows the reason. The companion cards cover insufficient funds (4000 0000 0000 9995), lost card (4000 0000 0000 9987), stolen card (4000 0000 0000 9979), expired card (4000 0000 0000 0069), incorrect CVC (4000 0000 0000 0127), and a processing error (4000 0000 0000 0119).
- Cons: All are Visa, so brand specific handling stays untested. Decline codes attach to the API version you are pinned to, and some paths only fire after an authentication step.
Use it for: error state design, retry logic, dunning flows, and QA scripts that walk every rejection branch.
4000 0025 0000 3155 and 4000 0000 0000 3220: 3D Secure
The first requires 3D Secure authentication and then succeeds once you complete the challenge. The second drives the 3D Secure 2 challenge flow. Both need test mode plus a browser that can follow the redirect or open the challenge frame.
- Pros: Proves your handling of requires_action and the follow-up confirmation call. Catches the common bug where an order is marked paid before authentication returns.
- Cons: Cannot be exercised from a pure server side test without simulating the challenge. Slower and noisier in CI than a plain success card.
Use it for: Strong Customer Authentication testing, subscription signup flows, and any market where the challenge is mandatory.
Brand coverage: 5555 5555 5555 4444, 3782 822463 10005, 6011 1111 1111 1117
These cover Mastercard, American Express, and Discover respectively, and each has a different card length and CVC rule.
- Pros: Exposes hardcoded assumptions about 16 digit numbers and 3 digit CVCs. Amex uses a four digit CVC and a 15 digit number, which breaks naive validation.
- Cons: Success only, so pair each with a decline card if you want full coverage. Brand rules change, so confirm the numbers against current documentation before you bake them into a fixture.
Use it for: form validation, card brand icons, and layout checks where number length changes the UI.
Rules that keep test data honest
- Use test mode API keys everywhere outside production, and never point a development build at a live key.
- Never enter a real card number into a test environment. Stripe test cards are published specifically so you do not have to.
- Keep test numbers in a fixture file, not scattered through source, so a documentation change is a one line edit.
- Assert on the decline code, not on the human readable message, which can be reworded.
- Verify numbers against Stripe's current testing documentation at the start of each quarter, since card lists and API versions drift.