Test cards

Not a developer?

Check out our no-code docs, use a prebuilt solution from our partner directory, or hire a Stripe-certified expert.

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:

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, 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

Do not use real card details. Testing in live mode using real payment method details is prohibited by the Stripe Services Agreement, which permits business use only. 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.

Test code

When writing test code, we don’t recommend using a card number. Instead, use the corresponding PaymentMethod, such as pm_card_visa.

Command Line

curl
 
https://api.stripe.com/v1/payment_intents
 \
  -u
 
sk_test_4eC39HqLyjWDarjtT1zdp7dc
  -d
 
amount
=
500
 \
  -d
 
currency
=
gbp
 \
  -d
 
payment_method
=
pm_card_visa

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.

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, use test cards from the following list. The billing country for each test card is set to the United States. If you need to create test card payments using cards for other billing countries, use international test cards.

BrandNumberCVCDate

Visa Any 3 digitsAny future dateVisa (debit)Any 3 digitsAny future dateMastercardAny 3 digitsAny future dateMastercard (2-series)Any 3 digitsAny future dateMastercard (debit)Any 3 digitsAny future dateMastercard (prepaid)Any 3 digitsAny future dateAmerican ExpressAny 4 digitsAny future dateAmerican ExpressAny 4 digitsAny future dateDiscoverAny 3 digitsAny future dateDiscoverAny 3 digitsAny future dateDiscover (debit)Any 3 digitsAny future dateDiners ClubAny 3 digitsAny future dateDiners Club (14-digit card)Any 3 digitsAny future dateJCBAny 3 digitsAny future dateUnionPayAny 3 digitsAny future dateUnionPay (debit)Any 3 digitsAny 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-brandNumberCVCDateCartes Bancaires/VisaAny 3 digitsAny future dateCartes Bancaires/MastercardAny 3 digitsAny future dateeftpos Australia/VisaAny 3 digitsAny future dateeftpos Australia/MastercardAny 3 digitsAny future date

Cards by country

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

Americas

Use these test cards to simulate successful payments from North and South America.

CountryNumberBrand

United States (US)VisaBrazil (BR)VisaCanada (CA)VisaMexico (MX)Visa

Europe and Middle East

Use these test cards to simulate successful payments from Europe and the 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.

CountryNumberBrand

United Arab Emirates (AE)VisaUnited Arab Emirates (AE)MastercardAustria (AT)VisaBelgium (BE)VisaBulgaria (BG)VisaBelarus (BY)VisaCroatia (HR)VisaCyprus (CY)VisaCzech Republic (CZ)VisaDenmark (DK)VisaEstonia (EE)VisaFinland (FI)VisaFrance (FR)VisaGermany (DE)VisaGibraltar (GI)VisaGreece (GR)VisaHungary (HU)VisaIreland (IE)VisaItaly (IT)VisaLatvia (LV)VisaLiechtenstein (LI)VisaLithuania (LT)VisaLuxembourg (LU)VisaMalta (MT)VisaNetherlands (NL)VisaNorway (NO)VisaPoland (PL)VisaPortugal (PT)VisaRomania (RO)VisaSaudi Arabia (SA)VisaSlovenia (SI)VisaSlovakia (SK)VisaSpain (ES)VisaSweden (SE)VisaSwitzerland (CH)VisaUnited Kingdom (GB)VisaUnited Kingdom (GB)Visa (debit)United Kingdom (GB)Mastercard

Asia-Pacific

Use these test cards to simulate successful payments from Asia and the Pacific.

Caution

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

CountryNumberBrand

Australia (AU)VisaChina (CN)VisaHong Kong (HK)VisaIndia (IN)VisaJapan (JP)VisaJapan (JP)JCBMalaysia (my)VisaNew Zealand (NZ)VisaSingapore (SG)VisaThailand (TH)Visa (credit)Thailand (TH)Visa (debit)

Declined payments

To simulate payments that the issuer declines for various reasons, use test cards from this section. This can be useful for testing your integration’s error handling logic. 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 decline, you must provide a CVC. It can be any three-digit number. If you don’t provide a CVC, Stripe doesn’t perform the CVC check, so the check can’t fail.

DescriptionNumberError codeDecline code

Generic declinecard_declinedgeneric_declineInsufficient funds declinecard_declinedinsufficient_fundsLost card declinecard_declinedlost_cardStolen card declinecard_declinedstolen_cardExpired card declineexpired_cardn/aIncorrect CVC declineincorrect_cvcn/aProcessing error declineprocessing_errorn/aIncorrect number declineincorrect_numbern/a

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.

DescriptionNumberDetailsDecline after attachingAttaching 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. It can be any three-digit number. To simulate a failed postal code check, you must provide a postal code. It can be any valid postal code. If you don’t provide those values, Radar doesn’t perform the corresponding checks, so the checks can’t fail.

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_month13
• invalid_expiry_year95
• invalid_cvc99
• incorrect_numberLuhn check, such as

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.

DescriptionNumberDetailsFraudulentWith default account settings, charge succeeds, only to be disputed as fraudulentprotectedNot receivedWith default account settings, charge succeeds, only to be disputed as product not receivedisn’t protectedInquiryWith default account settings, charge succeeds, only to be disputed as an inquiryWarningWith default account settings, charge succeeds, only to receive an early fraud warning

Evidence

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

EvidenceDescriptionwinning_evidenceThe dispute is closed and marked as won. Your account is credited the amount of the charge and related fees.losing_evidenceThe 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.)

DescriptionNumberDetailsAsynchronous successThe 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.updated webhook event.Asynchronous failureThe 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.updated webhook event.

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.

DescriptionNumberDetailsBypass pending balanceThe US charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.Bypass pending balanceThe 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. Use the test cards in this section to simulate payment flows that involve authentication. Other test cards are not enrolled in 3D Secure, which means that no authentication can occur.

Common mistake

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 NumberDetails

Authenticate unless set upThis card requires authentication for off-session payments unless you set it upAlways authenticateThis card requires authentication on all transactions, regardless of how the card is set up.Already set upThis card is already set up for off-session use. It requires authentication for one-time and other on-session

off-session payments

succeed as if the card has been previously set upInsufficient fundsThis 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 usageOutcomeNumberDetails

3DS2 RequiredOK3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card.3DS RequiredOK3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card.3DS RequiredDeclined3D 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 RequiredError3D 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 SupportedOK3D 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 SupportedError3D 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 SupportedUnenrolled3D Secure is supported for this card, but this card isn’t enrolled in 3D Secure. This means that if your Radar rules request 3D Secure, the customer doesn’t go through additional authentication. 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 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 flowNumberDetails

Out of band3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with Out of Band UI.One time passcode3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with One Time Passcode UI.Single select3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with single-select UI.Multi select3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with multi-select UI.Webview3D Secure authentication must be completed for the payment to be successful. Triggers the challenge flow using a webview. You can check that your return_url dismisses the modal.

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.

DescriptionNumberDetailsOffline PINThis 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 retrySimulates 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 PINThis 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 retrySimulates 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.

Webhooks

To test webhooks, you have two options:

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 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 our documentation on 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:

To test scenarios with instant verifications, mimic different scenarios for ACH charges by selecting the test bank account for the use case you want to test.

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.

Common mistake

You need to activate your Stripe account before you can trigger these emails in Test mode.

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 numberTokenRouting numberBehavior000123456789pm_usBankAccount_success110000000The payment succeeds.000111111113pm_usBankAccount_accountClosed110000000The payment fails because the account is closed.000111111116pm_usBankAccount_noAccount110000000The payment fails because no account is found.000222222227pm_usBankAccount_insufficientFunds110000000The payment fails due to insufficient funds.000333333335pm_usBankAccount_debitNotAuthorized110000000The payment fails because debits aren’t authorized.000444444440pm_usBankAccount_invalidCurrency110000000The payment fails due to invalid currency.000666666661pm_usBankAccount_failMicrodeposits110000000The payment fails to send microdeposits.

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 values0.01 descriptor code valuesScenario32 and 45SM11AASimulates verifying the account.10 and 11SM33CCSimulates exceeding the number of allowed verification attempts.40 and 41SM44DDSimulates a microdeposit timeout.