Documentation

Welcome to our little corner of the Tech World. I hope that you find things useful and that you will embrace our community spirit by contributing!

Test Credit Card numbers for Stripe

Basic test card numbers

Genuine card information cannot be used in test mode. Instead, use any of the following test card numbers, a valid expiration date in the future, and any random CVC number, to create a successful payment. Each basic test card’s billing country is set to U.S. If you need to create test card payments using cards for other billing countries, use our international test cards.

Card numbers
Tokens
PaymentMethods
NUMBER
BRAND
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

Diners Club Any 3 digits Any future date

Diners Club (14 digit card) Any 3 digits Any future date

JCB Any 3 digits Any future date

UnionPay Any 3 digits Any future date

We recommend using our test IDs when testing your integration and creating charges, instead of passing card information directly to the API. Using these test IDs in place of card numbers helps ensure your production integration is developed in a PCI compliant manner and isn’t going to handle card information directly. Each test ID is human-readable and represents card information that has been tokenized with our client-side libraries (for example, Stripe Elements, Stripe.js).

International test card numbers

You can use any of the following test cards to simulate a successful payment for different billing countries.

Americas
Europe, Middle East, and Africa
Asia-Pacific
NUMBER
TOKEN
PAYMENT METHOD
COUNTRY
BRAND

tok_us pm_card_us United States (US) Visa

tok_br pm_card_br Brazil (BR) Visa

tok_ca pm_card_ca Canada (CA) Visa

tok_mx pm_card_mx Mexico (MX) Visa

Regulatory (3D Secure) test card numbers

The following card information tests payments affected by regional regulations such as Strong Customer Authentication (SCA). Use it to test saving cards with the Setup Intents API.

Card numbers
PaymentMethods
NUMBER
DESCRIPTION

This card requires authentication for one-time payments. However, if you set up this card and use the saved card for subsequent off-session payments, no further authentication is needed.

This card requires authentication on all transactions, regardless of how the card is set up.

This card requires authentication for one-time payments. All payments will be declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.

This card requires authentication for one-time and other on-session payments. However, all off-session payments will succeed as if the card has been previously set up.

3D Secure test card numbers and tokens

Not all cards support 3D Secure or require you to redirect the customer to their card issuer’s authentication page. Use the following card information to test 3D Secure payments—be aware that 3D Secure redirects won’t occur for payments created directly in the Stripe Dashboard.

Card numbers
Tokens
PaymentMethods
NUMBER
3D SECURE USAGE
DESCRIPTION

Required 3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.

Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.

Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.

Required 3D Secure authentication is required, but the 3D Secure lookup request will fail with a processing error. Payments will be declined with a card_declined failure code. By default, your Radar rules will request 3D Secure authentication for this card.

Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.

Supported 3D Secure authentication may still be performed, but is not required. However, attempts to perform 3D Secure result in a processing error. By default, your Radar rules will not request 3D Secure authentication for this card.

Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.

Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.

All other Visa and Mastercard test cards do not require authentication from the customer’s card issuer.

Testing for specific responses and errors

You can use the following test cards to create payments that produce specific responses—useful for testing different scenarios and error codes. Verification checks only run when the required information is provided (for example, for cvc_check to be set to fail, a CVC code must be provided).

Card numbers
Tokens
PaymentMethods
NUMBER
DESCRIPTION

Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).

Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).

Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.

The address_line1_check and address_zip_check verifications fail. If your account is blocking payments that fail postal code validation, the charge is declined.

Charge succeeds but the address_line1_check verification fails.

The address_zip_check verification fails. If your account is blocking payments that fail postal code validation, the charge is declined.

Charge succeeds but the address_zip_check and address_line1_check verifications are both unavailable.

Charge succeeds but refunding a captured charge fails asynchronously with a failure_reason of expired_or_canceled_card. Note that because refund failures are asynchronous, the refund will appear to be successful at first and will only have the failed status on subsequent fetches. We also notify you of refund failures using the charge.refund.updated webhook event.

Charge succeeds but refunds are initially held in the pending state. Some time later the refund is released from pending and sends a charge.refund.updated webhook event.

If a CVC number is provided, the cvc_check fails. If your account is blocking payments that fail CVC code validation, the charge is declined.

Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.

Results in a charge with a risk_level of elevated.

Results in a charge with a risk_level of highest.

Results in a charge with a risk_level of highest. The charge is blocked as it’s considered fraudulent.

Charge is declined with a card_declined code.

Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.

Charge is declined with a card_declined code. The decline_code attribute is lost_card.

Charge is declined with a card_declined code. The decline_code attribute is stolen_card.

Charge is declined with an expired_card code.

Charge is declined with an incorrect_cvc code.

Charge is declined with a processing_error code.

Charge is declined with an incorrect_number code as the card number fails the Luhn check.

Charge succeeds and returns a brand_product of MWE.

By default, passing address or CVC data with the card number causes the address and CVC checks to succeed. If this information isn’t specified, the value of the checks is null. Any expiration date in the future is considered valid.

You can also provide invalid card details to test specific error codes resulting from incorrect information being provided. For example:

  • invalid_expiry_month: Use an invalid month (for example, 13)
  • invalid_expiry_year: Use a year in the past (for example, 1970)
  • invalid_cvc: Use a two digit number (for example, 99)

Cartes Bancaires test card numbers

In test mode, you can use the test cards below to simulate a Cartes Bancaires charge:

NUMBER
DESCRIPTION

Creates a Cartes Bancaires card payment method co-branded with Visa.

Creates a Cartes Bancaires card payment method co-branded with Mastercard.

Disputes

In test mode, you can use the test cards below to simulate a disputed transaction:

Card numbers
Tokens
PaymentMethods
NUMBER
DESCRIPTION

With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.

With default account settings, charge succeeds, only to be disputed as product not received. This type of dispute is not protected if 3D Secure was run.

With default account settings, charge succeeds, only to be disputed as an inquiry.

With default account settings, charge succeeds, only to receive an early fraud warning.

Submit either of the following values for uncategorized_text to test a won or lost dispute outcome:

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 is not credited.

You can also use these values to test dispute outcomes in the Dashboard. Enter one of these values into the Additional Information field during evidence submission and then click Submit evidence.

Don’t store real user data in test mode Link accounts. Treat them as if they’re publicly available, because these accounts are tied to your publishable key.

You can create test mode accounts for Link with Stripe using any valid email address. You can use fixed one-time passcode values for authenticating test mode accounts, as outlined below:

VALUE
OUTCOME
Any other 6 digits not listed below Authentication succeeds.
000001 Authentication fails because the one-time passcode is invalid.
000002 Authentication fails because the one-time passcode is expired.
000003 Authentication fails because the maximum number of attempts is exceeded.

Rate limits

It is extremely unlikely for users to experience any rate limits with normal usage of the API, even at high volume. The most common causes for a user to experience rate limits are bugs, bulk data fetches, or extreme load testing.

If your requests begin to receive 429 HTTP errors, reduce the frequency of your requests. Each failed request is safe to retry as rate limiting takes place before any other action and prevents the request from being processed. When reducing your request frequency, we recommend an exponential backoff by first waiting one second before trying again. If your request continues to receive the same response, wait two seconds, then four seconds, and so on.

The rate limit in test mode is lower than the one in live mode. If you are experiencing rate limits but are unable to determine why, please let us know.

Sources

Use the following information when testing payments using Sources.

Redirect sources

When creating a test Source object that uses a redirect flow (for example, iDEAL), you can follow the URL returned in the redirect[url] field. This leads to a Stripe page that displays information about the API request, and where you can either authorize or cancel the payment.

Authorizing the payment redirects you to the URL specified in redirect[return_url].

BECS Direct Debit in Australia

You can create a test PaymentIntent that either succeeds or fails by doing the following:

  1. Create a test PaymentMethod with the test BSB 000-000 and a test account number from the list below.
  2. Use the resulting PaymentMethod in a confirmAuBecsDebitPayment request to create the test charge.
Test account numbers
ACCOUNT NUMBER
DESCRIPTION
000123456 The PaymentIntent status transitions from processing to succeeded. The mandate status remains active.
900123456 The PaymentIntent status transitions from processing to succeeded (with a three-minute delay). The mandate status remains active.
111111113 The PaymentIntent status transitions from processing to requires_payment_method with an account_closed failure code. The mandate status will become inactive.
111111116 The PaymentIntent status transitions from processing to requires_payment_method with a no_account failure code. The mandate status will become inactive.
222222227 The PaymentIntent status transitions from processing to requires_payment_method with a refer_to_customer failure code. The mandate status will remain active.
922222227 The PaymentIntent status transitions from processing to requires_payment_method with a refer_to_customer failure code (with a three-minute delay). The mandate status will remain active.
333333335 The PaymentIntent status transitions from processing to requires_payment_method with a debit_not_authorized failure code. The mandate status will become inactive.

SEPA Direct Debit

You can create a test PaymentIntent that either succeeds or fails by doing the following:

  1. Create a test PaymentMethod with a test account number.
  2. Use the resulting PaymentMethod in a confirmSepaDebitPayment request to create the test charge.
Test account numbers

ACCOUNT NUMBER
DESCRIPTION
AT611904300234573201 The PaymentIntent status transitions from processing to succeeded.
AT321904300235473204 The PaymentIntent status transitions from processing to succeeded after three minutes.
AT861904300235473202 The PaymentIntent status transitions from processing to requires_payment_method.
AT051904300235473205 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
AT591904300235473203 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.

Webhooks

To test your integration, perform actions using the API (in test mode) to send legitimate events to your endpoint. For instance, creating a charge triggers the charge.succeeded event that contains the charge data. You can easily trigger events with the Stripe CLI or Stripe for Visual Studio Code. You can then use the API to verify the resulting event data. If you’re migrating to the Payment Intents API, also see Monitoring a PaymentIntent with Webhooks.

You can also send test events to your integration’s endpoint within your account’s webhooks settings. However, the event data contained within these events is fabricated and not available in the API—its purpose is only to test that your endpoint is working and configured correctly.

See also

Not the solution you are looking for?

Please check other articles or open a support ticket.