Test Payments

Simulate payments to test your integration.

Simulate payments to test your integration.

To confirm that your integration works correctly, simulate transactions without moving any money using special values in test mode.

Test cards let you simulate several scenarios:

• Successful payments by card brand or country

• Card errors due to declines, fraud, or invalid data

• Disputes and refunds

• Authentication with 3D Secure and PINs

Testing non-card payments works similarly. Each payment method has its own special values. Because of rate limits, we don’t recommend using test mode to load-test your integration. Instead, see our documentation on load testing.

How to use test cards

Any time you work with a test card - it has to be used in Test Mode / Sandbox Mode. This is true whether you’re serving a payment form to test interactively or writing test code.

Common mistake

Don’t use real card details. Use your test API keys and the card numbers below.

Testing interactively

When testing interactively, use a card number, such as 4242 4242 4242 4242. Enter the card number in the Dashboard or in any payment form.

• Use a valid future date, such as 12/34.

• Use any three-digit CVC (four digits for American Express cards).

• Use any value you like for other form fields.

Testing a form interactively with the test card number 4242 4242 4242 4242

Test code

When writing test code, use a PaymentMethod such as pm_card_visa instead of a card number. We don’t recommend using card numbers directly in API calls or server-side code, even in test mode. If you do use them, your code might not be PCI-compliant when you go live. By default, a PaymentMethod isn’t attached to a Customer.

Most integrations don’t use Tokens any more, but we make test Tokens such as tok_visa available if you need them.

When you’re ready to take your integration live, replace your test publishable and secret API keys with live ones. You can’t process live payments if your integration is still using your test API keys.

Cards by brand

To simulate a successful payment for a specific card brand, use test cards from the following list.

Caution

Cross-border fees are assessed based on the country of the card issuer. Cards where the issuer country isn’t the US (such as JCB and UnionPay) might be subject to a cross-border fee, even in test mode.

Card Numbers

Card numbers

BRAND	NUMBER	CVC	DATE
Visa	4242 4242 4242 4242	Any 3 digits	Any future date
Visa (debit)	4000 0566 5566 5556	Any 3 digits	Any future date
Mastercard	5555 5555 5555 4444	Any 3 digits	Any future date
Mastercard (2-series)	2223 0031 2200 3222	Any 3 digits	Any future date
Mastercard (debit)	5200 8282 8282 8210	Any 3 digits	Any future date
Mastercard (prepaid)	5105 1051 0510 5100	Any 3 digits	Any future date
American Express	3782 822463 10005	Any 4 digits	Any future date
American Express	3714 496353 98431	Any 4 digits	Any future date
Discover	6011 1111 1111 1117	Any 3 digits	Any future date
Discover	6011 0009 9013 9424	Any 3 digits	Any future date
Discover (debit)	6011 9811 1111 1113	Any 3 digits	Any future date
Diners Club	3056 9300 0902 0004	Any 3 digits	Any future date
Diners Club (14-digit card)	3622 720627 1667	Any 3 digits	Any future date
BCcard and DinaCard	6555 9000 0060 4105	Any 3 digits	Any future date
JCB	3566 0020 2036 0505	Any 3 digits	Any future date
UnionPay	6200 0000 0000 0005	Any 3 digits	Any future date
UnionPay (debit)	6200 0000 0000 0047	Any 3 digits	Any future date
UnionPay (19-digit card)	6205 5000 0000 0000 004	Any 3 digits	Any future date

PaymentMethods

Tokens

Most Cartes Bancaires and eftpos cards are co-branded with either Visa or Mastercard. The test cards in the following table simulate successful payments with co-branded cards.

Card numbers

BRAND/CO-BRAND	NUMBER	CVC	DATE
Cartes Bancaires/Visa	4000 0025 0000 1001	Any 3 digits	Any future date
Cartes Bancaires/Mastercard	5555 5525 0000 1001	Any 3 digits	Any future date
eftpos Australia/Visa	4000 0503 6000 0001	Any 3 digits	Any future date
eftpos Australia/Mastercard	5555 0503 6000 0080	Any 3 digits	Any future date

PaymentMethods

Tokens

Cards by Country

To simulate successful payments from specific countries, use test cards from the following sections.

Card numbers

AMERICAS

COUNTRY	NUMBER	BRAND
United States (US)	4242 4242 4242 4242	Visa
Argentina (AR)	4000 0003 2000 0021	Visa
Brazil (BR)	4000 0007 6000 0002	Visa
Canada (CA)	4000 0012 4000 0000	Visa
Chile (CL)	4000 0015 2000 0001	Visa
Colombia (CO)	4000 0017 0000 0003	Visa
Costa Rica (CR)	4000 0018 8000 0005	Visa
Ecuador (EC)	4000 0021 8000 0000	Visa
Mexico (MX)	4000 0048 4000 8001	Visa
Mexico (MX)	5062 2100 0000 0009	Carnet
Panama (PA)	4000 0059 1000 0000	Visa
Paraguay (PY)	4000 0060 0000 0066	Visa
Peru (PE)	4000 0060 4000 0068	Visa
Uruguay (UY)	4000 0085 8000 0003	Visa

PaymentMethods

Tokens

Card numbers

EUROPE and MIDDLE EAST

Security tip

Strong Customer Authentication regulations require 3D Secure authentication for online payments within the European Economic Area. The test cards in this section simulate a payment that succeeds without authentication. We recommend also testing scenarios that involve authentication, using 3D Secure test cards.

United Arab Emirates (AE)	4000 0078 4000 0001	Visa
United Arab Emirates (AE)	5200 0078 4000 0022	Mastercard
Austria (AT)	4000 0004 0000 0008	Visa
Belgium (BE)	4000 0005 6000 0004	Visa
Bulgaria (BG)	4000 0010 0000 0000	Visa
Belarus (BY)	4000 0011 2000 0005	Visa
Croatia (HR)	4000 0019 1000 0009	Visa
Cyprus (CY)	4000 0019 6000 0008	Visa
Czech Republic (CZ)	4000 0020 3000 0002	Visa
Denmark (DK)	4000 0020 8000 0001	Visa
Estonia (EE)	4000 0023 3000 0009	Visa
Finland (FI)	4000 0024 6000 0001	Visa
France (FR)	4000 0025 0000 0003	Visa
Germany (DE)	4000 0027 6000 0016	Visa
Gibraltar (GI)	4000 0029 2000 0005	Visa
Greece (GR)	4000 0030 0000 0030	Visa
Hungary (HU)	4000 0034 8000 0005	Visa
Ireland (IE)	4000 0037 2000 0005	Visa
Italy (IT)	4000 0038 0000 0008	Visa
Latvia (LV)	4000 0042 8000 0005	Visa
Liechtenstein (LI)	4000 0043 8000 0004	Visa
Lithuania (LT)	4000 0044 0000 0000	Visa
Luxembourg (LU)	4000 0044 2000 0006	Visa
Malta (MT)	4000 0047 0000 0007	Visa
Netherlands (NL)	4000 0052 8000 0002	Visa
Norway (NO)	4000 0057 8000 0007	Visa
Poland (PL)	4000 0061 6000 0005	Visa
Portugal (PT)	4000 0062 0000 0007	Visa
Romania (RO)	4000 0064 2000 0001	Visa
Saudi Arabia (SA)	4000 0068 2000 0007	Visa
Slovenia (SI)	4000 0070 5000 0006	Visa
Slovakia (SK)	4000 0070 3000 0001	Visa
Spain (ES)	4000 0072 4000 0007	Visa
Sweden (SE)	4000 0075 2000 0008	Visa
Switzerland (CH)	4000 0075 6000 0009	Visa
United Kingdom (GB)	4000 0082 6000 0000	Visa
United Kingdom (GB)	4000 0582 6000 0005	Visa (debit)
United Kingdom (GB)	5555 5582 6555 4449	Mastercard

PaymentMethods

Tokens

Card numbers

ASIA PACIFIC ²

Regional considerations | India

To test subscriptions that require mandates and pre-debit notifications, see India recurring payments.

Australia (AU)	4000 0003 6000 0006	Visa
China (CN)	4000 0015 6000 0002	Visa
Hong Kong (HK)	4000 0034 4000 0004	Visa
India (IN)	4000 0035 6000 0008	Visa
Japan (JP)	4000 0039 2000 0003	Visa
Japan (JP)	3530 1113 3330 0000	JCB
Malaysia (my)	4000 0045 8000 0002	Visa
New Zealand (NZ)	4000 0055 4000 0008	Visa
Singapore (SG)	4000 0070 2000 0003	Visa
Taiwan (TW)	4000 0015 8000 0008	Visa
Thailand (TH)	4000 0076 4000 0003	Visa (credit)
Thailand (TH)	4000 0576 4000 0008	Visa (debit)

PaymentMethods

Tokens

Declined payments

To test your integration’s error-handling logic by simulating payments that the issuer declines for various reasons, use test cards from this section. Using one of these cards results in a card error with the given error code and decline code.

Common mistake

To simulate an incorrect CVC, you must provide one using any three-digit number. If you don’t provide a CVC, Stripe doesn’t perform the CVC check, so the check can’t fail.

Card numbers

DESCRIPTION	NUMBER	ERROR CODE	DECLINE CODE
Generic decline	4000 0000 0000 0002	card_declined	generic_decline
Insufficient funds decline	4000 0000 0000 9995	card_declined	insufficient_funds
Lost card decline	4000 0000 0000 9987	card_declined	lost_card
Stolen card decline	4000 0000 0000 9979	card_declined	stolen_card
Expired card decline	4000 0000 0000 0069	expired_card	n/a
Incorrect CVC decline	4000 0000 0000 0127	incorrect_cvc	n/a
Processing error decline	4000 0000 0000 0119	processing_error	n/a
Incorrect number decline	4242 4242 4242 4241	incorrect_number	n/a
Exceeding velocity limit decline	4000 0000 0000 6975	card_declined	card_velocity_exceeded

The cards in the previous table can’t be attached to a Customer object. To simulate a declined payment with a successfully attached card, use the next one.

DESCRIPTION	PAYMENTMETHOD	DETAILS
Decline after attaching	4000 0000 0000 0341	Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.

Payment Method

Tokens

Fraud prevention

Stripe’s fraud prevention system, Radar, can block payments when they have a high risk level or fail verification checks. You can use the cards in this section to test your Radar settings. You can also use them to test how your integration responds to blocked payments.

Each card simulates specific risk factors. Your Radar settings determine which risk factors cause it to block a payment. Blocked payments result in card errors with an error code of fraud.

Common mistake

To simulate a failed CVC check, you must provide a CVC using any three-digit number. To simulate a failed postal code check, you must provide any valid postal code. If you don’t provide those values, Radar doesn’t perform the corresponding checks, so the checks can’t fail.

Card numbers

DESCRIPTION	NUMBER	DETAILS
Always blocked	4100 0000 0000 0019	The charge has a risk level of “highest” Our Antifraud System always blocks it.
Highest risk	4000 0000 0000 4954	The charge has a risk level of “highest” Our Antifraud Systemmight block it depending on your settings.
Elevated risk	4000 0000 0000 9235	The charge has a risk level of “elevated”
CVC check fails	4000 0000 0000 0101	If you provide a CVC number, the CVC check fails. Our Antifraud System might block it depending on your settings.
Postal code check fails	4000 0000 0000 0036	If you provide a postal code, the postal code check fails. Our Antifraud System might block it depending on your settings.
Line1 check fails	4000 0000 0000 0028	The address line 1 check fails. The payment succeeds unless you block it with a custom Antifraud System rule.
Address checks fail	4000 0000 0000 0010	The address postal code check and address line 1 check both fail. Our Antifraud System might block it depending on your settings.
Address unavailable	40000 0000 0000044	The address postal code check and address line 1 check are both unavailable. The payment succeeds unless you block it with a custom rule.

PaymentMethods

Tokens

Invalid data

To test errors resulting from invalid data, provide invalid details. You don’t need a special test card for this. Any invalid value works. For instance:

• invalid_expiry_month: Use an invalid month, such as 13.

• invalid_expiry_year: Use a year up to 50 years in the past, such as 95.

• invalid_cvc: Use a two-digit number, such as 99.

• incorrect_number: Use a card number that fails the Luhn check, such as 4242424242424241.

Disputes

To simulate a disputed transaction, use the test cards in this section. Then, to simulate winning or losing the dispute, provide winning or losing evidence.

Card numbers

DESCRIPTION	NUMBER	DETAILS
Fraudulent	4000 0000 0000 0259	With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication.
Not received	4000 0000 0000 2685	With default account settings, charge succeeds, only to be disputed as product not received. This type of dispute isn’t protected after 3D Secure authentication.
Inquiry	4000 0000 0000 1976	With default account settings, charge succeeds, only to be disputed as an enquiry.
Warning	4000 0000 0000 5423	With default account settings, charge succeeds, only to receive an early fraud warning.
Multiple disputes	4000 0004 0400 0079	With default account settings, charge succeeds, only to be disputed multiple times.
Visa Compelling Evidence 3.0	4000 0004 0400 0038	With default account settings, charge succeeds, only to be disputed as a Visa Compelling Evidence 3.0 eligible dispute.

PaymentMethods

Tokens

Evidence

To simulate winning or losing the dispute, respond with one of the evidence values from the table below.

• If you respond using the API, pass the value from the table as uncategorized_text.

• If you respond in the Dashboard, enter the value from the table in the Additional information field. Then, click Submit evidence.

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 isn’t credited.

Refunds

In live mode, refunds are asynchronous: a refund can appear to succeed and later fail, or can appear as pending at first and later succeed. To simulate refunds with those behaviors, use the test cards in this section. (With all other test cards, refunds succeed immediately and don’t change status after that.)

Card numbers

DESCRIPTION	NUMBER	DETAILS
Asynchronous success	4000 0000 0000 7726	The charge succeeds. If you initiate a refund, its status begins as pending. Some time later, its status transitions to succeeded and sends a refund.updated event.
Asynchronous failure	4000 0000 0000 5126	The charge succeeds. If you initiate a refund, its status begins as succeeded. Some time later, its status transitions to failed and sends a refund.failed event.

PaymentMethods

Tokens

You can cancel a card refund only by using the Dashboard. In live mode, you can cancel a card refund within a short but nonspecific period of time. Test mode simulates that period by allowing you to cancel a card refund within 30 minutes.

Available balance

To send the funds from a test transaction directly to your available balance, use the test cards in this section. Other test cards send funds from a successful payment to your pending balance.

Card Numbers

DESCRIPTION	NUMBER	DETAILS
Bypass pending balance	4000 0000 0000 0077	The US charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.
Bypass pending balance	4000 0037 2000 0278	The international charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.

PaymentMethods

Tokens

3D Secure authentication

3D Secure requires an additional layer of authentication for credit card transactions. The test cards in this section allow you to simulate triggering authentication in different payment flows.

Only cards in this section effectively test your 3D Secure integration by simulating defined 3DS behaviour, such as a challenge flow or an unsupported card. Other Stripe testing cards might still trigger 3DS, but we return attempt_acknowledged to bypass the additional steps since 3DS testing isn’t the objective for those cards.

Dashboard not supported

3D Secure redirects won’t occur for payments created directly in the Stripe Dashboard. Instead, use your integration’s own frontend or an API call.

Authentication and setup

To simulate payment flows that include authentication, use the test cards in this section. Some of these cards can also be set up for future payments, or have already been.

Card numbers

DESCRIPTION	NUMBER	DETAILS
Authenticate unless set up	4000 0025 0000 3155	This card requires authentication for off-session payments unless you set it up for future payments. After you set it up, off-session payments no longer require authentication. However, on-session payments with this card always require authentication.
Always authenticate	4000 0027 6000 3184	This card requires authentication on all transactions, regardless of how the card is set up.
Already set up	4000 0038 0000 0446	This card is already set up for off-session use. It requires authentication for one-off and other on-session payments. However, all off-session payments succeed as if the card has been previously set up.
Insufficient funds	4000 0082 6000 3178	This card requires authentication for one-off payments. All payments are declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.

PaymentMethods

Support and availability

We request authentication when required by regulation or when triggered by your Antifraud System rules or custom code. Even if authentication is requested, it can’t always be performed – for instance, the customer’s card might not be enrolled, or an error might occur. Use the test cards in this section to simulate various combinations of these factors.

Note

All 3DS references indicate 3D Secure 2.

Card numbers

3D SECURE USAGE	OUTCOME	NUMBER	DETAILS
3DS Required	OK	4000 0000 0000 3220	3D Secure authentication must be completed for the payment to be successful. By default, Our Antifraud System rules request 3D Secure authentication for this card.
3DS Required	Declined	4000 0084 0000 1629	3D Secure authentication is required, but payments are declined with a card_declined failure code after authentication. By default, Our Antifraud System rules request 3D Secure authentication for this card.
3DS Required	Error	4000 0084 0000 1280	3D Secure authentication is required, but the 3D Secure lookup request fails with a processing error. Payments are declined with a card_declined failure code. By default, Our Antifraud System rules request 3D Secure authentication for this card.
3DS Supported	OK	4000 0000 0000 3055	3D Secure authentication might still be performed, but isn’t required. By default, Our Antifraud System rules don’t request 3D Secure authentication for this card.
3DS Supported	Error	4000 0000 0000 3097	3D Secure authentication might still be performed, but isn’t required. However, attempts to perform 3D Secure result in a processing error. By default, Our Antifraud System rules don’t request 3D Secure authentication for this card.
3DS Supported	Unenrolled	4242 4242 4242 4242	3D Secure is supported for this card, but this card isn’t enrolled in 3D Secure. Even if Our Antifraud System rules request 3D Secure, the customer won’t be prompted to authenticate. By default, Our Antifraud System rules don’t request 3D Secure authentication for this card.
3DS Not supported		3782 822463 10005	3D Secure isn’t supported on this card and can’t be invoked. The PaymentIntent or SetupIntent proceeds without performing authentication.

PaymentMethods

Tokens

3D Secure mobile challenge flows

In a mobile payment, several challenge flows for authentication—where the customer has to interact with prompts in the UI—are available. Use the test cards in this section to trigger a specific challenge flow for test purposes. These cards aren’t useful in browser-based payment forms or in API calls. In those environments, they work but don’t trigger any special behavior. Because they’re not useful in API calls, we don’t provide any PaymentMethod or Token values to test with.

CHALLENGE FLOW	NUMBER	DETAILS
Out of band	4000 5826 0000 0094	3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with Out of Band UI.
One time passcode	4000 5826 0000 0045	3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with One Time Passcode UI.
Single select	4000 5826 0000 0102	3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with single-select U
Multi select	4000 5826 0000 0110	D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with multi-select UI.

Captcha challenge

To prevent fraud, Our Antifraud System might display a captcha challenge to the user on the payment page. Use the test cards below to simulate this flow.

DESCRIPTION	NUMBER	DETAILS
Captcha challenge	4000 0000 0000 1208	The charge succeeds if the user correctly answers the captcha challenge.
Captcha challenge	4000 0000 0000 3725	The charge succeeds if the user correctly answers the captcha challenge.

Rate limits

If your requests in test mode begin to receive 429 HTTP errors, make them less frequently. These errors come from our rate limiter, which is stricter in test mode than in live mode.

We don’t recommend load testing your integration using the API in test mode. Because the load limiter is stricter in test mode, you might see errors that you wouldn’t see in production. See load testing for an alternative approach.

Non-card payments

Any time you use a test non-card payment method, use test API keys in all API calls. This is true whether you’re serving a payment form you can test interactively or writing test code.

Different payment methods have different test procedures:

ACH Direct Debit

Send transaction emails in test mode

After you collect the bank account details and accept a mandate, send the mandate confirmation and microdeposit verification emails in test mode. To do this, provide an email in the payment_method_data.billing_details[email] field in the form of {any-prefix}+test_email@{any_domain} when you collect the payment method details.

Test account numbers

Stripe provides several test account numbers and corresponding tokens you can use to make sure your integration for manually-entered bank accounts is ready for production.

ACCOUNT NUMBER	TOKEN	ROUTING NUMBER	BEHAVIOR
000123456789	pm_usBankAccount_success	110000000	The payment succeeds.
000111111113	pm_usBankAccount_accountClosed	110000000	The payment fails because the account is closed.
000111111116	pm_usBankAccount_noAccount	110000000	The payment fails because no account is found.
000222222227	pm_usBankAccount_insufficientFunds	110000000	The payment fails due to insufficient funds.
000333333335	pm_usBankAccount_debitNotAuthorized	110000000	The payment fails because debits aren’t authorized.
000444444440	pm_usBankAccount_invalidCurrency	110000000	The payment fails due to invalid currency.
000666666661	pm_usBankAccount_failMicrodeposits	110000000	The payment fails to send microdeposits.
000555555559	pm_usBankAccount_dispute	110000000	The payment triggers a dispute.
000000000009	pm_usBankAccount_processing	110000000	The payment stays in processing indefinitely. Useful for testing PaymentIntent cancellation.
000777777771	pm_usBankAccount_weeklyLimitExceeded	110000000	The payment fails due to payment amount causing the account to exceed its weekly payment volume limit.

Before test transactions can complete, you need to verify all test accounts that automatically succeed or fail the payment. To do so, use the test microdeposit amounts or descriptor codes below.

Test microdeposit amounts and descriptor codes

To mimic different scenarios, use these microdeposit amounts or 0.01 descriptor code values.

MICRODEPOSIT VALUES	0.01 DESCRIPTOR CODE VALUES	SCENARIO
32 and 45	SM11AA	Simulates verifying the account.
10 and 11	SM33CC	Simulates exceeding the number of allowed verification attempts.
40 and 41	SM44DD	Simulates a microdeposit timeout.

SEPA debit

Bacs debit

BECS

Others

Link

Caution

Don’t store real user data in test mode Link accounts. Treat them as if they’re publicly available, because these test accounts are associated with your publishable key.

Currently, Link only works with credit cards, debit cards, and qualified US bank account purchases. Link requires domain registration.

You can create test mode accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that we accept for authenticating test mode accounts:

VALUE	OUTCOME
Any other 6 digits not listed below	Success
000001	Error, code invalid
000002	Error, code expired
000003	Error, max attempts exceeded

Multiple funding sources

As we add additional funding source support, you don’t need to update your integration. We automatically support them with the same transaction settlement time and guarantees as card and bank account payments.