tldr: Every Stripe test card number in one place. Copy a number, set any future expiry and any CVC, and you can trigger a successful charge, a specific decline, a 3D Secure challenge, or a dispute without ever touching a real card. Test cards only work with test API keys. They never work in live mode.
Stripe gives you a set of fake card numbers that behave like real ones inside test mode. Each number maps to a known outcome. 4242 4242 4242 4242 always succeeds. 4000 0000 0000 0002 always declines. A handful of others force 3D Secure, or land the payment in a dispute, or get blocked by Radar as fraud.
The rules are the same for every card. Use any future expiry date, such as 12/34. Use any three-digit CVC, or four digits for American Express. Use any postal code. The card number is the only thing that decides what happens.
This page is a reference. The tables below are the card numbers you copy into a checkout form or a PaymentMethod call. The last section covers the part most guides skip: how to run these cards inside an automated suite so payment regressions get caught before a customer hits them.
How Stripe test mode works
Test mode is a full parallel environment. It has its own API keys, its own dashboard data, and its own objects. Nothing you do in test mode touches real money or a real bank.
Two things gate it. First, you have to use your test secret key (the one prefixed sk_test_) or test publishable key (pk_test_). A test card sent with a live key fails. Second, real card numbers are rejected in test mode, and Stripe's agreement forbids sending real card details to test with. The separation is deliberate and strict.
That strictness is the whole point. You get to exercise the ugly paths, a declined card, a stolen card, a chargeback, on demand and repeatably, without waiting for a real customer to hit them.
Successful test cards by brand
Use these when you want the charge to go through. Every brand your customers might use has a test number so you can confirm your form accepts it and your logic handles the resulting PaymentIntent.
| Brand | Card number |
|---|---|
| Visa | 4242 4242 4242 4242 |
| Visa (debit) | 4000 0566 5566 5556 |
| Mastercard | 5555 5555 5555 4444 |
| Mastercard (2-series) | 2223 0031 2200 3222 |
| Mastercard (debit) | 5200 8282 8282 8210 |
| Mastercard (prepaid) | 5105 1051 0510 5100 |
| American Express | 3782 822463 10005 |
| American Express | 3714 496353 98431 |
| Discover | 6011 1111 1111 1117 |
| Diners Club | 3056 9300 0902 0004 |
| JCB | 3566 0020 2036 0505 |
| UnionPay | 6200 0000 0000 0005 |
Cards that trigger declines
This is the set most teams under-test. A payment form that only ever sees 4242 looks finished and is not. These numbers force specific failures, each with the exact decline_code Stripe returns, so you can confirm your UI shows the right message instead of a generic error.
| Scenario | Card number | Decline code |
|---|---|---|
| Generic decline | 4000 0000 0000 0002 | generic_decline |
| Insufficient funds | 4000 0000 0000 9995 | insufficient_funds |
| Lost card | 4000 0000 0000 9987 | lost_card |
| Stolen card | 4000 0000 0000 9979 | stolen_card |
| Expired card | 4000 0000 0000 0069 | expired_card |
| Incorrect CVC | 4000 0000 0000 0127 | incorrect_cvc |
| Processing error | 4000 0000 0000 0119 | processing_error |
| Card velocity exceeded | 4000 0000 0000 6975 | card_velocity_exceeded |
The message a customer sees on an insufficient-funds decline should not read the same as an expired-card decline. Each of these cards lets you prove that in a test, not in production.
3D Secure and authentication test cards
Strong Customer Authentication means some payments trigger a challenge step. If your checkout does not handle the challenge and its result, the payment stalls and the customer leaves. These cards force the authentication flow so you can test both the approved and the abandoned path.
| Scenario | Card number |
|---|---|
| Authentication required (unless card is saved) | 4000 0025 0000 3155 |
| Authentication required on every payment | 4000 0027 6000 3184 |
| 3DS required, authentication succeeds | 4000 0000 0000 3220 |
| 3DS supported but not required | 4000 0000 0000 3055 |
| Authentication required, then declines | 4000 0084 0000 1629 |
Run the last one on purpose. A card that passes the challenge and then declines is a real customer scenario, and it is exactly where half-built checkout flows break.
Fraud and dispute test cards
Two more categories round out the surface. Radar cards let you test how your system reacts when a payment is flagged or blocked. Dispute cards let a charge succeed and then turn into a chargeback so you can test your webhook handling and your evidence flow.
| Scenario | Card number |
|---|---|
| Always blocked by Radar (highest risk) | 4100 0000 0000 0019 |
| Elevated risk, may be queued for review | 4000 0000 0000 9235 |
| Charge succeeds, then disputed as fraudulent | 4000 0000 0000 0259 |
| Charge succeeds, then disputed as not received | 4000 0000 0000 2685 |
| Charge succeeds, receives early fraud warning | 4000 0000 0000 5423 |
Disputes arrive as asynchronous webhook events, sometimes days after the charge in real life and immediately in test. If a dispute event silently fails in your handler, you find out when a bank pulls the funds. These cards let you rehearse that instead.
Testing Stripe cards in an automated checkout suite
A copy-paste card into a manual test confirms the flow works once. It does not confirm the flow still works after next week's redesign, or on the mobile breakpoint, or when the 3DS modal renders differently.
That is the job of an end-to-end suite. A good one drives a real browser through the actual checkout, enters the test card, waits for the authentication challenge if one appears, and asserts the customer lands on the right confirmation or sees the right decline message. It runs on every deploy, not once.
This is where Bug0 fits. A Bug0 forward-deployed engineer authors your checkout coverage on Passmark, our AI testing engine, including the decline and 3D Secure paths above, and the engine injects the test card values at runtime and re-resolves the steps when your UI changes. You provide staging access and the test keys. Payment regressions get caught in a pull request, while the change is still cheap to fix.
The point of the whole test-card system is that failure is a first-class scenario, not an edge case you hope never happens. An automated suite is what keeps that promise on every release.
FAQs
Where do I find a Stripe test card number?
Stripe publishes them in its testing documentation, and the tables above cover the common ones. The most-used card is 4242 4242 4242 4242, which always succeeds. Pair any test card with a future expiry, any CVC, and any postal code.
Do Stripe test cards work in live mode?
No. Test cards only work with test API keys. Once you switch to live keys, Stripe rejects them, and real transactions require real card details. Stripe's agreement also prohibits testing with real cards in live mode.
What is the 4242 4242 4242 4242 card?
It is Stripe's default successful Visa test card. It approves every charge in test mode, which makes it the happy-path card. Testing only with 4242 is the most common gap, because it never exercises declines or authentication.
What expiry date and CVC should I use with test cards?
Any expiry date in the future works, for example 12/34. Use any three-digit CVC, or four digits for American Express. Postal code can be any value. Only the card number determines the outcome.
How do I test a declined payment on Stripe?
Use a decline card such as 4000 0000 0000 0002 for a generic decline or 4000 0000 0000 9995 for insufficient funds. Each returns a specific decline_code, so you can confirm your checkout shows the correct message for each failure instead of a single generic error.
Can I automate testing with Stripe test cards?
Yes. An end-to-end suite can drive your checkout in a real browser, enter a test card, handle any 3D Secure challenge, and assert the outcome on every deploy. Bug0 builds and maintains that coverage for you, including the decline and authentication paths.
