Testing ACH

International test card numbers and tokens

You can use any of the following test cards to simulate a successful payment for different billing countries.

Regulatory test card numbers

Use the following card information to test payments affected by regional regulations such as Strong Customer Authentication (SCA).

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