[metadata]
algolia:article-format: markdoc
algolia:depth: 2
algolia:hierachy: Testing
algolia:subtitle: Simulate payments to test your integration.
algolia:title: Testing
description: Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes and bank authentication. You can also test non-card payment methods and redirects.
og:description: Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes and bank authentication. You can also test non-card payment methods and redirects.
og:image: https://d37ugbyn3rpeym.cloudfront.net/docs/og-image/testing.ogimage.png
og:title: Test card numbers
og:type: website
twitter:card: summary_large_image
twitter:description: Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes and bank authentication. You can also test non-card payment methods and redirects.
twitter:image: https://d37ugbyn3rpeym.cloudfront.net/docs/og-image/testing.ogimage.png
twitter:title: Test card numbers
viewport: width=device-width, initial-scale=1

[canonical-links]
https://docs.stripe.com/testing?locale=en-GB

[document-links]
/
3D Secure 2: https://stripe.com/guides/3d-secure-2
3D Secure test cards: /testing#regulatory-cards
3D Secure: /payments/3d-secure
4242 4242 4242 4242: /testing?testing-method=card-numbers#visa
API keys: /keys
Activity logs: /activity-logs
Agent skills: /skills
Best practices for managing secret API keys: /keys-best-practices
Checkout Sessions: /payments/checkout
Connect embedded components: /connect/supported-embedded-components/disputes-list
Contact Sales: https://stripe.com/contact/sales
Contact Support: https://support.stripe.com/
Create account: https://dashboard.stripe.com/register
Custom objects: /custom-objects
Customer: /api/customers
Dashboard: https://dashboard.stripe.com/sandboxes
Developer resources: /development
Discord: https://stripe.com/go/developer-chat
Dispute Resolution or Dispute Deflection: https://dashboard.stripe.com/settings/disputes
Dispute prevention: /disputes/prevention
Dynamic risk thresholds: /radar/risk-settings#dynamic-risk-thresholds
European Economic Area: https://en.wikipedia.org/wiki/European_Economic_Area
File uploads: /file-upload
Financial Connections: /financial-connections/testing#web-how-to-use-test-accounts
Get started: /get-started
Home: /
ISO 3166-1 alpha-2: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
India recurring payments: /india-recurring-payments?integration=paymentIntents-setupIntents#testing
Load testing: /rate-limits#load-testing
Luhn check: https://en.wikipedia.org/wiki/Luhn_algorithm
Markdoc: https://markdoc.dev
Mastercard compliance dispute: /disputes/api/mastercard-compliance#testing
Model Context Protocol: /mcp
Money management: /money-management
Overview: /development
Overview: /extensibility
Overview: /testing/overview
Partner certification: /partners/training-and-certification
Payment Links: /payment-links
PaymentIntent cancellation: /api/payment_intents/cancel
Payments: /payments
Platforms and marketplaces: /connect
Read llms.txt: /llms.txt
Revenue: /revenue
Sandboxes: /sandboxes
Sign in: https://dashboard.stripe.com/login?redirect=https%3A%2F%2Fdocs.stripe.com%2Ftesting
Smart Disputes: /disputes/smart-disputes
Stripe CLI: /stripe-cli
Stripe Directory: /directory
Stripe Discord server: /discord
Stripe Services Agreement: https://stripe.com/legal/ssa#1-your-stripe-account
Stripe Signals: /signals
Stripe for Visual Studio Code: /stripe-vscode
Stripe health alerts: /health-alerts
Stripebot web crawler: /stripebot-crawler
Strong Customer Authentication: /strong-customer-authentication
Test Apple Pay and Google Pay rendering: /testing/wallets
Test Stripe Terminal: /terminal/references/testing
Testing use cases: /testing-use-cases
Testing your Billing integration: /billing/testing
Testing your Connect integration: /connect/testing
Testing your Terminal integration: /terminal/references/testing
Testing: /testing/overview
Trigger events using the Stripe CLI: /webhooks#test-webhook
URL parameter: /payment-links/customize#customize-checkout-with-url-parameters
Upgrade your API version: /upgrades
Visa Compelling Evidence 3.0 eligible dispute: /disputes/api/visa-ce3#testing
Visa compliance dispute: /disputes/api/visa-compliance#testing
an early fraud warning: /disputes/how-disputes-work#early-fraud-warnings
an enquiry: /disputes/how-disputes-work#inquiries
block it with a custom Radar rule: /radar/rules/reference#post-authorization-attributes
card error: /error-handling#payment-errors
card errors with an error code of fraud: /error-handling
card_declined: /error-codes#card-declined
card_velocity_exceeded: /declines/codes#card_velocity_exceeded
cardholder_verification_method: /api/charges/object#charge_object-payment_method_details-card_present-receipt-cardholder_verification_method
changelog: /changelog
charge.succeeded: /api#event_types-charge.succeeded
decline code: /declines/codes
depending on your settings.: /radar/rules#traditional-bank-checks
depending on your settings: /radar/risk-settings
depending on your settings: /radar/rules#traditional-bank-checks
disputed transaction: /disputes
domain registration: /payments/payment-methods/pmd-registration
error code: /error-codes
event destination: /event-destinations
event: /api/events/types#event_types-refund.failed
event: /api/events/types#event_types-refund.updated
expired_card: /error-codes#expired-card
fraudulent: /disputes/categories
free trial abuse risk control: /radar/risk-settings
generic_decline: /declines/codes#generic_decline
high risk of fraud: /radar/transaction-risk-prevention#high-risk
incorrect_cvc: /declines/codes#incorrect_cvc
incorrect_number: /declines/codes#incorrect_number
insufficient_funds: /declines/codes#insufficient_funds
invalid_cvc: /declines/codes#invalid_cvc
invalid_expiry_month: /declines/codes#invalid_expiry_month
invalid_expiry_year: /declines/codes#invalid_expiry_year
isn’t protected: /payments/3d-secure/authentication-flow#disputed-payments
load testing: /rate-limits#load-testing
lost_card: /declines/codes#lost_card
multiple days: /payments/ach-direct-debit#timing
multiple times: /disputes/how-disputes-work#multiple-disputes
on-session: /payments/existing-customers?platform=web&ui=elements
one-time payments: /payments/accept-a-payment?platform=web
one-time: /payments/accept-a-payment?platform=web
payment methods settings in the Dashboard: https://dashboard.stripe.com/settings/payment_methods
pm_card_visa: /testing?testing-method=payment-methods#visa
pricing tables: /payments/checkout/pricing-table
processing_error: /error-codes#processing-error
product not received: /disputes/categories
protected: /payments/3d-secure/authentication-flow#disputed-payments
queue it for review: /radar/transaction-reviews
rate limiter: /rate-limits
rate limits: /testing#rate-limits
refunds: /testing#refunds
requires redirects: /payments/payment-methods/payment-method-support#additional-api-supportability
respond in the Dashboard: /disputes/responding
respond using the API: /disputes/api
risk level of “elevated”: /radar/transaction-risk-prevention#elevated-risk
risk level of “highest”: /radar/transaction-risk-prevention#high-risk
sandbox: /sandboxes
set it up: /payments/save-and-reuse
set up your Stripe account: /get-started/account/set-up
set up: /payments/save-and-reuse
stolen_card: /declines/codes#stolen_card
test API keys: /keys#obtain-api-keys
testing with location-formatted emails: /payments/currencies/localize-prices/adaptive-pricing#testing
tokenised account number: /financial-connections/tokenized-account-numbers
uncategorised_text: /api/disputes/update#update_dispute-evidence-uncategorized_text
using Stripe for Visual Studio Code: /stripe-vscode#webhooks

[content]
Test card numbers | Stripe Documentation
Skip to content
Testing
Create account
or
Sign in
Search
/
Ask AI
Create account
Sign in
Get started
Payments
Revenue
Platforms and marketplaces
Money management
Developer resources
APIs & SDKs
Help
Overview
Versioning
Changelog
Upgrade your API version
Upgrade your SDK version
Essentials
SDKs
API
Testing
Overview
Testing
Testing use cases
Sandboxes
Test Apple Pay and Google Pay rendering
Stripe CLI
Tools
Stripe Dashboard
Workbench
Developers Dashboard
Stripe for Visual Studio Code
Terraform
Stripe Discord server
Features
Workflows
Batch Jobs
Event Destinations
Stripe health alerts
Stripe Signals
File uploads
AI solutions
Model Context Protocol
Agent skills
Stripe Directory
Extend Stripe
Overview
Build Stripe apps
Use apps from Stripe
Build extensions
Custom objects
Security and privacy
Security
Activity logs
Stripebot web crawler
Privacy
Partners
Partner ecosystem
Partner certification
Australia
English (United Kingdom)
Home
/
Developer resources
/
Testing
Testing
Simulate payments to test your integration.
Ask about this page
Copy for LLM
View as Markdown
Install tools
Test your integration in a
sandbox
by simulating transactions with test values – these transactions don’t 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 aren’t 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.
Don’t 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 you’re serving a payment form to test interactively or writing test code.
Don't use real card details
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.
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 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
Select a language
cURL
Stripe CLI
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
curl
https://api.stripe.com/v1/payment_intents
\
-u
"
sk_test_wsFx86XDJWwmE4dMskBgJYrt
:"
\
-d
amount
=
500
\
-d
currency
=
gbp
\
-d
payment_method
=
pm_card_visa
\
-d
"payment_method_types[]
=
card
"
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. Store live API keys in a secrets vault or environment variables. Don’t 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 isn’t the US (such as JCB and UnionPay) might be subject to a cross-border fee, even in testing environments.
Card numbers
PaymentMethods
Tokens
Brand
Number
CVC
Date
Visa
4242
4242
4242
4242
Any 3 digits
Any future date
Visa (debit)
4000
0566
5566
5556
Any 3 digits
Any future date
Mastercard
5555
5555
5555
4444
Any 3 digits
Any future date
Mastercard (2-series)
2223
0031
2200
3222
Any 3 digits
Any future date
Mastercard (debit)
5200
8282
8282
8210
Any 3 digits
Any future date
Mastercard (prepaid)
5105
1051
0510
5100
Any 3 digits
Any future date
American Express
3782
822463
10005
Any 4 digits
Any future date
American Express
3714
496353
98431
Any 4 digits
Any future date
Discover
6011
1111
1111
1117
Any 3 digits
Any future date
Discover
6011
0009
9013
9424
Any 3 digits
Any future date
Discover (debit)
6011
9811
1111
1113
Any 3 digits
Any future date
Diners Club
3056
9300
0902
0004
Any 3 digits
Any future date
Diners Club (14-digit card)
3622
720627
1667
Any 3 digits
Any future date
BCcard and DinaCard
6555
9000
0060
4105
Any 3 digits
Any future date
JCB
3566
0020
2036
0505
Any 3 digits
Any future date
UnionPay
6200
0000
0000
0005
Any 3 digits
Any future date
UnionPay (debit)
6200
0000
0000
0047
Any 3 digits
Any future date
UnionPay (19-digit card)
6205
5000
0000
0000
004
Any 3 digits
Any 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.
Card numbers
PaymentMethods
Tokens
Brand/Co-brand
Number
CVC
Date
Cartes Bancaires/Visa
4000
0025
0000
1001
Any 3 digits
Any future date
Cartes Bancaires/Mastercard
5555
5525
0000
1001
Any 3 digits
Any future date
eftpos Australia/Visa
4000
0503
6000
0001
Any 3 digits
Any future date
eftpos Australia/Mastercard
5555
0503
6000
0080
Any 3 digits
Any future date
Simulate a payment by country
To simulate successful payments from specific countries, use test cards from the following sections.
Security tip
Strong Customer Authentication
regulations require
3D Secure
authentication for online payments within the
European Economic Area
. The test cards in the Europe and Middle East section simulate a payment that succeeds without authentication. We also recommend testing authentication scenarios using
3D Secure test cards
.
Card numbers
PaymentMethods
Tokens
Country
Number
Brand
AMERICAS
United States (US)
4242
4242
4242
4242
Visa
Argentina (AR)
4000
0003
2000
0021
Visa
Brazil (BR)
4000
0007
6000
0002
Visa
Canada (CA)
4000
0012
4000
0000
Visa
Chile (CL)
4000
0015
2000
0001
Visa
Colombia (CO)
4000
0017
0000
0003
Visa
Costa Rica (CR)
4000
0018
8000
0005
Visa
Ecuador (EC)
4000
0021
8000
0000
Visa
Mexico (MX)
4000
0048
4000
8001
Visa
Mexico (MX)
5062
2100
0000
0009
Carnet
Panama (PA)
4000
0059
1000
0000
Visa
Paraguay (PY)
4000
0060
0000
0066
Visa
Peru (PE)
4000
0060
4000
0068
Visa
Uruguay (UY)
4000
0085
8000
0003
Visa
EUROPE and MIDDLE EAST
United Arab Emirates (AE)
4000
0078
4000
0001
Visa
United Arab Emirates (AE)
5200
0078
4000
0022
Mastercard
Austria (AT)
4000
0004
0000
0008
Visa
Belgium (BE)
4000
0005
6000
0004
Visa
Bulgaria (BG)
4000
0010
0000
0000
Visa
Belarus (BY)
4000
0011
2000
0005
Visa
Croatia (HR)
4000
0019
1000
0009
Visa
Cyprus (CY)
4000
0019
6000
0008
Visa
Czech Republic (CZ)
4000
0020
3000
0002
Visa
Denmark (DK)
4000
0020
8000
0001
Visa
Estonia (EE)
4000
0023
3000
0009
Visa
Finland (FI)
4000
0024
6000
0001
Visa
France (FR)
4000
0025
0000
0003
Visa
Germany (DE)
4000
0027
6000
0016
Visa
Gibraltar (GI)
4000
0029
2000
0005
Visa
Greece (GR)
4000
0030
0000
0030
Visa
Hungary (HU)
4000
0034
8000
0005
Visa
Ireland (IE)
4000
0037
2000
0005
Visa
Italy (IT)
4000
0038
0000
0008
Visa
Latvia (LV)
4000
0042
8000
0005
Visa
Liechtenstein (LI)
4000
0043
8000
0004
Visa
Lithuania (LT)
4000
0044
0000
0000
Visa
Luxembourg (LU)
4000
0044
2000
0006
Visa
Malta (MT)
4000
0047
0000
0007
Visa
Netherlands (NL)
4000
0052
8000
0002
Visa
Norway (NO)
4000
0057
8000
0007
Visa
Poland (PL)
4000
0061
6000
0005
Visa
Portugal (PT)
4000
0062
0000
0007
Visa
Romania (RO)
4000
0064
2000
0001
Visa
Saudi Arabia (SA)
4000
0068
2000
0007
Visa
Slovenia (SI)
4000
0070
5000
0006
Visa
Slovakia (SK)
4000
0070
3000
0001
Visa
Spain (ES)
4000
0072
4000
0007
Visa
Sweden (SE)
4000
0075
2000
0008
Visa
Switzerland (CH)
4000
0075
6000
0009
Visa
United Kingdom (GB)
4000
0082
6000
0000
Visa
United Kingdom (GB)
4000
0582
6000
0005
Visa (debit)
United Kingdom (GB)
5555
5582
6555
4449
Mastercard
ASIA PACIFIC
Regional considerations
India
To test subscriptions that require mandates and pre-debit notifications, see
India recurring payments
.
Australia (AU)
4000
0003
6000
0006
Visa
China (CN)
4000
0015
6000
0002
Visa
Hong Kong (HK)
4000
0034
4000
0004
Visa
India (IN)
4000
0035
6000
0008
Visa
Japan (JP)
4000
0039
2000
0003
Visa
Japan (JP)
3530
1113
3330
0000
JCB
Malaysia (MY)
4000
0045
8000
0002
Visa
New Zealand (NZ)
4000
0055
4000
0008
Visa
Singapore (SG)
4000
0070
2000
0003
Visa
Taiwan (TW)
4000
0015
8000
0008
Visa
Thailand (TH)
4000
0076
4000
0003
Visa (credit)
Thailand (TH)
4000
0576
4000
0008
Visa (debit)
Simulate customer location with email
When testing
Checkout Sessions
,
Payment Links
or
pricing tables
, you can simulate a customer’s 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
Below are test card numbers for simulating transactions using a health savings account (HSA) and a flexible spending account (FSA). These accounts are commonly used for medical expenses, and testing with them ensures proper handling of healthcare-related transactions within your application.
Card numbers
PaymentMethods
Brand/Type
Number
CVC
Date
Visa FSA
4000
0512
3000
0072
Any 3 digits
Any future date
Visa HSA
4000
0512
3000
0072
Any 3 digits
Any future date
Mastercard FSA
5200
8282
8282
8897
Any 3 digits
Any future date
Simulate a declined payment
To test your integration’s 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 behaviour. Stripe skips the CVC check if you omit it, so the check can’t fail. To simulate an incorrect CVC, use the “Incorrect CVC decline” test card listed in the following table and provide any three-digit CVC.
Card numbers
PaymentMethods
Tokens
Description
Number
Error code
Decline code
Generic decline
4000
0000
0000
0002
card_declined
generic_decline
Insufficient funds decline
4000
0000
0000
9995
card_declined
insufficient_funds
Lost card decline
4000
0000
0000
9987
card_declined
lost_card
Stolen card decline
4000
0000
0000
9979
card_declined
stolen_card
Expired card decline
4000
0000
0000
0069
expired_card
n/a
Incorrect CVC decline
4000
0000
0000
0127
incorrect_cvc
n/a
Processing error decline
4000
0000
0000
0119
processing_error
n/a
Incorrect number decline
4242
4242
4242
4241
incorrect_number
n/a
Exceeding velocity limit decline
4000
0000
0000
6975
card_declined
card_velocity_exceeded
You can’t attach cards that simulate issuer declines to a
Customer
object. To simulate a declined payment with an attached card, use the “Decline after attaching” test card listed in the following table.
Description
Number
Details
Decline after attaching
4000
0000
0000
0341
Attaching 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
.
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 can’t fail.
Card numbers
PaymentMethods
Tokens
Description
Number
Details
Always blocked
4100
0000
0000
0019
The charge has a
risk level of “highest”
Radar always blocks it.
Highest risk
4000
0000
0000
4954
The charge has a
risk level of “highest”
Radar might block it
depending on your settings
.
Elevated risk
4000
0000
0000
9235
The charge has a
risk level of “elevated”
Radar might
queue it for review
.
High fraud dispute score
4000
0084
0000
0407
This charge has a high fraud dispute score.
Radar might block it
depending on your settings
.
High early fraud warning score
4000
0084
0000
0159
This charge has a high early fraud warning score.
Radar might block it
depending on your settings
.
Dynamic risk thresholds
4000
0084
0000
1017
This charge triggers the Radar Dynamic risk thresholds control, when enabled.
Radar blocks the transaction if you enable the
Dynamic risk thresholds
.
Free trial abuse
4001
8588
2184
3804
This charge triggers the Radar free trial abuse risk control, when enabled.
Radar blocks the transaction if you enable the
free trial abuse risk control
.
Adaptive 3DS
4000
0084
0560
0003
This charge triggers the Radar Adaptive 3DS risk control, when enabled.
If you enable Adaptive 3DS, Radar requests 3DS authentication when using this test card.
CVC check fails
4000
0000
0000
0101
If you provide a CVC number, the CVC check fails.
Radar might block it
depending on your settings.
Postal code check fails
4000
0000
0000
0036
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
4000
0584
0030
7872
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
4000
0584
0030
6072
If you provide a postcode, the postcode check fails with a
risk level of “elevated”
Radar might block it
depending on your settings
.
Line1 check fails
4000
0000
0000
0028
The address line 1 check fails.
The payment succeeds unless you
block it with a custom Radar rule
.
Address checks fail
4000
0000
0000
0010
The address postal code check and address line 1 check both fail.
Radar might block it
depending on your settings.
Address unavailable
4000
0000
0000
0044
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
.
Trigger an error with 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
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
.
Card numbers
PaymentMethods
Tokens
Description
Number
Details
Fraudulent
4000
0000
0000
0259
With default account settings, charge succeeds, only to be disputed as
fraudulent
. This type of dispute is
protected
after 3D Secure authentication.
Not received
4000
0000
0000
2685
With default account settings, charge succeeds, only to be disputed as
product not received
. This type of dispute
isn’t protected
after 3D Secure authentication.
Enquiry
4000
0000
0000
1976
With default account settings, charge succeeds, only to be disputed as
an enquiry
.
Warning
4000
0000
0000
5423
With default account settings, charge succeeds, only to receive
an early fraud warning
.
Multiple disputes
4000
0004
0400
0079
With default account settings, charge succeeds, only to be disputed
multiple times
.
Visa Compelling Evidence 3.0
4000
0004
0400
0038
With default account settings, charge succeeds, only to be disputed as a
Visa Compelling Evidence 3.0 eligible dispute
.
Visa compliance
4000
0084
0000
0779
With default account settings, charge succeeds, only to be disputed as a
Visa compliance dispute
.
Mastercard compliance
5105
0084
0000
0002
With default account settings, charge succeeds, only to be disputed as a
Mastercard compliance dispute
.
Smart disputes
4000
0000
0100
0043
With default account settings, charge succeeds, only to be disputed as a
Smart Disputes
eligible 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
uncategorised_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
.
Evidence
Description
winning
_
evidence
Closes the dispute as won and credits your account for the amount of the charge and related fees.
losing
_
evidence
Closes the dispute as lost without crediting your account. For enquiries, this closes the enquiry without escalation.
escalate
_
inquiry
_
evidence
Escalates the enquiry to a chargeback. This transitions the enquiry to a full dispute and debits your account for the amount of the dispute and related fees.
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.
Card numbers
PaymentMethods
Tokens
Description
Number
Details
Visa Rapid Dispute Resolution
4000
0004
0400
4816
Charge succeeds, then Visa RDR prevents the dispute if the account is enrolled in Dispute Resolution. Otherwise, creates a dispute.
Verifi CE3 block
4000
0004
0400
5649
Charge succeeds, then Compelling Evidence 3.0 blocks the dispute if the account is enrolled in Dispute Deflection. Otherwise, creates a dispute.
Ethoca alert
5105
0003
0000
0018
Charge succeeds, then Ethoca Alerts prevents the dispute if the account is enrolled in Dispute Resolution. Otherwise, creates a dispute.
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 behaviours, use the test cards in this section. With all other test cards, refunds succeed immediately and don’t change status after that.
Card numbers
PaymentMethods
Tokens
Description
Number
Details
Asynchronous success
4000
0000
0000
7726
The 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 failure
4000
0000
0000
5126
The 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.
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.
Card numbers
PaymentMethods
Tokens
Description
Number
Details
Bypass pending balance
4000
0000
0000
0077
The US charge succeeds. Funds are added directly to your available balance, bypassing your pending balance.
Bypass pending balance
4000
0037
2000
0278
The international charge succeeds. Funds are added directly to your available balance, bypassing 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 behaviour, 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 front end 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.
Card numbers
PaymentMethods
Description
Number
Details
Authenticate unless set up
4000
0025
0000
3155
This 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. However, on-session payments with this card always require authentication.
Always authenticate
4000
0027
6000
3184
This card requires authentication on all transactions, regardless of how the card is set up.
Already set up
4000
0038
0000
0446
This 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 funds
4000
0082
6000
3178
This 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.
All 3DS references indicate
3D Secure 2
.
Card numbers
PaymentMethods
Tokens
3D Secure usage
Outcome
Number
Details
3DS Required
OK
4000
0000
0000
3220
3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card. Ireland-issued (
IE
).
3DS Required
OK
4000
0084
0000
0027
3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card. US-issued (
US
).
3DS Required
Declined
4000
0084
0000
1629
3D 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 Required
Error
4000
0084
0000
1280
3D 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 Supported
OK
4000
0000
0000
3055
3D 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 Supported
Error
4000
0000
0000
3097
3D 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 Supported
Unenrolled
4242
4242
4242
4242
3D 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
3782
822463
10005
3D Secure isn’t supported on this card and can’t be invoked. The PaymentIntent or SetupIntent proceeds without performing authentication.
3DS Frictionless flow
OK
4000
0000
3220
0000
3D Secure authentication is required on all transactions, regardless of how the card is set up. The authentication proceeds through a frictionless flow, and succeeds.
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 behaviour. Because they’re not useful in API calls, we don’t provide any
PaymentMethod
or
Token
values to test with.
Challenge flow
Number
Details
Out of band
4000
5826
0000
0094
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with Out of Band UI.
One time passcode
4000
5826
0000
0045
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with One Time Passcode UI.
Single select
4000
5826
0000
0102
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with single-select UI.
Multi select
4000
5826
0000
0110
3D Secure 2 authentication must be completed on all transactions. Triggers the challenge flow with multi-select UI.
Simulate a 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.
Description
Number
Details
Captcha challenge
4000
0000
0000
1208
The charge succeeds if the user correctly answers the captcha challenge.
Captcha challenge
4000
0000
0000
3725
The charge succeeds if the user correctly answers the captcha challenge.
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. 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.
Card numbers
PaymentMethods
Description
Number
Details
Offline PIN
4001
0070
2000
0002
This 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 retry
4000
0082
6000
0075
Simulates 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 PIN
4001
0003
6000
0005
This 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 retry
4000
0027
6000
0008
Simulates 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
.
Test a webhook or event destination
To test your webhook endpoint or
event destination
, choose one of these two options:
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
.
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.
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 you’re serving a payment form you can test interactively or writing test code.
Different payment methods have different test procedures:
ACH Direct Debit
SEPA Direct Debit
BACS Direct Debit
AU BECS Direct Debit
Others
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
.
If your domain is
{domain}
and your username is
{username}
, use the following email format to send test transaction emails:
{username}+test_email@{domain}
.
For example, if your domain is
example.com
and your username is
info
, use the format
info+test_email@example.com
for testing ACH Direct Debit payments. This format ensures that emails are routed correctly. If you don’t include the
+test_email
suffix, we won’t send the email.
Common mistake
You must
set up 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 number
Token
Routing number
Behavior
000123456789
pm
_
usBankAccount
_
success
110000000
The payment succeeds.
000111111113
pm
_
usBankAccount
_
accountClosed
110000000
The payment fails because the account is closed.
000000004954
pm
_
usBankAccount
_
riskLevelHighest
110000000
The payment is blocked by Radar due to a
high risk of fraud
.
000111111116
pm
_
usBankAccount
_
noAccount
110000000
The payment fails because no account is found.
000222222227
pm
_
usBankAccount
_
insufficientFunds
110000000
The payment fails due to insufficient funds.
000333333335
pm
_
usBankAccount
_
debitNotAuthorized
110000000
The payment fails because debits aren’t authorized.
000444444440
pm
_
usBankAccount
_
invalidCurrency
110000000
The payment fails due to invalid currency.
000666666661
pm
_
usBankAccount
_
failMicrodeposits
110000000
The payment fails to send microdeposits.
000555555559
pm
_
usBankAccount
_
dispute
110000000
The payment triggers a dispute.
000000000009
pm
_
usBankAccount
_
processing
110000000
The payment stays in processing indefinitely. Useful for testing
PaymentIntent cancellation
.
000777777771
pm
_
usBankAccount
_
weeklyLimitExceeded
110000000
The payment fails due to payment amount causing the account to exceed its weekly payment volume limit.
000888888885
110000000
The payment fails because of a deactivated
tokenised account number
.
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 values
0.01 descriptor code values
Scenario
32
and
45
SM11AA
Simulates verifying the account.
10
and
11
SM33CC
Simulates exceeding the number of allowed verification attempts.
40
and
41
SM44DD
Simulates a microdeposit timeout.
Test settlement behaviour
Test transactions settle instantly and are added to your available test balance. This behaviour differs from livemode, where transactions can take
multiple days
to settle in your available balance.
Test asynchronous payment methods
Asynchronous, or “delayed notification”, payment methods don’t 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 working days in live mode.
This behaviour differs from most card payments, which usually receive an immediate authorisation response from the issuer.
Don’t rely on a client-side callback or redirect to determine the final status for these payment methods. Always use webhooks to drive fulfilment.
Understand the PaymentIntent lifecycle
Payment methods that don’t require further action from your customer to authorise the payment, such as bank debits, move through these states after your customer submits payment:
Step
State
Description
1
processing
Your customer submitted the payment, and the outcome isn’t yet known.
2a
succeeded
The payment is confirmed.
2b
requires
_
payment
_
method
The payment failed, for example because of insufficient funds or a closed account.
Payment methods that require further action from your customer to authorise the payment, such as voucher-based methods including Multibanco, Boleto, OXXO, and Konbini, add an earlier state before
processing
:
Step
State
Description
1
requires
_
action
Stripe issued a voucher or payment code and is waiting for your customer to pay out of band.
2
processing
Stripe is waiting for the final outcome, and your customer can no longer complete the voucher payment through the original flow.
3a
succeeded
Your customer paid the voucher.
3b
requires
_
payment
_
method
The voucher expired or the payment failed.
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:
Event
Description
Recommended action
payment
_
intent
.
processing
Your customer successfully submitted payment and the result is pending. This is most common for bank debits.
Send a “payment pending” confirmation email and hold order fulfilment.
payment
_
intent
.
succeeded
The payment is confirmed.
Fulfil the order.
payment
_
intent
.
payment
_
failed
The payment failed, such as for insufficient funds, an expired voucher, or a closed account.
Notify your customer and request a new payment method.
payment
_
intent
.
requires
_
action
Stripe issued a voucher or out-of-band action and is waiting for your customer. This applies to Multibanco, Boleto, OXXO and Konbini.
Send your customer the voucher or payment instructions.
payment
_
intent
.
canceled
The
PaymentIntent
was cancelled before your customer completed payment.
Notify your customer. Don’t fulfil the order.
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.
Method
Test values
Expected webhooks for success
Expected webhooks for failure
SEPA Direct Debit
See SEPA Direct Debit
payment
_
intent
.
processing
, then
payment
_
intent
.
succeeded
payment
_
intent
.
processing
, then
payment
_
intent
.
payment
_
failed
ACH Direct Debit
See ACH Direct Debit
payment
_
intent
.
processing
, then
payment
_
intent
.
succeeded
payment
_
intent
.
processing
, then
payment
_
intent
.
payment
_
failed
BACS Direct Debit
See Bacs Direct Debit
payment
_
intent
.
processing
, then
payment
_
intent
.
succeeded
payment
_
intent
.
processing
, then
payment
_
intent
.
payment
_
failed
AU BECS Direct Debit
See BECS Direct Debit
payment
_
intent
.
processing
, then
payment
_
intent
.
succeeded
payment
_
intent
.
processing
, then
payment
_
intent
.
payment
_
failed
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.
Method
Expected webhooks for success
Expected webhooks for failure or expiry
Multibanco
payment
_
intent
.
requires
_
action
, then
payment
_
intent
.
processing
, then
payment
_
intent
.
succeeded
payment
_
intent
.
requires
_
action
, then
payment
_
intent
.
processing
, then
payment
_
intent
.
payment
_
failed
Boleto, OXXO, and Konbini
payment
_
intent
.
requires
_
action
, then
payment
_
intent
.
succeeded
payment
_
intent
.
requires
_
action
, then
payment
_
intent
.
payment
_
failed
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 doesn’t 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 don’t 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:
Command Line
stripe
listen
--forward-to
localhost:4242/webhook
Trigger specific events manually to test your handler in isolation without running a full payment flow:
Command Line
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.
Don’t fulfil 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 expiry 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 isn’t known when the sheet completes. Tell your customers their order is confirmed, and fulfil only after
payment
_
intent
.
succeeded
arrives.
Review asynchronous payment methods
The following table summarises the PaymentIntent state each method enters immediately after confirmation, and the webhook events your server should expect once the delayed outcome arrives.
Method
Category
State after confirm
Delayed success event
Delayed failure event
SEPA Direct Debit
Bank debit
processing
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
ACH Direct Debit
Bank debit
processing
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
BACS Direct Debit
Bank debit
processing
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
AU BECS Direct Debit
Bank debit
processing
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
Multibanco
Voucher
requires
_
action
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
Boleto
Voucher
requires
_
action
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
OXXO
Voucher
requires
_
action
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
Konbini
Voucher
requires
_
action
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
Pay by Bank
Redirect and delayed notification
requires
_
action
, then usually
succeeded
or
requires
_
payment
_
method
after the redirect
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
BLIK
Redirect and delayed notification or timeout
varies
payment
_
intent
.
succeeded
payment
_
intent
.
payment
_
failed
Test
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:
Value
Outcome
Any other 6 digits not listed below
Success
000001
Error, code invalid
000002
Error, code expired
000003
Error, 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.
Test a redirect-based flow
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:
Go to the
payment methods settings in the Dashboard
and enable a supported payment method by clicking
Turn on
in your testing environment.
Collect payment details.
Submit the payment to Stripe.
Authorise 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?
Yes
No
Need help?
Contact Support
.
Chat with Stripe developers on
Discord
.
Check out our
changelog
.
Questions?
Contact Sales
.
LLM?
Read llms.txt
.
Powered by
Markdoc
On this page
Related Guides
Testing use cases
API keys
