Use our available test information to trigger different flows in your integration and ensure they are handled accordingly. If you're using the Payment Intents API, use the 3D Secure test card numbers and tokens to trigger the 3D Secure authentication challenge in your integration.

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

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

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.

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 and tokens

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 authentication from the customer's card issuer.

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

To fully test your integration, perform actions using the API (in test mode) to send legitimate events to your endpoint. For instance, creating a charge triggers the charge.succeeded event that contains the charge data. You can then use the API to verify the resulting event data. If you're migrating to the Payment Intents API, also see Monitoring a PaymentIntent with Webhooks.

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