• Test card numbers and tokens
• Disputes
• Rate limits
• Sources
• Webhooks

When using Stripe.js and Elements, you should ensure that:

• The card Element is passed correctly to createToken in your submit handler
• In the response handler for createToken, card errors are handled and displayed properly
• Only valid tokens are passed to your server as part of payment form submission

In your server-side code, you should ensure that:

• All requests are being made successfully. You may find it useful to view your account's events and logs as you test your integration
• All API errors are handled properly
• Relevant webhooks are handled correctly

When you're ready to take your integration live, make sure that you replace your test publishable and secret API keys with live ones. Live payments cannot be processed if your integration is still using your test API keys. You can find your API key information in your account settings.

Test card numbers and tokens

Genuine card information cannot be used in test mode. Instead, use any of the following test card numbers, a valid expiration date in the future, and any random CVC number, to create a successful payment. Each test card's billing country is set to U.S. If you need to create test card payments using cards for other billing countries, use our international test cards.

We recommend using our test tokens when testing your integration and creating charges, instead of passing card information directly to the API. Using tokens in place of card numbers helps ensure your production integration is developed in a PCI compliant manner and is not going to handle card information directly. Each token is human-readable and represents card information that has been tokenized with our client-side libraries (e.g., Stripe Elements, Stripe.js).

International test card numbers and tokens

You can use any of the following test cards to simulate a successful payment for different billing countries. For countries that have separate domestic and international pricing (e.g., Australia), the fee calculated for test card payments is at the international rate.

3D Secure test card numbers

Not all cards support 3D Secure or require the customer be redirected to their card issuer's authentication page. Use the following card information to fully test 3D Secure payments.

All other Visa and Mastercard test cards do not require verification from the customer's card issuer. The 3D Secure Source status is immediately set to chargeable upon source creation.

Testing for specific responses and errors

The following test cards can be used to create payments that produce specific responses—useful for testing different scenarios and error codes. Verification checks only run when the required information is provided (e.g., for cvc_check to be set to fail, a CVC code must be provided).

By default, passing address or CVC data with the card number causes the address and CVC checks to succeed. If this information isn't specified, the value of the checks is null. Any expiration date in the future is considered valid.

You can also provide invalid card details to test specific error codes resulting from incorrect information being provided. For example:

• invalid_expiry_month: Use an invalid month (e.g., 13)
• invalid_expiry_year: Use a year in the past (e.g., 1970)
• invalid_cvc: Use a two digit number (e.g., 99)

Disputes

In test mode, you can use the test cards below to simulate a disputed transaction:

The following evidence, when submitted in the uncategorized_text, produces specific actions that are useful for testing the dispute flow:

Rate limits

It is extremely unlikely for users to experience any rate limits with normal usage of the API, even at high volume. The most common causes for a user to experience rate limits are bugs, bulk data fetches, or extreme load testing.

Should your requests begin to receive 429 HTTP errors, reduce the frequency of your requests. Each failed request is perfectly safe to retry as rate limiting takes place before any other action and prevents the request from being processed. When reducing your request frequency, we recommend an exponential backoff by first waiting one second before trying again. If your request continues to receive the same response, wait two seconds, then four seconds, etc.

Rate limits for both test and live modes are identical. Requests made in test mode are an accurate representation of what to expect when making live requests. If you are experiencing rate limits but are unable to determine why, please let us know.

Sources

Use the following information when testing payments using Sources.

Redirect sources

When creating a test Source object that uses a redirect flow (e.g., iDEAL), you can follow the URL returned in the redirect[url] field. This leads to a Stripe page that displays information about the API request, and where you can either authorize or cancel the payment.

Authorizing the payment redirects you to the URL specified in redirect[return_url].

SEPA Direct Debit

You can mimic a successful or failed charge by first creating a test source with one of the following test IBAN account numbers. Use the resulting source in a charge request to create a test charge that is either successful or failed.

Webhooks

You can send test webhooks to your integration's endpoint within your account's webhooks settings. The event data contained within these test webhooks is fabricated and not available in the API—its purpose is only to test that your endpoint is working and configured correctly.

To fully test your integration, perform actions using the API (in test mode) that cause legitimate webhooks to be sent. For instance, creating a charge triggers the charge.succeeded webhook that contains the charge data. You can then use the API to verify the resulting event data.

If you don't have a server set up to receive webhooks, but want to see example webhook requests, we suggest testing locally on your computer using a service like ngrok. This will allow you to inspect the requests we send.