Any time you work with a test card, use test API keys in all API calls. 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. The Stripe Services Agreement prohibits testing in live mode using real payment method 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 anymore, 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.
Brand
Number
CVC
Date
Visa
Any 3 digits
Any future date
Visa (debit)
Any 3 digits
Any future date
Mastercard
Any 3 digits
Any future date
Mastercard (2-series)
Any 3 digits
Any future date
Mastercard (debit)
Any 3 digits
Any future date
Mastercard (prepaid)
Any 3 digits
Any future date
American Express
Any 4 digits
Any future date
American Express
Any 4 digits
Any future date
Discover
Any 3 digits
Any future date
Discover
Any 3 digits
Any future date
Discover (debit)
Any 3 digits
Any future date
Diners Club
Any 3 digits
Any future date
Diners Club (14-digit card)
Any 3 digits
Any future date
BCcard and DinaCard
Any 3 digits
Any future date
JCB
Any 3 digits
Any future date
UnionPay
Any 3 digits
Any future date
UnionPay (debit)
Any 3 digits
Any future date
UnionPay (19-digit card)
Any 3 digits
Any future date
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.
Brand/Co-brand
Number
CVC
Date
Cartes Bancaires/Visa
Any 3 digits
Any future date
Cartes Bancaires/Mastercard
Any 3 digits
Any future date
eftpos Australia/Visa
Any 3 digits
Any future date
eftpos Australia/Mastercard
Any 3 digits
Any future date
Cards by country
To simulate successful payments from specific countries, use test cards from the following sections.
To test subscriptions that require mandates and pre-debit notifications, see India recurring payments.
Australia (AU)
Visa
China (CN)
Visa
Hong Kong (HK)
Visa
India (IN)
Visa
Japan (JP)
Visa
Japan (JP)
JCB
Malaysia (my)
Visa
New Zealand (NZ)
Visa
Singapore (SG)
Visa
Taiwan (TW)
Visa
Thailand (TH)
Visa (credit)
Thailand (TH)
Visa (debit)
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.
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
Number
Details
Decline after attaching
Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
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.
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:
With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication.
Not received
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
With default account settings, charge succeeds, only to be disputed as an inquiry.
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.)
Description
Number
Details
Asynchronous success
The charge succeeds. If you initiate a refund, its status begins as pending. Some time later, its status transitions to succeeded and sends a charge.refund.updatedwebhook event.
Asynchronous failure
The charge succeeds. If you initiate a refund, its status begins as succeeded. Some time later, its status transitions to failed and sends a charge.refund.updatedwebhook event.
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.
Description
Number
Details
Bypass pending balance
The US charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.
Bypass pending balance
The international charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.
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 behavior, 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.
Description
Number
Details
Authenticate unless set up
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
This card requires authentication on all transactions, regardless of how the card is set up.
Already set up
This card is already set up for off-session use. It requires authentication for one-time and other on-session payments. However, all off-session payments succeed as if the card has been previously set up.
Insufficient funds
This card requires authentication for one-time payments. All payments are declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.
Support and availability
Stripe requests authentication when required by regulation or when triggered by your Radar 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.
3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card.
3DS Required
Declined
3D Secure authentication is required, but payments are declined with a card_declined failure code after authentication. By default, your Radar rules request 3D Secure authentication for this card.
3DS Required
Error
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, your Radar rules request 3D Secure authentication for this card.
3DS Supported
OK
3D Secure authentication might still be performed, but isn’t required. By default, your Radar rules don’t request 3D Secure authentication for this card.
3DS Supported
Error
3D Secure authentication might still be performed, but isn’t required. However, attempts to perform 3D Secure result in a processing error. By default, your Radar rules don’t request 3D Secure authentication for this card.
3DS Supported
Unenrolled
3D Secure is supported for this card, but this card isn’t enrolled in 3D Secure. Even if your Radar rules request 3D Secure, the customer won’t be prompted to authenticate. By default, your Radar rules don’t request 3D Secure authentication for this card.
3DS Not supported
3D Secure isn’t supported on this card and can’t be invoked. The PaymentIntent or SetupIntent proceeds without performing authentication.
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
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with Out of Band UI.
One time passcode
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with One Time Passcode UI.
Single select
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with single-select UI.
Multi select
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with multi-select UI.
Payments with PINs
Use the test cards in this section to simulate successful in-person payments where a PIN is involved. There are many other options for testing in-person payments, including a simulated reader and physical test cards. See Test Stripe Terminal for more information.
Description
Number
Details
Offline PIN
This card simulates a payment where the cardholder is prompted for and enters an offline PIN. The resulting charge has cardholder_verification_method set to offline_pin.
Offline PIN retry
Simulates an SCA-triggered retry flow where a cardholder’s initial contactless charge fails and the reader then prompts the user to insert their card and enter their offline PIN. The resulting charge has cardholder_verification_method set to offline_pin.
Online PIN
This card simulates a payment where the cardholder is prompted for and enters an online PIN. The resulting charge has cardholder_verification_method set to online_pin.
Online PIN retry
Simulates an SCA-triggered retry flow where a cardholder’s initial contactless charge fails and the reader then prompts the user to insert their card and enter their online PIN. The resulting charge has cardholder_verification_method set to online_pin.
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 Stripe 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:
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.
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.
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.
Redirects
To test your integration’s redirect-handling logic by simulating a payment that uses a redirect flow (for example, iDEAL), use a supported payment method that requires redirects.
To create a test PaymentIntent that either succeeds or fails: