Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Developer tools
Get started
Payments
Finance automation
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Overview
Versioning
Changelog
Upgrade your API version
Upgrade your SDK version
Developer tools
SDKs
API
Testing
    Test your integration
    Testing use cases
    Sandboxes
    Test Apple Pay and Google Pay rendering
Workbench
Event Destinations
Workflows
Stripe CLI
Stripe Shell
Developers Dashboard
Agent toolkit
Stripe health alertsBuilding with LLMsStripe for Visual Studio CodeFile uploads
Security
Security
Extend Stripe
Stripe Apps
Stripe Connectors
Partners
Partner ecosystem
Partner certification
HomeDeveloper toolsTesting

Testing

Simulate payments to test your integration.

Copy page

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

Test cards function as fake credit cards and 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 that you use testing environments to load-test your integration. Instead, see 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

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.
An example payment form showing how to enter a test card number. The card number is "4242 4242 4242 4242", the expiration date is "12/34", and the CVC is "567". Other fields have arbitrary values. For instance, the email address is "test@example.com"

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 testing environments. 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.

Command Line
cURL
curl https://api.stripe.com/v1/payment_intents \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d amount=500 \ -d currency=gbp \ -d payment_method=pm_card_visa \ -d "payment_method_types[]"=card

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 testing environments.

BrandPaymentMethod
Visa pm_card_visa
Visa (debit)pm_card_visa_debit
Mastercardpm_card_mastercard
Mastercard (debit)pm_card_mastercard_debit
Mastercard (prepaid)pm_card_mastercard_prepaid
American Expresspm_card_amex
Discoverpm_card_discover
Diners Clubpm_card_diners
JCBpm_card_jcb
UnionPaypm_card_unionpay

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.

BrandPaymentMethod
Cartes Bancaires/Visapm_card_visa_cartesBancaires
Cartes Bancaires/Mastercardpm_card_mastercard_cartesBancaires
eftpos Australia/Visapm_card_visa_debit_eftposAuCoBranded
eftpos Australia/Mastercardpm_card_mastercard_debit_eftposAuCoBranded

Cards by country

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

CountryPaymentMethodBrand
AMERICAS
United States (US)pm_card_usVisa
Argentina (AR)pm_card_arVisa
Brazil (BR)pm_card_brVisa
Canada (CA)pm_card_caVisa
Chile (CL)pm_card_clVisa
Colombia (CO)pm_card_coVisa
Costa Rica (CR)pm_card_crVisa
Ecuador (EC)pm_card_ecVisa
Mexico (MX)pm_card_mxVisa
Panama (PA)pm_card_paVisa
Paraguay (PY)pm_card_pyVisa
Peru (PE)pm_card_peVisa
Uruguay (UY)pm_card_uyVisa
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)pm_card_aeVisa
United Arab Emirates (AE)pm_card_ae_mastercardMastercard
Austria (AT)pm_card_atVisa
Belgium (BE)pm_card_beVisa
Bulgaria (BG)pm_card_bgVisa
Belarus (BY)pm_card_byVisa
Croatia (HR)pm_card_hrVisa
Cyprus (CY)pm_card_cyVisa
Czech Republic (CZ)pm_card_czVisa
Denmark (DK)pm_card_dkVisa
Estonia (EE)pm_card_eeVisa
Finland (FI)pm_card_fiVisa
France (FR)pm_card_frVisa
Germany (DE)pm_card_deVisa
Gibraltar (GI)pm_card_giVisa
Greece (GR)pm_card_grVisa
Hungary (HU)pm_card_huVisa
Ireland (IE)pm_card_ieVisa
Italy (IT)pm_card_itVisa
Latvia (LV)pm_card_lvVisa
Liechtenstein (LI)pm_card_liVisa
Lithuania (LT)pm_card_ltVisa
Luxembourg (LU)pm_card_luVisa
Malta (MT)pm_card_mtVisa
Netherlands (NL)pm_card_nlVisa
Norway (NO)pm_card_noVisa
Poland (PL)pm_card_plVisa
Portugal (PT)pm_card_ptVisa
Romania (RO)pm_card_roVisa
Slovenia (SI)pm_card_siVisa
Slovakia (SK)pm_card_skVisa
Spain (ES)pm_card_esVisa
Sweden (SE)pm_card_seVisa
Switzerland (CH)pm_card_chVisa
United Kingdom (GB)pm_card_gbVisa
United Kingdom (GB)pm_card_gb_debitVisa (debit)
United Kingdom (GB)pm_card_gb_mastercardMastercard
ASIA PACIFIC 2

Regional considerations
India

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

Australia (AU)pm_card_auVisa
China (CN)pm_card_cnVisa
Hong Kong (HK)pm_card_hkVisa
India (IN)pm_card_inVisa
Japan (JP)pm_card_jpVisa
Japan (JP)pm_card_jcbJCB
Malaysia (my)pm_card_myVisa
New Zealand (NZ)pm_card_nzVisa
Singapore (SG)pm_card_sgVisa
Taiwan (TW)pm_card_twVisa
Thailand (TH)pm_card_th_creditVisa (credit)
Thailand (TH)pm_card_th_debitVisa (debit)

HSA and FSA test cards

Below are test card numbers for simulating transactions using Health Savings Accounts (HSA) and Flexible Spending Accounts (FSA). These accounts are commonly used for medical expenses, and testing with them ensures proper handling of healthcare-related transactions within your application.

Brand/TypePaymentMethod
Visa FSApm_card_debit_visaFsaProductCode
Visa HSApm_card_debit_visaHsaProductCode
Mastercard FSApm_card_mastercard_debit_mastercardFsaProductCode

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.

DescriptionNumberError codeDecline code
Generic declinepm_card_visa_chargeDeclinedcard_declinedgeneric_decline
Insufficient funds declinepm_card_visa_chargeDeclinedInsufficientFundscard_declinedinsufficient_funds
Lost card declinepm_card_visa_chargeDeclinedLostCardcard_declinedlost_card
Stolen card declinepm_card_visa_chargeDeclinedStolenCardcard_declinedstolen_card
Expired card declinepm_card_chargeDeclinedExpiredCardexpired_cardn/a
Incorrect CVC declinepm_card_chargeDeclinedIncorrectCvcincorrect_cvcn/a
Processing error declinepm_card_chargeDeclinedProcessingErrorprocessing_errorn/a
Exceeding velocity limit declinepm_card_visa_chargeDeclinedVelocityLimitExceededcard_declinedcard_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.

DescriptionPaymentMethodDetails
Decline after attachingpm_card_chargeCustomerFailAttaching 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.

DescriptionPaymentMethodDetails

Always blocked

pm_card_radarBlock

The charge has a risk level of “highest”

Radar always blocks it.

Highest risk

pm_card_riskLevelHighest

The charge has a risk level of “highest”

Radar might block it depending on your settings.

Elevated risk

pm_card_riskLevelElevated

The charge has a risk level of “elevated”

If you use Radar for Fraud Teams, Radar might queue it for review.

CVC check fails

pm_card_cvcCheckFail

If you provide a CVC number, the CVC check fails.

Radar might block it depending on your settings.

Postal code check fails

pm_card_avsZipFail

If you provide a postal code, the postal code check fails.

Radar might block it depending on your settings.

CVC check fails with elevated risk

pm_card_cvcCheckFailElevatedRisk

If you provide a CVC number, the CVC check fails with a risk level of “elevated”

Radar might block it depending on your settings.

Postal code check fails with elevated risk

pm_card_avsZipFailElevatedRisk

If you provide a postal code, the postal code check fails with a risk level of “elevated”

Radar might block it depending on your settings.

Line1 check fails

pm_card_avsLine1Fail

The address line 1 check fails.

The payment succeeds unless you block it with a custom Radar rule.

Address checks fail

pm_card_avsFail

The address postal code check and address line 1 check both fail.

Radar might block it depending on your settings.

Address unavailable

pm_card_avsUnchecked

The address postal code check and address line 1 check are both unavailable.

The payment succeeds unless you block it with a custom Radar rule.

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 .

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.

DescriptionPaymentMethodDetails
Fraudulentpm_card_createDisputeWith default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication.
Not receivedpm_card_createDisputeProductNotReceivedWith default account settings, charge succeeds, only to be disputed as product not received. This type of dispute isn’t protected after 3D Secure authentication.
Inquirypm_card_createDisputeInquiryWith default account settings, charge succeeds, only to be disputed as an inquiry.
Warningpm_card_createIssuerFraudRecordWith default account settings, charge succeeds, only to receive an early fraud warning.
Multiple disputespm_card_createMultipleDisputesWith default account settings, charge succeeds, only to be disputed multiple times.
Visa Compelling Evidence 3.0pm_card_createCe3EligibleDisputeWith default account settings, charge succeeds, only to be disputed as a Visa Compelling Evidence 3.0 eligible dispute.
Visa compliancepm_card_createComplianceDisputeWith default account settings, charge succeeds, only to be disputed as a Visa compliance dispute.

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.
EvidenceDescription
winning_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.)

DescriptionPaymentMethodDetails
Asynchronous successpm_card_pendingRefundThe 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 failurepm_card_refundFailThe 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.

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. Testing environments simulate 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.

DescriptionPaymentMethodDetails
Bypass pending balancepm_card_bypassPendingThe US charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.
Bypass pending balancepm_card_bypassPendingInternationalThe 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.

DescriptionPaymentMethodDetails
Authenticate unless set uppm_card_authenticationRequiredOnSetupThis card requires authentication for every payment unless you set it up for future payments. After you set it up, it no longer requires authentication.
Always authenticatepm_card_authenticationRequiredThis card requires authentication on all transactions, regardless of how the card is set up.
Already set uppm_card_authenticationRequiredSetupForOffSessionThis 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 fundspm_card_authenticationRequiredChargeDeclinedInsufficientFundsThis 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.

Note

All 3DS references indicate 3D Secure 2.

3D Secure usageOutcomePaymentMethodDetails
RequiredOKpm_card_threeDSecure2Required3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card.
RequiredDeclinedpm_card_threeDSecureRequiredChargeDeclined3D 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.
RequiredErrorpm_card_threeDSecureRequiredProcessingError3D 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.
SupportedOKpm_card_threeDSecureOptional3D Secure authentication might still be performed, but isn’t required. By default, your Radar rules don’t request 3D Secure authentication for this card.
SupportedErrorpm_card_threeDSecureOptionalProcessingError3D 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.
SupportedUnenrolledpm_card_visa3D 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.
Not supportedpm_card_amex_threeDSecureNotSupported3D 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 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.

Captcha challenge

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

DescriptionNumberDetails
Captcha challengeThe charge succeeds if the user correctly answers the captcha challenge.
Captcha challengeThe charge succeeds if the user correctly answers the captcha challenge.

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.

DescriptionNumberDetails
Offline PINoffline_pin_cvmThis 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 retryoffline_pin_sca_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 PINonline_pin_cvmThis 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 retryonline_pin_sca_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.

Event destinations

To test your webhook endpoint or event destination, choose one of these two options:

  1. Perform actions in a sandbox that send legitimate events to your event destination. For example, to trigger the charge.succeeded event, you can use a test card that produces a successful charge.
  2. Trigger events using the Stripe CLI or using Stripe for Visual Studio Code.

Rate limits

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

We don’t recommend load testing your integration using the Stripe API in testing environments. Because the load limiter is stricter in testing environments, 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:

Learn how to test scenarios with instant verifications using Financial Connections.

Send transaction emails in a sandbox

After you collect the bank account details and accept a mandate, send the mandate confirmation and microdeposit verification emails in a sandbox. 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 while testing.

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 numberBehavior
000123456789pm_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.
000555555559pm_usBankAccount_dispute110000000The payment triggers a dispute.
000000000009pm_usBankAccount_processing110000000The payment stays in processing indefinitely. Useful for testing PaymentIntent cancellation.
000777777771pm_usBankAccount_weeklyLimitExceeded110000000The 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 values0.01 descriptor code valuesScenario
32 and 45SM11AASimulates verifying the account.
10 and 11SM33CCSimulates exceeding the number of allowed verification attempts.
40 and 41SM44DDSimulates a microdeposit timeout.

Test settlement behavior

Test transactions settle instantly and are added to your available test balance. This behavior differs from livemode, where transactions can take multiple days to settle in your available balance.

Link

Caution

Don’t store real user data in sandbox 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 sandbox accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that Stripe accepts for authenticating sandbox accounts:

ValueOutcome
Any other 6 digits not listed belowSuccess
000001Error, code invalid
000002Error, code expired
000003Error, max attempts exceeded

Multiple funding sources

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

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:

  1. Navigate to the payment methods settings in the Dashboard and enable a supported payment method by clicking Turn on in your testing environment.
  2. Collect payment details.
  3. Submit the payment to Stripe.
  4. Authorize or fail the test payment.

Make sure that the page (corresponding to return_url) on your website provides the status of the payment.

See also

  • Testing your Connect integration
  • Testing your Billing integration
  • Testing your Terminal integration
  • Load testing
Was this page helpful?
YesNo
Need help? Contact Support.
Join our early access program.
Check out our changelog.
Questions? Contact Sales.
LLM? Read llms.txt.
Powered by Markdoc
Related Guides
Testing use cases
API keys