Testing

Test your integration in a sandbox by simulating transactions with test valuesthese transactions dont move funds.

You can access your sandboxes using the account picker in the Dashboard.

Test cards act as fake credit cards, and allow you to simulate the following 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

You can also test non-card payments in a sandbox. Non-card payments are payment methods that arent credit or debit cards. Stripe supports various non-card payment options, such as digital wallets and bank transfers. Each payment method has its own special values.

Dont use testing environments to load test your integration because you might hit rate limits. To load test your integration, see load testing.

How to use test cards

When you work with a test card, use test API keys in all API calls. This is true whether youre serving a payment form to test interactively or writing test code.

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, use a PaymentMethod such as pm_card_visa instead of a card number. We dont recommend using card numbers directly in API calls or server-side code, even in testing environments. If you use them, your code might not be PCI-compliant when you go live. By default, a PaymentMethod isnt attached to a Customer.

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

When youre ready to take your integration live, replace your test publishable and secret API keys with live ones.

You cant process live payments if your integration is still using your test API keys. Store live API keys in a secrets vault or environment variables. Dont store keys in source code or configuration files checked into version control. To learn how to use live keys safely, see Best practices for managing secret API keys.

Simulate a payment by card brand

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

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

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.

Simulate a payment by country

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

Simulate customer location with email

When testing Checkout Sessions, Payment Links, or pricing tables, you can simulate a customers geographic location by using a location-formatted email address. Add a +location_XX suffix to the local part of any email address, where XX is a valid two-letter ISO 3166-1 alpha-2 country code.

For example, to simulate a customer located in the United States, pass test+location_US@example.com as the customer_email parameter when creating a Checkout Session and as the prefilled_email URL parameter when creating a Payment Link.

When you visit the resulting Checkout Session URL, you see the same currency and payment methods that a customer in the specified country would see. Learn more about testing with location-formatted emails.

Simulate an HSA or FSA card payment

Use these test card numbers to simulate FSA or HSA transactions in your integration. These accounts are commonly used for medical expenses, and testing with them helps you verify that your application handles healthcare-related transactions correctly.

Simulate a declined payment

To test your integrations error-handling logic by simulating payments that the issuer declines for various reasons, use test cards from this section. These cards return a card error with the listed error code and decline code.

Provide a CVC when you test CVC behavior. Stripe skips the CVC check if you omit it, so the check cant fail. To simulate an incorrect CVC, use the Incorrect CVC decline test card listed in the following table and provide any three-digit CVC.

Fraud prevention

Stripes 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.

To trigger a failed CVC check, include a CVC (any three-digit number). To trigger a failed postal code check, include any valid postal code. If you omit these fields, Radar skips those checks, so they cant fail.

Trigger an error with invalid data

To test errors resulting from invalid data, provide invalid details. You dont 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.

Simulate a dispute

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.

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 or in Connect embedded components, enter the value from the table in the Additional information field. Then, click Submit evidence.

Dispute prevention

Dispute prevention helps resolve or block disputes before they become chargebacks. To simulate prevented disputes in test mode, use the test cards in this section. If your account has Dispute Resolution or Dispute Deflection enabled, the dispute on the transaction is either blocked or resolved. Otherwise, the transaction is successfully disputed.

Simulate an asynchronous refund

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 dont change status after that.

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.

Send funds to your 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.

Test 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 Stripe returns attempt_acknowledged to bypass the additional steps because 3DS testing isnt the objective for those cards.

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.

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 cant always be performedfor instance, the customers card might not be enrolled, or an error might occur. Use the test cards in this section to simulate various combinations of these factors.

All 3DS references indicate 3D Secure 2.

3D Secure mobile challenge flows

In a mobile payment, several challenge flows for authenticationwhere the customer has to interact with prompts in the UIare available. Use the test cards in this section to trigger a specific challenge flow for test purposes. These cards arent useful in browser-based payment forms or in API calls. In those environments, they work but dont trigger any special behavior. Because theyre not useful in API calls, we dont provide any PaymentMethod or Token values to test with.

Simulate a captcha challenge

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

Simulate an in-person payment with a PIN

Use the test cards in this section to simulate successful in-person payments where a PIN is involved. For additional testing options, including a simulated reader and physical test cards, see Test Stripe Terminal.

Test a webhook or event destination

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 requests in your test environment return 429 errors, reduce your request frequency. The rate limiter is stricter in test environments than in live mode. For an alternative, see Load testing.

Test a non-card payment method

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

Different payment methods have different test procedures:

Test asynchronous payment methods

Asynchronous, or delayed notification, payment methods dont immediately confirm whether a payment succeeds or fails. After your customer submits payment details, the PaymentIntent can enter a processing state. The final outcome, such as succeeded or requires_payment_method, arrives later, from a few minutes in a sandbox to several business days in live mode.

This behavior differs from most card payments, which usually receive an immediate authorization response from the issuer.

Dont rely on a client-side callback or redirect to determine the final status for these payment methods. Always use webhooks to drive fulfillment.

Understand the PaymentIntent lifecycle

Payment methods that dont require further action from your customer to authorize the payment, such as bank debits, move through these states after your customer submits payment:

Payment methods that require further action from your customer to authorize the payment, such as voucher-based methods including Multibanco, Boleto, OXXO, and Konbini, add an earlier state before processing:

Handle webhook events

Register a webhook handler, or use the Stripe CLI to listen locally with stripe listen --forward-to localhost:4242/webhook, and handle these events:

For Checkout-based integrations, these corresponding session-level events also trigger:

• checkout.session.async_payment_succeeded
• checkout.session.async_payment_failed

Review expected webhook sequence by payment method

The test values for each method are in the Test a non-card payment method section. Use the following tables to understand which webhook sequence to expect when you use those test values.

Review bank debit webhook sequence

All bank debit methods follow the processing to succeeded or payment_failed pattern. In test mode, transitions happen after about 3 minutes for account numbers that simulate a delay. These use a 9 prefix or suffix. See the test values for each method in the referenced section.

Review voucher-based webhook sequence

Voucher methods issue a payment code that your customer pays out of band. The PaymentIntent enters requires_action immediately after confirmation. The delayed outcome arrives when your customer pays or when the voucher expires.

For Multibanco, Boleto, OXXO, and Konbini, use the email address patterns in their respective test sections to control whether the simulated voucher is paid, expires, or never resolves.

Review redirect and delayed notification method

Some payment methods redirect your customer for authentication. Depending on the payment method and configuration, Stripe might confirm the final outcome immediately after the redirect or deliver it asynchronously.

Expected webhook events for a successful payment:

• payment_intent.processing
• payment_intent.succeeded

BLIK can also fail asynchronously in two ways. Use the email patterns in the BLIK test section to simulate them:

• Delayed bank decline: The bank declines the payment after your customer approves it, and payment_intent.payment_failed triggers after a delay.
• Timeout: Your customer doesnt respond in time, and payment_intent.payment_failed triggers after the timeout window.

BLIK can also fail immediately, such as when a code is expired or invalid. These synchronous failures dont involve a delayed webhook.

Test asynchronous flow end to end

Use these tips to test your integration.

Use the Stripe CLI to receive webhooks locally:

stripe listen --forward-to localhost:4242/webhook

Trigger specific events manually to test your handler in isolation without running a full payment flow:

stripe trigger payment_intent.processing
stripe trigger payment_intent.succeeded
stripe trigger payment_intent.payment_failed

Handle processing in your return URL UI. When Stripe redirects your customer back to your site, paymentIntent.status might be processing, not succeeded. Show a payment pending state instead of an error.

Dont fulfill physical goods on processing. Wait for payment_intent.succeeded. For digital goods, you might choose to grant access speculatively on processing, but your webhook handler must revoke access if payment_intent.payment_failed arrives later.

Test expiration and timeout paths. Use the expire_immediately or fill_never email patterns, where available, to verify that your integration handles unpaid vouchers correctly.

If you use the mobile PaymentSheet, enable allowsDelayedPaymentMethods to show delayed notification methods. The final payment status isnt known when the sheet completes. Tell your customers their order is confirmed, and fulfill only after payment_intent.succeeded arrives.

Review asynchronous payment methods

The following table summarizes the PaymentIntent state each method enters immediately after confirmation, and the webhook events your server should expect once the delayed outcome arrives.

Test Link

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

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:

Multiple funding sources

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

Test a redirect-based flow

To test your integrations 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. Go 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.