Stripe Test Card Numbers

How Stripe test cards work

Stripe test cards only work with your test API keys (they start with pk_test_ and sk_test_) or in a Stripe sandbox. They never move money. In live mode the same numbers are rejected, and Stripe’s terms forbid testing live mode with real card details.

For card details, use any future expiry date such as 12/34 and any three-digit CVC (four digits for American Express). Other fields, such as name or postal code, can be anything. There is one exception: if you want a CVC or postal code check to fail, you have to send a value, because Stripe skips checks for empty fields.

In server-side code and automated tests, Stripe recommends test PaymentMethod IDs instead of raw numbers, for example pm_card_visa, pm_card_visa_chargeDeclined or pm_card_threeDSecure2Required. Sending raw card numbers from your server can put the code in PCI scope once it goes live. Use the raw numbers below in Stripe Elements, Checkout or Payment Links, where the customer types them.

Declined payments

Each card returns the error code shown. Cards that simulate issuer declines can’t be attached to a Customer; use 4000 0000 0000 0341 when you need a card that attaches successfully and then fails when charged. Stripe also documents incorrect_number for a card number that fails the Luhn check — any 4242 card with a wrong last digit.

Radar fraud and verification checks

Radar results depend on your Radar rules and settings. Cards for optional controls (Adaptive 3DS, dynamic risk thresholds, free-trial abuse) only behave differently when that control is enabled, so they are left out here.

3D Secure and authentication

Only these cards reliably exercise 3D Secure. Other test cards can still trigger it, but they return attempt_acknowledged. Payments created in the Dashboard never redirect to a 3DS page.

Testing Stripe payments step by step

1. Switch the Dashboard to test mode or a sandbox and copy the test publishable and secret keys into your development environment.
2. Pay with 4242 4242 4242 4242 in your checkout to confirm the happy path end to end, including webhooks such as payment_intent.succeeded.
3. Repeat with each decline card and check that your UI shows a useful message for card_declined, expired_card and incorrect_cvc.
4. Run the 3D Secure cards through your real payment flow (not the Dashboard) to make sure the authentication modal opens and your code handles requires_action.
5. Use a different card per independent scenario: card-level state from one test can affect the next one.

Common errors and fixes

“Your card was declined. Your request was in live mode, but used a known test card.”

You are using live keys. Swap in the pk_test_ / sk_test_ keys.

No 3D Secure prompt appears

Use a card from the 3D Secure table and confirm the payment from your integration. Generic test cards and Dashboard payments do not trigger a challenge.

CVC check never fails

Send a CVC value with 4000 0000 0000 0101. Without a CVC the check is skipped.

HTTP 429 in tests

Test mode has stricter rate limits than live mode. Slow down parallel test runs.

Sources

Every number on this page was copied from Stripe’s official documentation and passes the Luhn check. Checked October 2026; gateways change their test data from time to time, so if a number stops working, check the source:

• Stripe docs – Testing