Test your integration
This page includes test card numbers and other information to make sure your integration works as planned. Use it to trigger different flows in your integration and ensure they are handled accordingly.
Payment Intents API
When using the Payment Intents API with Stripe’s client libraries and SDKs, ensure that:
- Authentication flows are triggered when required (use the regulatory test card numbers and PaymentMethods.)
- No authentication (default U.S. card):
4242 4242 4242 4242. - Authentication required:
4000 0027 6000 3184.
- No authentication (default U.S. card):
- The PaymentIntent is created with an idempotency key to avoid erroneously creating duplicate PaymentIntents for the same purchase.
- Errors are caught and displayed properly in the UI.
Charges API
When using the Charges API with Stripe’s client libraries and SDKs, ensure that:
- The
cardElement is passed correctly tocreateTokenin yoursubmithandler. - 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.
Server-side code
In your server-side code, 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, replace your test publishable and secret API keys with live ones. Live payments cannot be processed if your integration is still using your test keys.
Basic test card numbers
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 basic 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 IDs when testing your integration and creating charges, instead of passing card information directly to the API. Using these test IDs 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 test ID 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
You can use any of the following test cards to simulate a successful payment for different billing countries.
Regulatory (3D Secure) test card numbers
The following card information tests payments affected by regional regulations such as Strong Customer Authentication (SCA). Use it to test saving cards with the Setup Intents API.
3D Secure test card numbers and tokens
Not all cards support 3D Secure or require you to redirect the customer to their card issuer’s authentication page. Use the following card information to test 3D Secure payments—be aware that 3D Secure redirects won’t occur for payments created directly in the Stripe Dashboard.
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)
Cartes Bancaires test card numbers
In test mode, you can use the test cards below to simulate a Cartes Bancaires charge:
| Number | Description |
|---|---|
| Creates a Cartes Bancaires card payment method co-branded with Visa. | |
| Creates a Cartes Bancaires card payment method co-branded with Mastercard. |
Disputes
In test mode, you can use the test cards below to simulate a disputed transaction:
Submit either of the following values for uncategorized_text to test a won or lost dispute outcome:
| Evidence | Description |
|---|---|
winning_evidence | The dispute is closed and marked as won. Your account is credited the amount of the charge and related fees. |
losing_evidence | The dispute is closed and marked as lost. Your account is not credited. |
You can also use these values to test dispute outcomes in the Dashboard. Enter one of these values into the Additional Information field during evidence submission and then click Submit evidence.
Link with Stripe
Don’t store real user data in test mode Link accounts. Treat them as if they’re publicly available, because these accounts are tied to your publishable key.
You can create test mode accounts for Link with Stripe using any valid email address. You can use fixed one-time passcode values for authenticating test mode accounts, as outlined below:
| Value | Outcome |
|---|---|
| Any other 6 digits not listed below | Authentication succeeds. |
| 000001 | Authentication fails because the one-time passcode is invalid. |
| 000002 | Authentication fails because the one-time passcode is expired. |
| 000003 | Authentication fails because the maximum number of attempts is exceeded. |
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.
The rate limit in test mode is lower than the one in live mode. 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].
BECS Direct Debit in Australia
You can create a test PaymentIntent that either succeeds or fails by doing the following:
- Create a test PaymentMethod with the test BSB
000-000and a test account number from the list below. - Use the resulting PaymentMethod in a
confirmAuBecsDebitPaymentrequest to create the test charge.
Test account numbers
| Account Number | Description |
|---|---|
000123456 | The PaymentIntent status transitions from processing to succeeded. The mandate status remains active. |
900123456 | The PaymentIntent status transitions from processing to succeeded (with a three-minute delay). The mandate status remains active. |
111111113 | The PaymentIntent status transitions from processing to requires_payment_method with an account_closed failure code. The mandate status will become inactive. |
111111116 | The PaymentIntent status transitions from processing to requires_payment_method with a no_account failure code. The mandate status will become inactive. |
222222227 | The PaymentIntent status transitions from processing to requires_payment_method with a refer_to_customer failure code. The mandate status will remain active. |
922222227 | The PaymentIntent status transitions from processing to requires_payment_method with a refer_to_customer failure code (with a three-minute delay). The mandate status will remain active. |
333333335 | The PaymentIntent status transitions from processing to requires_payment_method with a debit_not_authorized failure code. The mandate status will become inactive. |
SEPA Direct Debit
You can create a test PaymentIntent that either succeeds or fails by doing the following:
- Create a test PaymentMethod with a test account number.
- Use the resulting PaymentMethod in a
confirmSepaDebitPaymentrequest to create the test charge.
Test account numbers
Webhooks
To 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 easily trigger events with the Stripe CLI or Stripe for Visual Studio Code. 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.