Stripe Test Cards
Introduction
If you’re integrating Stripe, Stripe test cards are the safest, fastest way to simulate real payments—without moving real money or touching live customer data. This guide shows you how to use the canonical numbers (including 4242) and a complete Stripe test cards list to validate success paths, catch edge cases early, and ship with confidence.
You’ll see how these numbers behave across brands and countries, and how they interact with modern compliance needs like 3D Secure (3DS) / SCA.
We’ll go beyond copy-pasting numbers. You’ll learn how to structure automated and manual tests, verify webhook flows and idempotency, and rehearse negative scenarios such as declines, disputes, and refunds. Building for point-of-sale?
We’ll cover Stripe Terminal test options. Running subscriptions? We’ll use Stripe Billing with Test Clock to fast-forward renewals, proration, dunning, and cancellations—so you can preview the full customer lifecycle in minutes.
What Are Stripe Test Cards?
Stripe provides special card numbers that behave like real cards in test mode. You can test successful payments, failures, regulatory flows like 3D Secure 2, and more. Always use test API keys with test cards; never use real card data in live mode for testing.
Quick Start: The “4242” Happy-Path Payment
To smoke-test your checkout:
- Use card number 4242 4242 4242 4242
- Any future expiry date (e.g., 12/34)
- Any 3-digit CVC (4 digits for Amex)
- Any billing ZIP/postal code
You should see a successful PaymentIntent and a new payment in your Stripe Dashboard. This is the fastest way to confirm your end-to-end path works.
Why 4242? It’s Stripe’s default Visa test card. It also appears as 3DS supported but unenrolled—useful to confirm that your flow won’t try to authenticate when it’s not required.
Stripe Test Cards List (Most-Used Numbers by Brand)
The table below covers the core set developers and QA teams use most often. Enter any future expiry and any CVC (Amex: 4 digits).
Common “Success” Cards
- 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 (15 digits)
- American Express (alt): 3714 496353 98431
- Discover: 6011 1111 1111 1117
- Discover (alt): 6011 0009 9013 9424
- Diners Club: 3056 9300 0902 0004
- Diners (14-digit): 3622 7206 2716 67
- JCB: 3566 0020 2036 0505
- UnionPay: 6200 0000 0000 0005
- UnionPay (debit): 6200 0000 0000 0047
- UnionPay (19-digit): 6205 5000 0000 0000 004
Need co-branded cards (Cartes Bancaires/eftpos)? Stripe also publishes those test numbers. They behave like their co-brand in test mode.
Stripe Test Cards Documentation (How to Read It Fast)
Stripe’s official Testing page aggregates:
- Cards by brand, country, and product (HSA/FSA, co-branded).
- Flows for declines, fraud signals, disputes, refunds, 3DS, and in-person PIN.
- PaymentMethod tokens like pm_card_visa and scenario tokens for automated tests.
Bookmark the “Testing” and “Accept a payment” pages while building your checklist. They’re the source of truth (and updated by Stripe).
3D Secure (3DS) with Stripe Test Cards
Modern Europe/UK payments often require Strong Customer Authentication (SCA), which commonly uses 3D Secure 2. Stripe provides specific test cards to force or simulate 3DS behavior so you can validate your UX and fallbacks.
The 3DS “Must-Know” Numbers
- 3DS Required → OK: 4000 0000 0000 3220
Payment succeeds if the customer completes the challenge. - 3DS Required → Declined after auth: 4000 0084 0000 1629
Auth completes, but issuer declines the charge (simulate post-auth decline). - 3DS Required → Processing Error: 4000 0084 0000 1280
Lookup fails; Stripe returns a processing error. - 3DS Supported (optional) → OK: 4000 0000 0000 3055
- 3DS Supported → Error: 4000 0000 0000 3097
- 3DS Supported → Unenrolled: 4242 4242 4242 4242
No challenge presented even if requested, because the card isn’t enrolled. - 3DS Not Supported: 3782 822463 10005 (Amex test card)
Tip: Stripe’s test environment renders a mock challenge page where you can approve or cancel the authentication—great for verifying your success/failure UI paths.
Off-Session & “Remember Me” Scenarios
To test off-session behavior (e.g., saving a card for future charges), use:
- “Authenticate unless set up” card: 4000 0025 0000 3155
Requires authentication for off-session charges unless the card was properly set up with a mandate (e.g., via SetupIntent).
If your 3DS test card seems to trigger every time, check you’re using 3155, not a card that forces challenges on all payments (older advice mentioned a different suffix). Stripe’s support note clarifies the difference.
Declines, Disputes, Refunds, and Fraud Simulations
You should test negative paths as thoroughly as positive ones:
- Declines & errors: Stripe publishes card numbers that simulate issuer declines (e.g., card_declined) or processing errors. Validate your error messaging and retry UX.
- Disputes (chargebacks): Use test flows to create disputes, respond with evidence, and verify webhook handling. Your ops team needs muscle memory before go-live.
- Refunds (async behavior): A special refund card simulates delayed or cancelable refunds so you can practice states beyond “succeeded”.
- Fraud signals & CAPTCHA: Stripe even offers captcha challenge test cards to confirm your UX handles extra friction.
International & Regulatory Coverage (SCA/PSD2)
Testing for the EU/UK means verifying SCA/3DS behavior and exemptions. Stripe provides country-specific PaymentMethods/tokens to simulate cross-border scenarios (for example, UK, DE, FR). Use these to ensure address/issuer country logic works as expected.
For background, SCA is mandated under PSD2 and typically requires two factors (knowledge, possession, inherence). Your integration should be ready for challenges and exemptions. For authoritative context, see the EBA’s RTS materials.
Stripe Terminal (In-Person) Test Cards
Building a POS or kiosk? You can:
- Use the simulated reader to run flows using simulated test cards in the SDKs.
- Order physical Stripe Terminal test cards to test real tap/insert/swipe behavior with your reader hardware.
Stripe Billing & Subscriptions: 4242 + Test Clock
For subscriptions, test free trials, renewals, and proration with test clocks, and attach a standard card (often 4242) to the customer in test mode. This lets you fast-forward time and confirm invoicing and retries.
How to Structure Your Automated Tests
Use a balanced mix of unit, integration, and E2E tests:
- Unit: Confirm you construct PaymentIntents/SetupIntents correctly and handle webhooks idempotently.
- Integration: Call Stripe’s APIs in test mode with scenario PaymentMethods like pm_card_visa, pm_card_threeDSecure2Required, and verify transitions (requires_action → succeeded, etc.).
- E2E: Drive a browser through your hosted fields or Checkout, cover happy-path (4242), 3DS required (3220), post-auth decline (1629), and unenrolled (4242) flows.
Troubleshooting FAQ
Why doesn’t the 3DS pop-up appear?
You may be using a card that’s unenrolled (like 4242), or your rules don’t request 3DS. Switch to a 3DS required card (3220) and ensure your code handles requires_action.
Every test payment asks for 3DS—why?
Some cards force a challenge on every transaction (or your rules are set to require 3DS). For “typical” one-off flows, use 4000 0000 0000 3055 (optional) or the 3155 off-session card described above.
Can I test country-specific cards?
Yes. Stripe provides brand/country PaymentMethods/tokens to simulate international issuers, useful for cross-border fees or SCA logic.
Is it okay to load-test with test cards?
Don’t use test mode for load testing; you may hit rate limits. Stripe documents alternatives and guidance.
Conclusion
Stripe test cards are the safest, fastest way to pressure-test payments across real-world conditions—brands, countries, 3D Secure/SCA, declines, disputes, refunds, off-session charges, in-person PIN, and subscriptions. Treat them like a flight simulator:
run happy paths, then break things on purpose to prove your app recovers cleanly.
Bake these cards into automated suites and manual playbooks. Cover end-to-end flows, webhook transitions, and idempotency on retries. Validate SCA edges (challenge success, failure, unenrolled), off-session mandates, and post-auth declines.
For subscriptions, use Test Clock to fast-forward invoices, dunning, proration, and cancellations.
Don’t stop at “payment succeeded.” Verify customer messaging, error copy, receipts, refunds, dispute evidence collection, and dashboard reconciliation.
Log scenario IDs per test so you can trace failures quickly. Keep runs in CI, seed consistent test data, and document a minimal smoke set for on-call.
Your turn: what tripped you up—3DS challenges looping, off-session declines, or dispute webhooks? Drop a concrete example (card, state, error code) in the comments, and we’ll map the exact reproduction steps and a fix.
Stay in touch to get more updates & alerts on Sosmodapks! Thank you
About the Author
