What test card numbers are and why they exist

Test card numbers are fake credit and debit card numbers that payment processors and banks provide so developers can test payment systems without charging real money. They work only in sandbox environments — the testing versions of payment platforms — and will always be declined in live, real-money transactions.

When you build a website, mobile app, or payment feature, you need to check that the payment flow works before you launch it to actual customers. Test cards let you do that safely. You can test successful payments, failed payments, different card types, and error scenarios without touching anyone's real bank account.

The major payment processors — Stripe, PayPal, Square, and others — each publish their own set of test card numbers. These numbers follow the same format rules as real cards (they pass the Luhn algorithm check, which validates card number structure), but they're flagged in the processor's system as test-only.

Key Takeaways

  • Test card numbers work only in sandbox mode and will always fail in live payment processing, so they cannot accidentally charge real customers.
  • Each payment processor publishes its own test card numbers, and you must use the ones matching the processor your app is connected to.
  • Different test card numbers trigger different outcomes — some simulate successful charges, others simulate declines, and some trigger specific error codes.
  • Test cards require a future expiration date and any three-digit security code to work in most sandbox environments.

Where to find test card numbers for your payment processor

Your payment processor's developer documentation is the only reliable source. Stripe publishes test cards in its testing guide; PayPal lists them in its sandbox documentation; Square includes them in its developer resources. Do not use test card numbers from random websites or forums — they may be outdated or incorrect.

To find them: log into your developer account with the processor you're using, navigate to the documentation or developer section, and search for "test cards" or "testing." The page will show you a table of test card numbers, each paired with the outcome it produces. Bookmark this page — you'll reference it often during development.

If you're building an integration with a payment processor you haven't used before, start by reading their testing documentation before you write any code. This saves time because you'll know exactly which test cards to use and what results to expect.

How test card numbers work in sandbox mode

When your app is in sandbox mode, it connects to the processor's test environment instead of the live payment network. Any card number you submit — real or test — is intercepted before it reaches the banking system. The processor checks whether the number is on its test list, and if it is, it simulates the transaction outcome instead of processing it.

This means a test card number will never charge a real bank account, even if you accidentally use a real expiration date or security code. The transaction stops at the processor's test server. Once you switch your app to live mode and use real card numbers, the processor routes transactions to the actual payment network, and real money moves.

The boundary between sandbox and live is strict and intentional. You cannot use test card numbers in live mode — they will always be declined. You also cannot use real card numbers in sandbox mode for testing (and you shouldn't, because it's unnecessary risk). Keep your sandbox credentials and live credentials completely separate in your code.

Common test card numbers and what they simulate

Most processors provide test cards that fall into a few categories. A successful charge card simulates a normal, approved transaction — use this to test that your app correctly handles a payment going through. A decline card simulates a card that the bank rejected — use this to test your error handling and the messages you show users when a payment fails.

Some processors also offer test cards that trigger specific decline reasons: insufficient funds, lost card, stolen card, expired card, or incorrect security code. These let you test whether your app handles different failure types correctly and shows the right message to the user in each case.

A few processors provide test cards for 3D find (an extra authentication step) or for testing recurring charges. Check your processor's documentation to see the full list. The exact numbers vary by processor, so a Stripe test card will not work with PayPal, and vice versa.

What expiration date and security code to use with test cards

Test cards accept any expiration date in the future and any three-digit security code (or four digits for American Express). You do not need to match a real card's details. Most developers use a straightforward date like 12/25 or 12/99 and a security code like 123 or 000 — whatever is easiest to remember and type.

The processor's test environment does not validate these details the way a live system does. It only checks that the card number itself is on the test list. So you could submit a test card with an expiration date in 1999 and it would still work in sandbox mode. This flexibility is intentional — it lets you focus on testing the payment flow, not on finding realistic dates.

In live mode, by contrast, the processor validates the expiration date and security code against the real card network. An expired card or incorrect code will be declined. This is why testing in sandbox with realistic details is a good habit — it trains you to handle the validation that will happen in production.

Testing different payment scenarios with test cards

A complete test should cover at least three scenarios: a successful payment, a declined payment, and an error. Use your processor's success test card to verify that your app correctly records the transaction, shows a confirmation message, and updates the user's account. Use the decline test card to verify that your app shows an error message and does not record a false transaction.

For the error scenario, some processors provide test cards that trigger specific error codes — for example, a card that simulates a network timeout or a processor error. These let you test how your app behaves when something goes wrong on the processor's side, not just when the customer's card is declined.

Write down the test cases you plan to run before you start. A straightforward checklist might look like: successful charge, card declined, insufficient funds, expired card, incorrect security code, and network error. Run through each one and confirm your app handles it correctly. This takes an hour or two but catches most payment bugs before they reach customers.

Moving from sandbox testing to live payments

Once you've tested all your scenarios and your app is ready, you'll switch from sandbox credentials to live credentials. This is usually a configuration change — you update an environment variable or a settings file to point to the live API endpoint instead of the sandbox endpoint, and you use your live API keys instead of your test keys.

Before you make this switch, do a final check: verify that you've removed any test card numbers from your code, that your error messages are user-friendly, and that you're not logging sensitive payment details. Some developers leave a test card number in a comment or a default value by accident, which can cause confusion later.

After you go live, you can still use sandbox mode for testing new features. Keep your sandbox and live environments separate. Many developers maintain both — they test new payment flows in sandbox, then deploy the code to production once it's working. This is the safest approach.

Frequently Asked Questions

Can test card numbers be used to make real purchases?

No. Test card numbers work only in sandbox mode and will always be declined in live transactions. They are flagged in the processor's system as test-only, so even if you somehow submitted one to a live payment gateway, it would fail. You cannot accidentally charge a customer with a test card.

What happens if I use a real card number in sandbox mode?

The transaction will be declined because real card numbers are not on the processor's test list. More importantly, you should never do this — there is no reason to submit real card details to a test environment, and it creates unnecessary security risk. Always use test cards for sandbox testing.

Do I need different test cards for different payment methods?

Yes. Most processors provide separate test card numbers for Visa, Mastercard, American Express, and Discover. Some also provide test numbers for digital wallets like Apple Pay or Google Pay. Check your processor's documentation to find the test cards for each method you plan to support.

Can I use the same test card number across different processors?

No. Each processor has its own test card numbers. A Stripe test card will not work with PayPal, and a Square test card will not work with Stripe. You must use the test cards published by the specific processor your app is integrated with.

What should I do if a test card number stops working?

Check your processor's documentation to confirm the number is still listed and that you're using the correct expiration date and security code. If the number is correct but still fails, verify that you're in sandbox mode and not live mode. If you're definitely in sandbox and the test card still does not work, contact your processor's support team — test card numbers rarely change, but it can happen during system updates.