Stripe Test Card Numbers
Every Stripe test card, test bank account and test IBAN, with what each one does. Click any value to copy it.
Any 3 digits
(4 digits for Amex)
Any future date
e.g. 12/34
Any 5 digits
e.g. 42424
Successful payment test cards
Cards that produce successful charges with no authentication required.
4242 4242 4242 4242
Succeeds and immediately processes the payment.
4000 0566 5566 5556
Succeeds and immediately processes the payment.
5555 5555 5555 4444
Succeeds and immediately processes the payment.
2223 0031 2200 3222
Succeeds and immediately processes the payment.
5200 8282 8282 8210
Succeeds and immediately processes the payment.
5105 1051 0510 5100
Succeeds and immediately processes the payment.
3782 822463 10005
Succeeds and immediately processes the payment.
3714 496353 98431
Succeeds and immediately processes the payment.
6011 1111 1111 1117
Succeeds and immediately processes the payment.
6011 0009 9013 9424
Succeeds and immediately processes the payment.
3056 9300 0902 0004
Succeeds and immediately processes the payment.
3622 720627 1667
Succeeds and immediately processes the payment.
3566 0020 2036 0505
Succeeds and immediately processes the payment.
6200 0000 0000 0005
Succeeds and immediately processes the payment.
Declined test cards
Cards that simulate various decline scenarios for testing error handling.
4000 0000 0000 0002
Card declined with a generic_decline code.
4000 0000 0000 9995
Card declined with insufficient_funds code.
4000 0000 0000 9987
Card declined with lost_card code.
4000 0000 0000 9979
Card declined with stolen_card code.
4000 0000 0000 0069
Card declined with expired_card code.
4000 0000 0000 0127
Card declined with incorrect_cvc code.
4000 0000 0000 0119
Card declined with processing_error code.
4242 4242 4242 4241
Card declined with incorrect_number code.
4000 0000 0000 0101
The cvc_check fails if a CVC is provided.
4000 0000 0000 0341
Attaching the card to a Customer succeeds, but charges fail.
3D Secure (SCA) test cards
Cards that test 3D Secure (SCA) authentication flows.
4000 0000 0000 3220
3D Secure 2 authentication required. Completes successfully.
4000 0000 0000 3063
3D Secure 2 authentication required. The customer fails to authenticate.
4000 0000 0000 3055
3D Secure 2 authentication may be performed but is not required.
4000 0000 0000 3097
3D Secure 2 authentication required but payments will be declined.
4000 0025 0000 3155
3D Secure 2 required on setup. Authentication succeeds.
4000 0027 6000 3184
3D Secure required. 3D Secure 2 challenge flow.
4000 0082 6000 3178
3D Secure required. 3D Secure 2 frictionless flow.
International test cards by country
Cards from different countries to test international payment scenarios.
4000 0007 6000 0002
Brazil. Successful charge.
4000 0012 4000 0000
Canada. Successful charge.
4000 0048 4000 8001
Mexico. Successful charge.
4000 0004 0000 0008
Austria. Successful charge.
4000 0005 6000 0004
Belgium. Successful charge.
4000 0020 8000 0001
Denmark. Successful charge.
4000 0024 6000 0001
Finland. Successful charge.
4000 0025 0000 0003
France. Successful charge.
4000 0027 6000 0016
Germany. Successful charge.
4000 0037 2000 0005
Ireland. Successful charge.
4000 0038 0000 0008
Italy. Successful charge.
4000 0052 8000 0002
Netherlands. Successful charge.
4000 0057 8000 0007
Norway. Successful charge.
4000 0062 0000 0007
Portugal. Successful charge.
4000 0072 4000 0007
Spain. Successful charge.
4000 0075 2000 0008
Sweden. Successful charge.
4000 0025 6000 0009
United Kingdom. Successful charge.
4000 0003 6000 0006
Australia. Successful charge.
4000 0055 4000 0008
New Zealand. Successful charge.
4000 0039 2000 0003
Japan. Successful charge.
4000 0070 2000 0003
Singapore. Successful charge.
Dispute and early fraud warning test cards
Cards that trigger disputes and specific refund behaviors.
4000 0000 0000 0259
Charge succeeds, but a dispute is created (fraudulent).
4000 0000 0000 1976
Charge succeeds, but a dispute is created (product_not_received).
4000 0000 0000 5423
Charge succeeds, but a dispute is created (inquiry).
4000 0000 0000 2685
Charge succeeds, but an early fraud warning is created.
ACH Direct Debit test bank accounts
US bank account numbers for ACH Direct Debit in test mode. Every account uses routing number 110000000. Accounts that succeed or fail automatically still need verifying first: enter one of the descriptor codes (or microdeposit amounts) at the end of the list.
110000000
Use this routing number with every test account below.
000123456789
The payment succeeds. Test PaymentMethod: pm_usBankAccount_success.
000111111113
The payment fails because the account is closed (pm_usBankAccount_accountClosed).
000111111116
The payment fails because no account is found (pm_usBankAccount_noAccount).
000222222227
The payment fails due to insufficient funds (pm_usBankAccount_insufficientFunds).
000333333335
The payment fails because debits aren't authorized (pm_usBankAccount_debitNotAuthorized).
000444444440
The payment fails due to invalid currency (pm_usBankAccount_invalidCurrency).
000555555559
The payment triggers a dispute (pm_usBankAccount_dispute).
000000000009
The payment stays in processing indefinitely. Useful for testing PaymentIntent cancellation (pm_usBankAccount_processing).
000000004954
The payment is blocked by Radar for the highest fraud risk (pm_usBankAccount_riskLevelHighest).
000666666661
The payment fails to send microdeposits (pm_usBankAccount_failMicrodeposits).
000777777771
The payment fails because it exceeds the account's weekly payment volume limit (pm_usBankAccount_weeklyLimitExceeded).
000888888885
The payment fails because of a deactivated tokenized account number.
SM11AA
Verifies the account. Microdeposit amounts 32 and 45 do the same.
SM33CC
Simulates exceeding the allowed verification attempts. Same as amounts 10 and 11.
SM44DD
Simulates a microdeposit timeout. Same as amounts 40 and 41.
SEPA Direct Debit test IBANs
German test IBANs for SEPA Direct Debit. Stripe publishes the same ten outcomes for other SEPA countries (Austria, Belgium, France, Ireland and more) on its testing page.
DE89 3704 0044 0532 0130 00
The PaymentIntent goes from processing to succeeded.
DE08 3704 0044 0532 0130 03
Stays processing for at least three minutes, then succeeds.
DE62 3704 0044 0532 0130 01
The PaymentIntent goes from processing to requires_payment_method.
DE78 3704 0044 0532 0130 04
Stays processing for at least three minutes, then fails.
DE35 3704 0044 0532 0130 02
The payment succeeds and a dispute is created immediately.
DE65 3704 0044 0002 2222 27
Fails with insufficient_funds.
DE84 3704 0044 0000 4545 45
Fails with debit_not_authorized and the mandate becomes inactive.
DE65 3704 0044 0000 3434 34
Fails with charge_exceeds_source_limit.
DE27 3704 0044 0000 1212 12
Fails with charge_exceeds_weekly_limit.
DE18 3704 0044 0000 0666 66
Fails with bank_account_unusable.
Source: Stripe docs, Testing. Test values change occasionally; the provider’s page is authoritative.
Testing subscriptions with test clocks
Test cards prove the first payment works. Renewals, trials ending and failed renewals happen weeks later, and a test clock lets you get there in seconds: you freeze a clock at a point in time, attach customers to it, and move it forward. Stripe then creates the invoices, attempts the payments and sends the webhooks it would have sent on those dates.
1. Create a clock frozen at a start date (here 1 January 2026):
curl https://api.stripe.com/v1/test_helpers/test_clocks \
-u "sk_test_...:" \
-d frozen_time=1767225600 \
-d "name=Monthly renewal"2. Create a customer on the clock with a test payment method, then a subscription for that customer as usual. The subscription belongs to the clock through the customer.
curl https://api.stripe.com/v1/customers \
-u "sk_test_...:" \
-d test_clock=clock_... \
-d payment_method=pm_card_visa \
-d "invoice_settings[default_payment_method]=pm_card_visa"3. Advance the clock to the renewal date (1 February 2026). The renewal invoice is created as a draft; advance one more hour and it is finalized and paid.
curl https://api.stripe.com/v1/test_helpers/test_clocks/clock_.../advance \
-u "sk_test_...:" \
-d frozen_time=1769904000Test clock limits worth knowing
- Up to three customers per clock, and up to three subscriptions per customer.
- A clock moves forward only, at most two billing intervals at a time (two months for a monthly price). Without subscriptions it can jump up to two years.
- Advancing takes a few seconds. Wait for the
test_helpers.test_clock.readyevent, or poll the clock until its status isready. customer.subscription.trial_will_endfires three days before a trial ends, so advance past that point to test your reminder emails.- Bank debits such as
us_bank_accountare collected only after the clock finishes advancing, not during it, so test failed bank renewals by watchinginvoice.payment_failedafterwards. - Clocks are deleted automatically after 30 days. Deleting one deletes its customers and cancels their subscriptions.
Source: Stripe docs, Test clocks.
How to use Stripe test cards
Stripe provides test card numbers that simulate real payment scenarios in test mode. These cards only work when your Stripe integration is running with test API keys (prefixed with sk_test_). No real charges are made and no real money is moved.
To use a test card, enter the card number in a Stripe-powered checkout form. Use any future expiration date (e.g., 12/34), any 3-digit CVC (4 digits for Amex), and any 5-digit ZIP code. The card will behave according to its designated scenario.
Testing Best Practices
- Test the happy path first. Use 4242 4242 4242 4242 to confirm your checkout flow works end-to-end before testing error scenarios.
- Test every error your users might encounter. Declined cards, insufficient funds, and expired cards are the most common failure modes.
- Verify 3D Secure handling. If you accept international payments, Strong Customer Authentication (SCA) is mandatory in the EU. Test both successful and failed authentication flows.
- Test dispute flows. Use dispute-triggering cards to ensure your system handles chargebacks gracefully and sends appropriate notifications.
- Test international cards. Different countries may trigger different Stripe behaviors, including currency conversion and regional card network routing.
- Test renewals, not just the first payment. Use a test clock (above) to reach the next billing date and watch the invoice and webhooks a renewal produces.
Testing Affiliate Payments with Stripe
When building an affiliate program that integrates with Stripe, you need to test the full conversion flow: click tracking, checkout, webhook processing, and commission attribution. Use the successful payment cards above to simulate real purchases in test mode, then verify that commissions are correctly calculated and attributed to the referring affiliate.
Refgrow integrates directly with Stripe webhooks to automatically track conversions, calculate commissions, and manage payouts. Test your entire affiliate pipeline with these cards before going live.
Check affiliate attribution before you go live
Refgrow has a dry-run test mode for Stripe. Forward your test-mode events with stripe listen, open your site with ?ref=CODE, pay with 4242 4242 4242 4242, and Refgrow reports which affiliate the sale would be credited to, and why, without creating a conversion, a commission or an email. How to run a dry run.
Test cards for other providers
Building a Stripe-powered affiliate program?
Refgrow connects to your Stripe account and automatically tracks affiliate conversions, commissions, and payouts.