Test payment methods (2024)

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 Test payment methods (1)

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 interactivelyTest payment methods (2)

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 payment methods (3)

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

Test codeTest payment methods (4)

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.

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

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 Test payment methods (5)

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.

Caution

Cross border fees are assessed based on the country of the card issuer. While each of the cards in this section use US as the billing country, 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.

BrandNumberCVCDate
Visa Any 3 digitsAny future date
Visa (debit)Any 3 digitsAny future date
MastercardAny 3 digitsAny future date
Mastercard (2-series)Any 3 digitsAny future date
Mastercard (debit)Any 3 digitsAny future date
Mastercard (prepaid)Any 3 digitsAny future date
American ExpressAny 4 digitsAny future date
American ExpressAny 4 digitsAny future date
DiscoverAny 3 digitsAny future date
DiscoverAny 3 digitsAny future date
Discover (debit)Any 3 digitsAny future date
Diners ClubAny 3 digitsAny future date
Diners Club (14-digit card)Any 3 digitsAny future date
BCcard and DinaCardAny 3 digitsAny future date
JCBAny 3 digitsAny future date
UnionPayAny 3 digitsAny future date
UnionPay (debit)Any 3 digitsAny future date
UnionPay (19-digit card)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-brandNumberCVCDate
Cartes Bancaires/VisaAny 3 digitsAny future date
Cartes Bancaires/MastercardAny 3 digitsAny future date
eftpos Australia/VisaAny 3 digitsAny future date
eftpos Australia/MastercardAny 3 digitsAny future date

Cards by country Test payment methods (6)

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

CountryNumberBrand
AMERICAS
United States (US)Visa
Argentina (AR)Visa
Brazil (BR)Visa
Canada (CA)Visa
Chile (CL)Visa
Colombia (CO)Visa
Costa Rica (CR)Visa
Ecuador (EC)Visa
Mexico (MX)Visa
Mexico (MX)Carnet
Panama (PA)Visa
Paraguay (PY)Visa
Peru (PE)Visa
Uruguay (UY)Visa
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)Visa
United Arab Emirates (AE)Mastercard
Austria (AT)Visa
Belgium (BE)Visa
Bulgaria (BG)Visa
Belarus (BY)Visa
Croatia (HR)Visa
Cyprus (CY)Visa
Czech Republic (CZ)Visa
Denmark (DK)Visa
Estonia (EE)Visa
Finland (FI)Visa
France (FR)Visa
Germany (DE)Visa
Gibraltar (GI)Visa
Greece (GR)Visa
Hungary (HU)Visa
Ireland (IE)Visa
Italy (IT)Visa
Latvia (LV)Visa
Liechtenstein (LI)Visa
Lithuania (LT)Visa
Luxembourg (LU)Visa
Malta (MT)Visa
Netherlands (NL)Visa
Norway (NO)Visa
Poland (PL)Visa
Portugal (PT)Visa
Romania (RO)Visa
Saudi Arabia (SA)Visa
Slovenia (SI)Visa
Slovakia (SK)Visa
Spain (ES)Visa
Sweden (SE)Visa
Switzerland (CH)Visa
United Kingdom (GB)Visa
United Kingdom (GB)Visa (debit)
United Kingdom (GB)Mastercard
ASIA PACIFIC

Regional considerations

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 paymentsTest payment methods (7)

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 declinecard_declinedgeneric_decline
Insufficient funds declinecard_declinedinsufficient_funds
Lost card declinecard_declinedlost_card
Stolen card declinecard_declinedstolen_card
Expired card declineexpired_cardn/a
Incorrect CVC declineincorrect_cvcn/a
Processing error declineprocessing_errorn/a
Incorrect number declineincorrect_numbern/a
Exceeding velocity limit declinecard_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.

DescriptionNumberDetails
Decline after attachingAttaching this card to a Customer object succeeds, but attempts to charge the customer fail.

Fraud preventionTest payment methods (8)

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.

DescriptionNumberDetails

Always blocked

The charge has a risk level of “highest”

Radar always blocks it.

Highest risk

The charge has a risk level of “highest”

Radar might block it depending on your settings.

Elevated risk

The charge has a risk level of “elevated”

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

CVC check fails

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

Radar might block it depending on your settings.

Postal code check fails

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

Radar might block it depending on your settings.

Line1 check fails

The address line 1 check fails.

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

Address checks fail

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

Radar might block it depending on your settings.

Address unavailable

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 dataTest payment methods (9)

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 Test payment methods (10)

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.

DescriptionNumberDetails
FraudulentWith default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication.
Not receivedWith default account settings, charge succeeds, only to be disputed as product not received. This type of dispute isn’t protected after 3D Secure authentication.
InquiryWith default account settings, charge succeeds, only to be disputed as an inquiry.
WarningWith default account settings, charge succeeds, only to receive an early fraud warning.
Multiple disputesWith default account settings, charge succeeds, only to be disputed multiple times.

Evidence Test payment methods (11)

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.

RefundsTest payment methods (12)

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

DescriptionNumberDetails
Asynchronous 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 balanceTest payment methods (13)

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.

DescriptionNumberDetails
Bypass 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 Test payment methods (14)

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 setupTest payment methods (15)

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 up for future payments. After you set it up, off-session payments no longer require authentication.
Always 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 payments. However, all off-session payments succeed as if the card has been previously set up.
Insufficient 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 Test payment methods (16)

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 usageOutcomeNumberDetails
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. 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 flowsTest payment methods (17)

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.

Payments with PINs Test payment methods (18)

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 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 Test payment methods (19)

To test webhooks, you have two options:

  1. Perform actions in test mode that send legitimate events to your endpoint. For instance, 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 limitsTest payment methods (20)

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 paymentsTest payment methods (21)

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 test modeTest payment methods (22)

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 numbersTest payment methods (23)

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.

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 codesTest payment methods (24)

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.

RedirectsTest payment methods (25)

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 test mode.
  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 alsoTest payment methods (26)

  • Testing your Connect integration
  • Testing your Billing integration
  • Testing your Terminal integration
  • Load testing
Test payment methods (2024)

FAQs

What is test payment method? ›

Test Payment method allows merchants to check how the payment process works without making real payments.

What is a B testing payment method Stripe? ›

Beta. Launch an A/B test for a new payment method in Dashboard—no code required. A/B testing allows you to measure the impact of offering new payment methods to a percentage of buyers before offering them to all of your customers.

What is a test transaction? ›

A test transaction is a transaction conducted to mimic the sale process within the customer journey. The difference being it is conducted by the merchant, using the Commission Factory test transaction link, so that it can be tracked in the dashboard as a test transaction rather than a regular customer conversion.

How do I get PayPal in test mode? ›

Under Sandbox, click Accounts, and then click Create Account. Choose the type of account and country that you want to test, and click Create. PayPal generates an account for you with test values for bank account, credit card, and balance.

Is Stripe free for testing? ›

Stripe's test mode allows you to test your integration without making actual charges or payments.

Can I use Stripe as a payment method? ›

Recurring revenue businesses can use Stripe Billing to manage subscription logic and invoices and give customers the ability to pay their invoices with bank debits or other preferred payment methods. Platforms and marketplaces can use Stripe Connect to accept money and pay out to third parties.

Is Stripe free to use? ›

Stripe is free to set up and the company does not charge a monthly or annual fee for its services. Instead, all Stripe fees are per transaction with transparent pricing. Online sales cost businesses 2.9% plus 30 cents per transaction.

How do you automate payment testing? ›

Check Out Best Practices for User Payment Testing
  1. Take an End-to-End Approach. ...
  2. Combine Automated and Manual Testing. ...
  3. Execute Multiple Integration Test Cases. ...
  4. Test With Real Transactions and Payment Methods. ...
  5. Use a Scalable Testing Platform. ...
  6. Run a Pre-Test Pilot.

How to do a test payment with Square? ›

To test an invoice paid through email, you can create and publish an invoice in the Sandbox environment. The invoice settings can be configured to direct Square to automatically send an invoice to a customer's email address.

How do I create a dummy payment gateway? ›

How do I create a dummy payment gateway for testing?
  1. Create a Make-Believe Checkout Counter: Design a fake checkout counter on your computer. ...
  2. Make Up Some Credit Cards: Create imaginary credit card numbers, expiration dates, and security codes.
Dec 5, 2023

How to do a test payment in Stripe? ›

Enter the card number in the Dashboard or in any payment form.
  1. Use a valid future date, such as 12/34.
  2. Use any three-digit CVC (four digits for American Express cards).
  3. Use any value you like for other form fields.

Why do Stripe payments fail? ›

There are three reasons why a payment might fail: Issuer declines. Blocked payments. Invalid API calls.

How to test payment API? ›

Here are 11 items you should be sure to cover when you test payments:
  1. Collect all relevant test data, such as dummy financial information.
  2. Compile payment gateway data from the merchant.
  3. Create a payment processor sandbox to run simulated scenarios.
  4. Develop a list of error codes and document all error events.

What is the payment method of UserTesting? ›

All contributors receive payments in USD through PayPal (you can then convert to your local currency via PayPal if desired). You must have a confirmed PayPal account that's in good standing to receive payments.

Is payment testing safe? ›

Payment testing can also include testing for compliance with industry regulations and standards and for vulnerabilities and potential security breaches. Payments testing aims to ensure that the payment system is reliable, secure, and compliant while providing an intuitive experience for users.

What is the payment method for Testerwork? ›

Payments are made via PayPal or Upwork.

What does verify payment method mean? ›

Payment verification is a crucial process that helps safeguard financial transactions from fraudulent activities. It involves the thorough examination and validation of payment information provided by users before authorizing a transaction.

References

Top Articles
Latest Posts
Article information

Author: Prof. An Powlowski

Last Updated:

Views: 6138

Rating: 4.3 / 5 (64 voted)

Reviews: 95% of readers found this page helpful

Author information

Name: Prof. An Powlowski

Birthday: 1992-09-29

Address: Apt. 994 8891 Orval Hill, Brittnyburgh, AZ 41023-0398

Phone: +26417467956738

Job: District Marketing Strategist

Hobby: Embroidery, Bodybuilding, Motor sports, Amateur radio, Wood carving, Whittling, Air sports

Introduction: My name is Prof. An Powlowski, I am a charming, helpful, attractive, good, graceful, thoughtful, vast person who loves writing and wants to share my knowledge and understanding with you.