- Blog
- Stripe Bookkeeping
- Stripe Test Cards: 4242 Card Numbers, Declines & 3D Secure
Stripe Test Cards: 4242 Card Numbers, Declines & 3D Secure

You're wiring up a Stripe integration. You need to know it works before a real customer hits it. That's what stripe test cards are for. They're fake card numbers that trigger one exact result: a good charge, a decline, a 3D Secure prompt, or a fraud flag. No real money moves.
Every card here is for Stripe's testing environments and your test API keys (sk_test_… and pk_test_…). Switch to your test environment. Pick a number below, and Stripe runs the exact case that card is built for. We show you where to grab those keys and where to paste them further down, in the "Where to paste your test cards" section.
This page covers the main card types Stripe documents: working payments by brand, 3D Secure, declines by code, fraud and Radar, disputes, refunds, country cards, and the pm_card_* PaymentMethods. Every number below is copied straight from Stripe's own docs.
What are Stripe test cards?
Stripe test cards are fake card numbers built for test mode. Each number triggers one set result: a good charge, a decline, a 3D Secure prompt, or a fraud flag. The best-known one is 4242 4242 4242 4242. Use any future expiry date, any 3-digit CVC (4 for Amex), and any ZIP code. No real money moves.
What is a Stripe test card number?
A Stripe test card number is a fake card you use with Stripe's test API keys (sk_test_…/pk_test_…) in a testing environment. Each one triggers one exact result: a good charge, a decline, a 3D Secure prompt, or a fraud flag. The universal success card is4242 4242 4242 4242(Visa). It works with any future expiry date, any 3-digit CVC, and any ZIP code. Stripe documents dozens of these numbers, one for nearly every case you'd want to test before going live. None of them move real money. The Stripe Services Agreement prohibits testing in live mode with real card details. Test transactions settle instantly. In live mode, settling to your available balance can take multiple days.
Key Takeaways
- The one card to memorize:
4242 4242 4242 4242is Stripe's universal Visa success card. Reach for it any time you just need a charge that works. - CVC, expiry, and ZIP are throwaway values: any 3-digit CVC (4 digits for Amex), any future expiry date, any ZIP code. A Stripe test card CVC is never checked against anything real.
- Test cards are for test mode only: use them with your test API keys (
sk_test_…/pk_test_…). The Stripe Services Agreement prohibits testing in live mode with real card details. - The number picks the result: decline codes, 3D Secure prompts, and Radar fraud flags each get their own card. Match the row to the case you're testing, not just the happy path.
- PaymentMethod tokens skip the raw number entirely: pass
pm_card_visaor a similar token as thepayment_methodvalue when you test at the API level. - Keep test and live keys apart: you can't process live payments while your integration still uses test API keys, so check which mode you're in before you paste anything into your checkout form.
Grab-and-go: the test cards you'll copy most
Categorizes the routine. Flags what needs you.
See Growthy on a sample book. Read-only bank access.
Get started with GrowthyHere are the numbers you'll reach for again and again. Each block has a copy button, so you can grab the raw digits and paste them straight into your checkout form or API call. The full reference tables are further down.
Visa, successful payment (the one to memorize):
14242424242424242
Mastercard, successful payment:
15555555555554444
American Express, successful payment (use a 4-digit CVC):
1378282246310005
Generic decline:
14000000000000002
Insufficient funds decline:
14000000000009995
Requires 3D Secure authentication:
14000002760003184
PaymentMethod token for API tests (no raw number needed):
1pm_card_visa
Expiry is any future date, CVC is any 3 digits (4 for Amex), and the ZIP is any value. These work only in test mode. The tables below cover every other card Stripe documents.
Stripe test cards for successful payments (every brand)
Use these test credit card numbers any time you need a charge that works, across every card network your customers might use, not just Visa.
Brand | Card number | CVC |
|---|---|---|
Visa |
| Any 3 digits. |
Visa (debit) |
| Any 3 digits. |
Mastercard |
| Any 3 digits. |
Mastercard (2-series) |
| Any 3 digits. |
Mastercard (debit) |
| Any 3 digits. |
Mastercard (prepaid) |
| Any 3 digits. |
American Express |
| Any 4 digits. |
American Express (alt) |
| Any 4 digits. |
Discover |
| Any 3 digits. |
Discover (alt) |
| Any 3 digits. |
Discover (debit) |
| Any 3 digits. |
Diners Club |
| Any 3 digits. |
Diners Club (14-digit) |
| Any 3 digits. |
JCB |
| Any 3 digits. |
UnionPay |
| Any 3 digits. |
UnionPay (debit) |
| Any 3 digits. |
UnionPay (19-digit) |
| Any 3 digits. |
See the full list and current test-mode keys on Stripe's site.
3D Secure test cards
Need a 3D Secure test card? Some cards must pass 3D Secure under SCA rules. These numbers force each result on purpose, so your whole auth flow gets tested, not just the happy path.
Scenario | Card number | Behavior |
|---|---|---|
Requires authentication (SCA) on all transactions |
| Always prompts 3DS. |
Requires auth for off-session unless set up |
| 3DS unless saved for future use. |
Already set up for off-session |
| On-session needs auth; off-session succeeds. |
Auth required, then declined |
| Authenticates, then declines. |
3DS2 required, succeeds |
| Must complete 3DS2. |
3DS2 required, declined after auth ( |
| Completes 3DS, then declines. |
3DS supported but not required |
| Optional 3DS. |
Supports 3DS but not enrolled (no prompt) |
| Same as basic Visa. |
Does not support 3DS |
| Amex, proceeds without auth. |
See how the 3D Secure flow works in Stripe's docs.
Declined payments: test every decline code
A generic decline card covers catch-all error handling in your checkout. To run a stripe declined card test for one exact reason, like insufficient_funds or stolen_card, use the matching row below. That tests the specific decline your code will hit, not a generic stand-in.
Scenario | Card number | Error code returned |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Attaches to Customer, then charge fails |
|
|
See the full decline code list on Stripe's site.
Fraud and Radar test cards
These numbers trigger Stripe Radar's risk score and the AVS/CVC checks. Use them if your code reacts to a risk level or a check failure, like a manual-review queue.
Scenario | Card number |
|---|---|
Always blocked (risk = highest) |
|
Highest risk |
|
Elevated risk |
|
CVC check fails |
|
ZIP / postal check fails |
|
Address line 1 check fails |
|
Both ZIP and line 1 fail |
|
Dispute and chargeback test cards
Use these to test your dispute logic, including the charge.dispute.created webhook, without waiting on a real chargeback. With default account settings, each charge succeeds and is then disputed.
Dispute type | Card number |
|---|---|
Fraudulent (3DS-protected) |
|
Product not received |
|
Inquiry |
|
Early fraud warning |
|
Multiple disputes |
|
Refund test cards (async outcomes)
Refunds aren't always instant. These two cards test the pending-then-succeeds and succeeds-then-fails paths, through the refund.updated and refund.failed webhooks.
Scenario | Card number |
|---|---|
Refund pending, then succeeds ( |
|
Refund succeeds, then fails ( |
|
Country-specific test cards
This is a sample, not the full list. For every country Stripe covers, use the link below.
Country | Card number | Brand |
|---|---|---|
United States |
| Visa. |
Canada |
| Visa. |
Mexico |
| Visa. |
Brazil |
| Visa. |
United Kingdom |
| Visa. |
France |
| Visa. |
Germany |
| Visa. |
Australia |
| Visa. |
India |
| Visa. |
Japan |
| Visa. |
See the full country list on Stripe's site.
PaymentMethod test tokens (no raw card numbers)
Pass a PaymentMethod as the payment_method value instead of a raw card number when you write test code against the API. Stripe's own example is pm_card_visa, sent with a test secret key when creating a PaymentIntent. Same result as the matching card, no card number needed.
- Success by brand:
pm_card_visa,pm_card_visa_debit,pm_card_mastercard,pm_card_amex,pm_card_discover,pm_card_diners,pm_card_jcb,pm_card_unionpay. - Declines:
pm_card_visa_chargeDeclined,pm_card_visa_chargeDeclinedInsufficientFunds,pm_card_visa_chargeDeclinedLostCard,pm_card_visa_chargeDeclinedStolenCard,pm_card_chargeDeclinedExpiredCard,pm_card_chargeDeclinedIncorrectCvc,pm_card_chargeDeclinedProcessingError,pm_card_visa_chargeDeclinedVelocityLimitExceeded. - 3D Secure:
pm_card_threeDSecure2Required,pm_card_threeDSecureRequiredChargeDeclined,pm_card_threeDSecureOptional,pm_card_authenticationRequired. - Disputes:
pm_card_createDispute,pm_card_createDisputeProductNotReceived,pm_card_createDisputeInquiry. - Fraud:
pm_card_radarBlock,pm_card_riskLevelHighest,pm_card_riskLevelElevated,pm_card_cvcCheckFail,pm_card_avsZipFail. - Where to find more: every card table on Stripe's testing page has a "PaymentMethods" tab next to "Card numbers", with the PaymentMethod for each scenario.
- Why bother: Stripe doesn't recommend using card numbers directly in API calls or server-side code, even in testing environments. If you do, your code might not be PCI-compliant when you go live.
- Default behavior: a PaymentMethod isn't attached to a Customer by default.
Older tokens use tok_ (for example tok_visa, tok_visa_chargeDeclined). Most tables on Stripe's page also have a "Tokens" tab for older integrations built on tokens. New test code is better served by PaymentMethods, per the PCI note above.
Where to paste your test cards (test keys and setup)
Stripe card testing uses your test API keys, never live ones. You get a publishable key and a secret key for testing, and they start with sk_test_… (secret) and pk_test_… (publishable). When you're ready to go live, you replace both test keys with live ones.
Never mix test and live keys in the same setup. You can't process live payments while your integration still uses test keys. And a live key sitting in what you think is a test run is how a real charge slips through. Store live keys in a secrets vault or environment variables, not in source code.
Once you're in test mode, enter any card number from this page in the Dashboard or in any payment form. Same screen your real customers see, fake number, exact result. Test transactions settle instantly and land in your available test balance. In live mode, settling to your available balance can take multiple days.
One rule doesn't bend: don't use real card details to test, even to "just check" something. The Stripe Services Agreement prohibits testing in live mode using real payment method details, and a real card won't show you anything a test card can't already show.
See test-mode keys and the full setup steps on Stripe's site.
Frequently asked questions
Quick answers to what people ask most about stripe test cards, straight from Stripe's own docs.
Are Stripe test cards real card numbers?
No. They're numbers Stripe reserves for testing, tied to no real account and no real person. They only work with test-mode keys, and they never move money. Nothing in test mode settles to a real account, on either side. Test mode exists so you can run every case without moving a dollar. The best-known one is 4242 4242 4242 4242, the standard Visa success card used all through this guide.
What is the Stripe test card 4242 4242 4242 4242?
It's Stripe's universal Visa success card. Pair it with any future expiry date, any 3-digit CVC, and any ZIP code, and the charge goes through. Use it with your test API keys (sk_test_… and pk_test_…), not live ones. Reach for it any time you just need a payment that works, before you test the harder cases.
What CVC and expiry do I use for a Stripe test card?
Any future date works (for example 12/34), any 3-digit CVC (4 digits for American Express), and any ZIP or postal code. Stripe doesn't check these against anything real in test mode. They're throwaway values, so you can type whatever is easy to remember when you test your checkout form.
Can I use my own card in Stripe test mode?
No. Stripe says not to use real card details for testing, and the Stripe Services Agreement prohibits testing in live mode with real payment method details. Use test keys with test cards, and live keys with real cards. Live-mode charges move real money. Test-mode charges never do. You also can't process live payments while your integration still uses test keys.
How do I test a declined payment with a Stripe test card?
Use generic_decline, 4000 0000 0000 0002, for a catch-all decline. To test one exact reason, like insufficient_funds, use the matching row instead: 4000 0000 0000 9995 triggers insufficient_funds on the nose. Test several cards, because your real customers won't all hand you the same one. They'll pay with Visa, Mastercard, Amex, and Discover, and some will get declined, trigger 3D Secure, or trip a fraud rule. One card, one happy path, leaves every one of those cases unchecked.
What are the Stripe 3D Secure test cards?
4000 0027 6000 3184 always prompts 3D Secure, no matter what. To test auth that only fires for off-session charges unless the card was saved first, use 4000 0025 0000 3155 instead. The 3D Secure table above lists every case, including 3DS2 that succeeds and 3DS2 that declines after auth.
Where can I find the full official list of Stripe test card numbers?
Stripe's own testing page at docs.stripe.com/testing is the source, and it covers more country cards and edge cases than fit on this page. This guide sorts and links back to that list. Stripe's docs stay the last word. Use this page to grab the common numbers fast, and Stripe's page for anything not listed here.
Where Growthy fits in
Get your checkout working, and money starts moving for real. It doesn't land as line items, though. It lands as one net payout. Picture a made-up example: a single $3,847.92 deposit that's actually 47 charges minus 3 refunds minus $127 in fees, all bundled together. Matching that number back to the sales, refunds, and fees behind it is a real bookkeeping problem, and it's not one this guide tries to solve.
This guide comes from Growthy. We build bookkeeping software that pulls bank feeds through Plaid, scores its confidence on each categorization, and syncs categories both ways with QuickBooks Online. You review the low-confidence ones. For how the Stripe fees hit your chart of accounts, why one payout isn't one sale, and what to do when your deposits don't match your sales, start with our Stripe bookkeeping guide. Past testing and into real revenue? Get started with Growthy.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice.
See It Work on Your Data
See Growthy on a sample book. Read-only bank access.
Bobby Huang • Partner, SDO CPA LLC / CEO, Growthy
Partner at SDO CPA. Bobby still reconciles real client books and builds Growthy from that operating work.
View author profileGrowthy content is written and reviewed by people who keep real books. Worked examples come from real bookkeeping scenarios, and product claims are checked against what the product does today. Our editorial guidelines cover how we source, verify, and update every article.
Keep reading

Stripe Chargeback Accounting: Refunds, Disputes, and Fees
Stripe refunds and chargebacks look similar in payouts but hit the books differently. Use the right entries, reserve logic, and fee treatment here now.

Best Stripe Accounting Tools Compared (2026)
A practitioner comparison of A2X, Synder, Bookkeep, Acodei, native Stripe-QBO sync, and Growthy with its Stripe payout report, with pricing, model breakdowns, and a decision table.

Stripe Payouts vs. Individual Transactions: Which Booking Method?
Payout-level summary journal entries vs. individual transaction booking in Stripe: when each method works, where individual booking breaks, and why most bookkeepers land on the summary approach.