Learn about the different methods to test your integration before going live.
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.
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.
Number
Brand
4242424242424242
Visa
4000056655665556
Visa (debit)
5555555555554444
Mastercard
2223003122003222
Mastercard (2-series)
5200828282828210
Mastercard (debit)
5105105105105100
Mastercard (prepaid)
378282246310005
American Express
371449635398431
American Express
6011111111111117
Discover
6011000990139424
Discover
30569309025904
Diners Club
38520000023237
Diners Club
3566002020360505
JCB
6200000000000005
UnionPay
Token
Brand
tok_visa
Visa
tok_visa_debit
Visa (debit)
tok_mastercard
Mastercard
tok_mastercard_debit
Mastercard (debit)
tok_mastercard_prepaid
Mastercard (prepaid)
tok_amex
American Express
tok_discover
Discover
tok_diners
Diners Club
tok_jcb
JCB
tok_unionpay
UnionPay
Payment Method
Brand
pm_card_visa
Visa
pm_card_visa_debit
Visa (debit)
pm_card_mastercard
Mastercard
pm_card_mastercard_debit
Mastercard (debit)
pm_card_mastercard_prepaid
Mastercard (prepaid)
pm_card_amex
American Express
pm_card_discover
Discover
pm_card_diners
Diners Club
pm_card_jcb
JCB
pm_card_unionpay
UnionPay
Each 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).
Testing ACH
You can mimic successful and failed ACH charges using the following bank routing and account numbers:
Routing number: 110000000
Account number:
000123456789 (success)
000111111116 (failure upon use)
000111111113(account closed)
000222222227 (NSF/insufficient funds)
000333333335 (debit not authorized)
000444444440 (invalid currency)
To mimic successful and failed bank account verifications, use these meaningful amounts:
[32, 45] (success)
[any other number combinations] (failure)
International test card numbers and tokens
You can use any of the following test cards to simulate a successful payment for different billing countries.
Number
Token
Payment Method
Country
Brand
4000000760000002
tok_br
pm_card_br
Brazil (BR)
Visa
4000001240000000
tok_ca
pm_card_ca
Canada (CA)
Visa
4012888888881881
n/a
n/a
Canada (CA)
Visa
4000004840000008
tok_mx
pm_card_mx
Mexico (MX)
Visa
Number
Token
Payment Method
Country
Brand
4000000400000008
tok_at
pm_card_at
Austria (AT)
Visa
4000000560000004
tok_be
pm_card_be
Belgium (BE)
Visa
4000002080000001
tok_dk
pm_card_dk
Denmark (DK)
Visa
4000002460000001
tok_fi
pm_card_fi
Finland (FI)
Visa
4000002500000003
tok_fr
pm_card_fr
France (FR)
Visa
4000002760000016
tok_de
pm_card_de
Germany (DE)
Visa
4000003720000005
tok_ie
pm_card_ie
Ireland (IE)
Visa
4000003800000008
tok_it
pm_card_it
Italy (IT)
Visa
4000004420000006
tok_lu
pm_card_lu
Luxembourg (LU)
Visa
4000005280000002
tok_nl
pm_card_nl
Netherlands (NL)
Visa
4000005780000007
tok_no
pm_card_no
Norway (NO)
Visa
4000006200000007
tok_pt
pm_card_pt
Portugal (PT)
Visa
4000006430000009
tok_ru
pm_card_ru
Russian Federation (RU)
Visa
4000007240000007
tok_es
pm_card_es
Spain (ES)
Visa
4000007520000008
tok_se
pm_card_se
Sweden (SE)
Visa
4000007560000009
tok_ch
pm_card_ch
Switzerland (CH)
Visa
4000008260000000
tok_gb
pm_card_gb
United Kingdom (GB)
Visa
4000058260000005
tok_gb_debit
pm_card_gb_debit
United Kingdom (GB)
Visa (debit)
Number
Token
Payment Method
Country
Brand
4000000360000006
tok_au
pm_card_au
Australia (AU)
Visa
4000001560000002
tok_cn
pm_card_cn
China (CN)
Visa
4000003440000004
tok_hk
pm_card_hk
Hong Kong (HK)
Visa
4000003920000003
tok_jp
pm_card_jp
Japan (JP)
Visa
3530111333300000
tok_jcb
pm_card_jcb
Japan (JP)
JCB
4000004580000002
tok_my
pm_card_my
Malaysia (MY)
Visa
4000005540000008
tok_nz
pm_card_nz
New Zealand (NZ)
Visa
4000007020000003
tok_sg
pm_card_sg
Singapore (SG)
Visa
Regulatory test card numbers
Use the following card information to test payments affected by regional regulations such as Strong Customer Authentication (SCA).
Number
Description
4000002500003155
This card requires authentication when saving a card and when processing one-time payments without setting up the card beforehand.
In live mode, Stripe dynamically determines when a particular transaction requires authentication due to regional regulations such as Strong Customer Authentication.
4000002760003184
This card requires authentication on all transactions, regardless of how the card is set up.
4000008260003178
This card requires authentication, but payments will be declined with an insufficient_funds failure code after successful authentication.
Payment Method
Description
pm_card_authenticationRequiredOnSetup
This card requires authentication when saving a card and when processing one-time payments without setting up the card beforehand.
In live mode, Stripe dynamically determines when a particular transaction requires authentication due to regional regulations such as Strong Customer Authentication.
pm_card_authenticationRequired
This card requires authentication on all transactions, regardless of how the card is set up.
This card requires authentication, but payments will be declined with an insufficient_funds failure code after successful authentication.
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.
Number
3D Secure usage
Description
4000000000003220
Required
3D Secure 2 authentication must be completed for the payment to be successful.
By default, your Radar rules will request 3D Secure 2 authentication for this card.
4000000000003063
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.
4000008400001629
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.
4000000000003055
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.
4242424242424242
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.
378282246310005
Not supported
3D Secure is not supported on this card and cannot be invoked.
The PaymentIntent will proceed without performing authentication.
Token
3D Secure usage
Description
tok_threeDSecure2Required
Required
3D Secure 2 authentication must be completed for the payment to be successful.
Use this card to test that your integration is ready to support
Strong Customer AuthenticationStrong Customer Authentication (SCA) is a new regulatory requirement coming into effect on September 14, 2019 which will impact many European online payments. It requires customers to use two-factor authentication like 3D Secure to verify their purchase.
requirements in Europe. By default, your Radar rules will request 3D Secure 2
authentication for this card.
tok_threeDSecureRequired
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.
tok_threeDSecureRequiredChargeDeclined
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.
tok_threeDSecureOptional
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.
tok_visa
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.
tok_amex_threeDSecureNotSupported
Not supported
3D Secure is not supported on this card and cannot be invoked.
The PaymentIntent will proceed without performing authentication.
Payment Method
3D Secure usage
Description
pm_card_threeDSecure2Required
Required
3D Secure 2 authentication must be completed for the payment to be successful.
Use this card to test that your integration is ready to support
Strong Customer AuthenticationStrong Customer Authentication (SCA) is a new regulatory requirement coming into effect on September 14, 2019 which will impact many European online payments. It requires customers to use two-factor authentication like 3D Secure to verify their purchase.
requirements in Europe. By default, your Radar rules will request 3D Secure 2
authentication for this card.
pm_card_threeDSecureRequired
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.
pm_card_threeDSecureRequiredChargeDeclined
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.
pm_card_threeDSecureOptional
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.
pm_card_visa
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.
pm_card_amex_threeDSecureNotSupported
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 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).
Number
Description
4000000000000077
Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
4000000000000093
Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.
Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
4000000000009235
Results in a charge with a risk_level of elevated.
4000000000004954
Results in a charge with a risk_level of highest.
4100000000000019
Results in a charge with a risk_level of highest. The charge is blocked as it's considered fraudulent.
4000000000000002
Charge is declined with a card_declined code.
4000000000009995
Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
4000000000009987
Charge is declined with a card_declined code. The decline_code attribute is lost_card.
4000000000009979
Charge is declined with a card_declined code. The decline_code attribute is stolen_card.
4000000000000069
Charge is declined with an expired_card code.
4000000000000127
Charge is declined with an incorrect_cvc code.
4000000000000119
Charge is declined with a processing_error code.
4242424242424241
Charge is declined with an incorrect_number code as the card number fails the Luhn check.
Token
Description
tok_bypassPending
Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
tok_domesticPricing
Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.
Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
tok_riskLevelElevated
Results in a charge with a risk_level of elevated.
tok_riskLevelHighest
Results in a charge with a risk_level of highest.
tok_chargeDeclined
Charge is declined with a card_declined code.
tok_chargeDeclinedInsufficientFunds
Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
tok_chargeDeclinedFraudulent
Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
tok_chargeDeclinedIncorrectCvc
Charge is declined with an incorrect_cvc code.
tok_chargeDeclinedExpiredCard
Charge is declined with an expired_card code.
tok_chargeDeclinedProcessingError
Charge is declined with a processing_error code.
Payment Method
Description
pm_card_bypassPending
Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
pm_card_domesticPricing
Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.
Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
pm_card_riskLevelElevated
Results in a charge with a risk_level of elevated.
pm_card_riskLevelHighest
Results in a charge with a risk_level of highest.
pm_card_chargeDeclined
Charge is declined with a card_declined code.
pm_card_chargeDeclinedInsufficientFunds
Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
pm_card_chargeDeclinedFraudulent
Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
pm_card_chargeDeclinedIncorrectCvc
Charge is declined with an incorrect_cvc code.
pm_card_chargeDeclinedExpiredCard
Charge is declined with an expired_card code.
pm_card_chargeDeclinedProcessingError
Charge is declined with a processing_error code.
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:
Number
Description
4000000000000259
With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
4000000000001976
With default account settings, charge succeeds, only to be disputed as an inquiry.
Token
Description
tok_createDispute
With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
tok_createDisputeInquiry
With default account settings, charge succeeds, only to be disputed as an inquiry.
Payment Method
Description
pm_card_createDispute
With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
pm_card_createDisputeInquiry
With default account settings, charge succeeds, only to be disputed as an inquiry.
The following evidence, when submitted in the uncategorized_text, produces specific actions that are useful for testing the dispute flow:
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.
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.
Account Number
Description
AT611904300234573201
The charge status transitions from pending to succeeded.
AT861904300235473202
The charge status transitions from pending to failed.
AT591904300235473203
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
BE62510007547061
The charge status transitions from pending to succeeded.
BE68539007547034
The charge status transitions from pending to failed.
BE08510007547063
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
DK5000400440116243
The charge status transitions from pending to succeeded.
DK8003450003179681
The charge status transitions from pending to failed.
DK9300400440116245
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
FR1420041010050500013M02606
The charge status transitions from pending to succeeded.
FR8420041010050500013M02607
The charge status transitions from pending to failed.
FR5720041010050500013M02608
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
DE89370400440532013000
The charge status transitions from pending to succeeded.
DE62370400440532013001
The charge status transitions from pending to failed.
DE35370400440532013002
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
IE29AIBK93115212345678
The charge status transitions from pending to succeeded.
IE02AIBK93115212345679
The charge status transitions from pending to failed.
IE51AIBK93115212345670
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
IT40S0542811101000000123456
The charge status transitions from pending to succeeded.
IT60X0542811101000000123456
The charge status transitions from pending to failed.
IT83S0542811101000000123458
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
LU280019400644750000
The charge status transitions from pending to succeeded.
LU980019400644750001
The charge status transitions from pending to failed.
LU710019400644750002
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
NL39RABO0300065264
The charge status transitions from pending to succeeded.
NL91ABNA0417164300
The charge status transitions from pending to failed.
NL82RABO0300065266
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
PT50000201231234567890154
The charge status transitions from pending to succeeded.
PT23000201231234567890155
The charge status transitions from pending to failed.
PT93000201231234567890156
The charge status transitions from pending to succeeded, but a dispute is immediately created.
Account Number
Description
ES0700120345030000067890
The charge status transitions from pending to succeeded.
ES9121000418450200051332
The charge status transitions from pending to failed.
ES5000120345030000067892
The charge status transitions from pending to succeeded, but a dispute is immediately created.
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 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.