Testing

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.

Testing interactively

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.

Testing a form interactively with the test card number 4242 4242 4242 4242

Test code

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.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_4eC39HqLyjWDarjtT1zdp7dc
:" \
  -d amount=500 \
  -d currency=gbp \
  -d payment_method=pm_card_visa

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.

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.

Americas

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.

Asia-Pacific

Use these test cards to simulate successful payments from Asia and the Pacific.

Declined payments

To simulate payments that the issuer declines for various reasons, use test cards from this section. This can be useful for testing your integration’s error handling logic. Using one of these cards results in a card error with the given error code and decline code.

Fraud prevention

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.

Invalid data

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 4242424242424241

Disputes

To simulate a disputed transaction, use the test cards in this section. Then, to simulate winning or losing the dispute, provide winning or losing evidence.

Evidence

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.

Refunds

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.)

Available balance

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.

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 PaymentMethod or Token values to test with.

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.

Webhooks

To test webhooks, you have two options:

1. 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.
2. Trigger events using the Stripe CLI or using Stripe for Visual Studio Code.

Rate limits

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.

Non-card payments

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: