Testing

• Test card numbers
• Bitcoin
• Debugging JavaScript
• Disputes
• Managed Accounts
• Rate limits
• Webhooks

When using Stripe.js, you should ensure that:

• The card number, expiration, CVC and amount are set correctly in createToken
• In the response handler for createToken, card errors are handled and displayed properly
• Only a valid token is passed to your server as part of payment form submission
• Sensitive card details (number, expiration and CVC) are not included in form data submitted to your server

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

• All values submitted from the payment form are valid and expected
• 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

Genuine card information cannot be used in test mode. Instead, use any of the following test cards to create a successful payment:

International test card numbers

You can use any of the following test cards to simulate a successful transaction for different issuing 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.

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

Bitcoin

In test mode, you can use the following test emails (set on BitcoinReceiver objects) to test different edge cases. By default, a receiver is always paid 3 seconds after creation.

Debugging JavaScript

There are many tools for tracking down problems in your client side code. We recommend reading about the Chrome Web Inspector. Should you need it, you can also load a debug version of Stripe.js from https://js.stripe.com/v2/stripe-debug.js.

Disputes

In test mode, you can use the test card 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:

Managed Accounts

Use these test routing and account numbers, debit card numbers, and tax IDs to trigger certain events during your testing of Managed Accounts. The following bank account details can only be used when creating or updating Managed Accounts via the API in test mode.

Routing numbers

Account numbers

Debit card numbers

Use these test debit card numbers to test transfers to a debit card. These can only be used with test secret keys.

Tax IDs

Pass in any name and one of these tax IDs (valid as both SSN or EIN) for the desired verification behavior.

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.

Webhooks

You can send test webhooks to your integration's endpoint within your account's webhooks settings. The event data contained within one of 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 results in legitimate webhooks being sent. For instance, creating a charge triggers the charge.succeeded webhook that contains the charge data. The resulting event data can then be verified using the API.

If you don't have a server set up to receive webhooks but want to see example webhook requests, we suggest using a service like RequestBin to inspect the requests we send.