Test your Stripe integration
Learn about the different methods for testing your Stripe integration before launching it.
IS HE NOT A DEVELOPER?
Hire a certified expert here either do it yourself or use a pre-designed solution created by one of our verified partners (no code required).
This page includes test card numbers and other information to ensure your integration works as intended. Use it to trigger different flows in your integration and ensure they are handled accordingly.
Payment intent API
When using the Payment Intent API with Stripe's client libraries and SDKs, ensure that:
- Authentication flows are activated when necessary (use the regulatory test card numbers and payment methods).
- Without authentication (default US card): 4242 4242 4242 4242.
- Authentication required: 4000 0027 6000 3184.
- The payment attempt is created with a key of idempotency key to avoid the erroneous creation of duplicate payment attempts for the same purchase.
- Errors are detected and displayed correctly in the user interface.
Charges API
When using the Charges API When using Stripe's client libraries and SDKs, ensure that:
- The card element is successfully passed to create Token in your send controller.
- In the response controller for creating Token, card errors are handled and displayed correctly.
- Only valid tokens are passed to your server as part of the payment form submission.
Server-side code
In your server-side code, make sure that:
- All requests are being processed successfully. You may find it helpful to view your account events and logs while testing your integration.
- All API errors are handled correctly.
- The relevant webhooks are handled correctly.
- When you're ready to go live with your integration, replace your test secret and publishable API keys with live keys. Live payments cannot be processed if your integration is still using your test keys.
Basic test card numbers
The original card information cannot be used in test mode. Instead, use any of the following test card numbers, a valid future expiration date, and any random CVC number to create a successful payment. The billing country for each basic test card is set to the USA. If you need to create test card payments with cards for other billing countries, please use our international test cards.
|
Number |
Brand |
CVC |
Date |
|---|---|---|---|
|
|
View | any 3 digits | Any date in the future |
|
|
Visa (debit) | any 3 digits | Any date in the future |
|
|
Mastercard | any 3 digits | Any date in the future |
|
|
Mastercard (2-series) | any 3 digits | Any date in the future |
|
|
Mastercard (debit) | any 3 digits | Any date in the future |
|
|
Mastercard (prepaid) | any 3 digits | Any date in the future |
|
|
American Express | Any 4 digits | Any date in the future |
|
|
American Express | Any 4 digits | Any date in the future |
|
|
Discover | any 3 digits | Any date in the future |
|
|
Discover | any 3 digits | Any date in the future |
|
|
Diners Club | any 3 digits | Any date in the future |
|
|
Diners Club (14 digit card) | any 3 digits | Any date in the future |
|
|
JCB | any 3 digits | Any date in the future |
|
|
UnionPay | any 3 digits | Any date in the future |
We recommend using our test IDs when testing your integration and creating charges, rather than passing card information directly to the API. Using these test IDs instead of card numbers helps ensure your production integration is PCI compliant and doesn't handle card information directly. Each test ID is human-readable and represents card information that has been tokenized using 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.
|
Number |
Token |
Payment Method |
Country |
Brand |
|---|---|---|---|---|
|
|
tok_us |
pm_card_us |
United States (US) | View |
|
|
tok_br |
pm_card_br |
Brazil (BR) | View |
|
|
tok_ca |
pm_card_ca |
Canada (CA) | View |
|
|
tok_mx |
pm_card_mx |
Mexico (MX) | View |
Regulatory test card numbers (3D Secure)
The following card information tests payments affected by regional regulations, such as Strong Customer Authentication (SCA). Use it to test savings cards with the Setup Intents API.
|
Number |
Description |
|---|---|
|
|
This card requires authentication for one-time paymentsHowever, if you Set up this card and use the saved card for subsequent off-session payments, no further authentication is needed. |
|
|
This card requires authentication on all transactions, regardless of how the card is set up. |
|
|
This card requires authentication for one-time payments. All payments will be declined with an insufficient_funds failure code even after being successfully authenticated or previously set-up. |
|
|
This card requires authentication for one-time and other on-session payments. However, all off-session payments will succeed as if the card has been previously set-up. |
3D Secure test card numbers and tokens
Not all cards support 3D Secure or require you to redirect the customer to the card issuer's authentication page. Use the card information below to test 3D Secure payments; note that 3D Secure redirects will not occur for payments created directly in the Stripe Dashboard.
|
Number |
3D Secure usage |
Description |
|---|---|---|
|
|
required | 3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card. |
|
|
required | 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card. |
|
|
required | 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card. |
|
|
required | 3D Secure authentication is required, but the 3D Secure lookup request will fail with a processing error. Payments will be declined with a card_declined failure code. By default, your Radar rules will request 3D Secure authentication for this card. |
|
|
Supported | 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card. |
|
|
Supported | 3D Secure authentication may still be performed, but is not required. However, attempts to perform 3D Secure result in a processing error. By default, your Radar rules will not request 3D Secure authentication for this card. |
|
|
Supported | 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card. |
|
|
Not supported | 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication. |
All other Visa and Mastercard test cards do not require authentication from the customer's card issuer.
Testing specific answers and errors
You can use the following test cards to create payments that produce specific responses, useful for testing different scenarios and error codes. Verification checks are only executed when the required information is provided (for example, a CVC code must be provided for the CVC checker to be set to fail).
|
Number |
Description |
|---|---|
|
|
Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance). |
|
|
Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance). |
|
|
Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing. |
|
|
The address_line1_check and address_zip_check verifications fail. If your account is blocking payments that fail postal code validationThe charge is declined. |
|
|
Charge succeeds but the address_line1_check Verification fails. |
|
|
The address_zip_check verification fails. If your account is blocking payments that fail postal code validationThe charge is declined. |
|
|
Charge succeeds but the address_zip_check and address_line1_check verifications are both unavailable. |
|
|
Charge succeeds but refunding a captured charge fails asynchronously with a failure_reason of expired_or_canceled_card. Note that because refund failures are asynchronous, the refund will appear to be successful at first and will only have the failed status on subsequent fetches. We also notify you of refund failures using the charge.refund.updated webhook event. |
|
|
Charge succeeds but refunds are initially held in the pending state. Some time later the refund is released from pending and sends a charge.refund.updated webhook event. |
|
|
If a CVC number is provided, the cvc_check fails. If your account is blocking payments that fail CVC code validationThe charge is declined. |
|
|
Attaching this card to a Customer object succeeds, but attempts to charge the customer fail. |
|
|
Results in a charge with a risk_level of elevated. |
|
|
Results in a charge with a risk_level of highest. |
|
|
Results in a charge with a risk_level of highest. The charge is blocked as it's considered fraudulent. |
|
|
Charge is declined with a card_declined code. |
|
|
Charge is declined with a card_declined The code. decline_code attribute is insufficient_funds. |
|
|
Charge is declined with a card_declined The code. decline_code attribute is lost_card. |
|
|
Charge is declined with a card_declined The code. decline_code attribute is stolen_card. |
|
|
Charge is declined with an expired_card code. |
|
|
Charge is declined with an incorrect_cvc code. |
|
|
Charge is declined with a processing_error code. |
|
|
Charge is declined with an incorrect_number code as the card number fails the Luhn check. |
|
|
Charge succeeds and returns a brand_product of MWE. |
By default, including address or CVC data along with the card number ensures successful address and CVC checks. If this information is not specified, the checks will be invalid. Any future expiration date will be considered valid.
You can also provide details of invalid cards to test for specific error codes resulting from incorrect information. For example:
- invalid_expiry_month: Use an invalid month (for example, 13)
- invalid_expiry_year: Use a year in the past (e.g., 1970)
- invalid_cvc: Use a two-digit number (for example, 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. |
Disputas
In test mode, you can use the test cards below to simulate a disputed transaction:
Submit any of the following uncategorized text values to prove a dispute result won or lost:
|
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 the results of disputes in the panelEnter one of these values in the field Additional Information during the evidence submission process and then click on Send evidence.
Link with Stripe
You can create trial accounts for Link with Stripe using any valid email address. You can use fixed, one-time access code values to authenticate trial accounts, as described 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. |
Fare limits
It is highly unlikely that users will experience any rate limits with normal API usage, even at high volumes. The most common causes of rate limits are errors, massive data retrievals, or extreme load testing.
If your requests start receiving HTTP 429 errors, reduce the frequency of your requests. It's safe to retry each failed request, as rate limiting occurs before any other action and prevents the request from being processed. When reducing your request frequency, we recommend exponential backoff, waiting one second before retrying. If your request continues to receive the same response, wait two seconds, then four seconds, and so on.
The frequency limit in test mode is lower than in live mode. If you have tariff limits but cannot determine the reason, please let us know.
Fonts
Use the following information when testing payments through the sources.
Redirect sources
By creating a test source object that uses a redirect flow (for example, iDEAL), you can follow the URL returned in the redirect field [url]. This leads to a Stripe page that displays information about the API request and where you can authorize or cancel the payment.
Upon authorizing the payment, you will be redirected to the URL specified in the redirect [return_url].
BECS Direct Debit in Australia
You can create a test PaymentIntent that succeeds or fails by doing the following:
Create a test payment method using the test BSB 000-000 and a test account number from the list below.
Use the resulting PaymentMethod in a confirmAuBecsDebitPayment request to create the test charge.
Account proof numbers
|
Account number |
Description |
|---|---|
000123456 |
The PaymentIntent status transitions from processing to succeededThe 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 on 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. |
Webhooks
See Webhooks to learn how to install and configure an endpoint.
To test your integration, perform actions using the API (in test mode) to send legitimate events to your endpoint. For example, creating a charge triggers the `charge.succeeded` event, which contains the charge data. You can easily trigger events using 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 Intent API, also see Monitoring a Payment Intent with Webhooks.
You can also send test events to your integration endpoint within your account's webhooks settings. However, the event data contained in these events is fabricated and not available in the API; its purpose is solely to test that your endpoint is functioning and configured correctly.
[hover_color align=»center» background=»» background_hover=»» border=»» border_hover=»» border_width=»0px» padding=»60px 60px» link=»https://selfish.com.mx/servicios/» target=»» class=»cta-blog themecolorbg» style=»»] Ready to take your ecommerce to another level? [/hover_color]
