To confirm that your integration works correctly, simulate transactions without moving any money using special values in test mode.
Test cards let you simulate several scenarios:
- Successful payments by card brand or country
- Card errors due to declines, fraud, or invalid data
- Disputes and refunds
- Authentication with 3D Secure and PINs
Testing non-card payments works similarly. Each payment method has its own special values. Because of rate limits, we don’t recommend using test mode to load-test your integration. Instead, see our documentation on load testing.
How to use test cards
Any time you work with a test card, use test API keys in all API calls. This is true whether you’re serving a payment form to test interactively or writing test code.
Don’t use real card details. The Stripe Services Agreement prohibits testing in live mode using real payment method details. Use your test API keys and the card numbers below.
When testing interactively, use a card number, such as 4242 4242 4242 4242. Enter the card number in the Dashboard or in any payment form.
- Use a valid future date, such as 12/34.
- Use any three-digit CVC (four digits for American Express cards).
- Use any value you like for other form fields.
When writing test code, use a
PaymentMethod such as pm_card_visa instead of a card number. We don’t recommend using card numbers directly in API calls or server-side code, even in test mode. If you do use them, your code might not be PCI-compliant when you go live. By default, a
PaymentMethod isn’t attached to a Customer.
Most integrations don’t use Tokens anymore, but we make test Tokens such as tok_visa available if you need them.
When you’re ready to take your integration live, replace your test publishable and secret API keys with live ones. You can’t process live payments if your integration is still using your test API keys.
Cards by brand
To simulate a successful payment, use test cards from the following list. The billing country for each test card is set to the United States. If you need to create test card payments using cards for other billing countries, use international test cards.
Cross border fees are assessed based on the country of the card issuer. While each of the cards in this section use US as the billing country, cards where the issuer country isn’t the US (such as JCB and UnionPay) might be subject to a cross border fee, even in test mode.
Most Cartes Bancaires and eftpos cards are co-branded with either Visa or Mastercard. The test cards in the following table simulate successful payments with co-branded cards.
Cards by country
To simulate successful payments from many countries, use test cards from the following sections.
Use these test cards to simulate successful payments from North and South America.
Europe and Middle East
Use these test cards to simulate successful payments from Europe and the Middle East.
Strong Customer Authentication regulations require 3D Secure authentication for online payments within the European Economic Area. The test cards in this section simulate a payment that succeeds without authentication. We recommend also testing scenarios that involve authentication, using 3D Secure test cards.
Use these test cards to simulate successful payments from Asia and the Pacific.
To test subscriptions that require mandates and pre-debit notifications, see India recurring payments.
To test your integration’s error-handling logic by simulating payments that the issuer declines for various reasons, use test cards from this section. Using one of these cards results in a card error with the given error code and decline code.
To simulate an incorrect CVC, you must provide one using any three-digit number. If you don’t provide a CVC, Stripe doesn’t perform the CVC check, so the check can’t fail.
Stripe’s fraud prevention system, Radar, can block payments when they have a high risk level or fail verification checks. You can use the cards in this section to test your Radar settings. You can also use them to test how your integration responds to blocked payments.
Each card simulates specific risk factors. Your Radar settings determine which risk factors cause it to block a payment. Blocked payments result in card errors with an error code of fraud.
To simulate a failed CVC check, you must provide a CVC using any three-digit number. To simulate a failed postal code check, you must provide any valid postal code. If you don’t provide those values, Radar doesn’t perform the corresponding checks, so the checks can’t fail.
To test errors resulting from invalid data, provide invalid details. You don’t need a special test card for this. Any invalid value works. For instance:
invalid_expiry_month: Use an invalid month, such as 13
invalid_expiry_year: Use a year up to 50 years in the past, such as 95
invalid_cvc: Use a two-digit number, such as 99
incorrect_number: Use a card number that fails the Luhn check, such as
To simulate winning or losing the dispute, respond with one of the evidence values from the table below.
- If you respond using the API, pass the value from the table as uncategorized_text.
- If you respond in the Dashboard, enter the value from the table in the Additional information field. Then, click Submit evidence.
|The dispute is closed and marked as won. Your account is credited the amount of the charge and related fees.|
|The dispute is closed and marked as lost. Your account isn’t credited.|
In live mode, refunds are asynchronous: a refund can appear to succeed and later fail, or can appear as
pending at first and later succeed. To simulate refunds with those behaviors, use the test cards in this section. (With all other test cards, refunds succeed immediately and don’t change status after that.)
To send the funds from a test transaction directly to your available balance, use the test cards in this section. Other test cards send funds from a successful payment to your pending balance.
3D Secure authentication
3D Secure requires an additional layer of authentication for credit card transactions. Use the test cards in this section to simulate payment flows that involve authentication. Other test cards are not enrolled in 3D Secure, which means that no authentication can occur.
3D Secure redirects won’t occur for payments created directly in the Stripe Dashboard. Instead, use your integration’s own frontend or an API call.
Authentication and setup
To simulate payment flows that include authentication, use the test cards in this section. Some of these cards can also be set up for future payments, or have already been.
Support and availability
Stripe requests authentication when required by regulation, or when triggered by your Radar rules or custom code. Even if authentication is requested, it can’t always be performed—for instance, the customer’s card might not be enrolled, or an error might occur. Use the test cards in this section to simulate various combinations of these factors.
3D Secure mobile challenge flows
In a mobile payment, several challenge flows for authentication—where the customer has to interact with prompts in the UI—are available. Use the test cards in this section to trigger a specific challenge flow for test purposes. These cards aren’t useful in browser-based payment forms or in API calls. In those environments, they work but don’t trigger any special behavior. Because they’re not useful in API calls, we don’t provide any
Token values to test with.
|Out of band||3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with Out of Band UI.|
|One time passcode||3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with One Time Passcode UI.|
|Single select||3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with single-select UI.|
|Multi select||3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with multi-select UI.|
Payments with PINs
Use the test cards in this section to simulate successful in-person payments where a PIN is involved. There are many other options for testing in-person payments, including a simulated reader and physical test cards. See Test Stripe Terminal for more information.
To test webhooks, you have two options:
- Perform actions in test mode that send legitimate events to your endpoint. For instance, to trigger the charge.succeeded event, you can use a test card that produces a successful charge.
- Trigger events using the Stripe CLI or using Stripe for Visual Studio Code.
If your requests in test mode begin to receive
429 HTTP errors, make them less frequently. These errors come from our rate limiter, which is stricter in test mode than in live mode.
We don’t recommend load testing your integration using the Stripe API in test mode. Because the load limiter is stricter in test mode, you might see errors that you wouldn’t see in production. See our documentation on load testing for an alternative approach.
Any time you use a test non-card payment method, use test API keys in all API calls. This is true whether you’re serving a payment form you can test interactively or writing test code.
Different payment methods have different test procedures:
To test your integration’s redirect-handling logic by simulating a payment that uses a redirect flow (for example, iDEAL), use a supported payment method that requires redirects.
To create a test
PaymentIntent that either succeeds or fails:
- Navigate to the payment methods settings in the Dashboard and enable a supported payment method by clicking Turn on in test mode.
- Collect payment details.
- Submit the payment to Stripe.
- Authorize or fail the test payment.
Make sure that the page (corresponding to
return_url) on your website provides the status of the payment.