Test card numbers are fake credit card numbers that payment processors use to check whether a transaction system is working correctly, without charging real money or risking real accounts.
When you're building a website, mobile app, or any system that takes payments, you need to test it before customers use it. Real payment cards can't be used for testing — you'd either charge actual money or trigger fraud alerts. Instead, payment processors like Stripe, Square, PayPal, and others provide test card numbers that work only in their test environments. These numbers follow the same format as real cards (they pass the Luhn algorithm check that validates card numbers), but they're connected to fake accounts that never actually process money.
Test cards let developers and business owners verify that their payment flow works: that forms accept input correctly, that transactions route to the right place, that receipts generate, and that error messages appear when something goes wrong. They're essential for catching bugs before launch, and they're free to use as many times as you want.
Key Takeaways
- Test card numbers are provided by payment processors and only work in test mode, never charging real money or affecting real accounts.
- Different test numbers trigger different outcomes — some simulate successful charges, others simulate declined cards or specific error conditions.
- Each payment processor (Stripe, Square, PayPal, etc.) has its own set of test numbers; a Stripe test card won't work in Square's test environment.
- Test cards are only for development and testing; they must never be used in a live payment system or with real customer data.
- You access test cards through your payment processor's developer dashboard, usually under a "Testing" or "Sandbox" section.
How test cards differ from real payment cards
A real credit card is connected to a bank account and a person's identity. When you charge it, money moves. A test card number is a string of digits that looks like a real card but exists only in the payment processor's test system. It has no bank behind it, no cardholder, and no real money attached.
Test cards work only when your system is set to test mode (also called sandbox mode). The moment you switch to live mode, test cards stop working — they'll be declined. This is intentional. It prevents accidental test charges from reaching customers or real bank accounts. Real cards, by contrast, work only in live mode and will be declined in test mode.
Test cards also come with preset outcomes. A processor might provide one test number that always succeeds, another that always fails, and others that simulate specific problems like expired cards, insufficient funds, or fraud blocks. This lets you test how your system handles both happy paths and errors without guessing or waiting for random failures.
Common test card numbers and what they simulate
Payment processors publish their test card numbers in their developer documentation. Here are examples of the types you'll typically find, though the actual numbers vary by processor:
| Card Type | Typical Outcome | Use Case |
|---|---|---|
| Visa test card | Transaction succeeds | Testing a successful purchase flow |
| Mastercard test card | Transaction succeeds | Testing that your system accepts multiple card brands |
| Declined card | Transaction fails | Testing error messages and retry logic |
| Expired card | Transaction fails with expiration error | Testing how your system handles expired cards |
| Insufficient funds card | Transaction fails with insufficient funds error | Testing customer communication when a charge bounces |
| 3D Secure card | Requires additional authentication | Testing two-factor payment flows |
You'll use different test cards depending on what you're testing. If you're building a checkout page, you might run through it with the success card first to make sure the happy path works. Then you'd test with the declined card to verify that your error page appears and your customer support team gets notified. Then you'd test with the expired card to make sure that specific error message is clear.
Where to find test card numbers for your payment processor
Every major payment processor publishes test card numbers in their developer documentation. Log into your account, look for a "Developers" or "API" section, and find the page labeled "Testing" or "Sandbox". Stripe calls it the "Testing" page. Square calls it "Sandbox". PayPal has a "Sandbox" environment. The location varies, but all of them make it public and free.
You don't need to request test cards or wait for approval — they're always available to anyone with a developer account. If you're building a system for a client or employer, ask them for access to their payment processor account, or create your own test account with the processor to learn how it works before handing off to them.
Test card numbers are also sometimes included in code libraries and SDKs (software development kits) that payment processors provide. If you're using Stripe's JavaScript library or Square's mobile SDK, the documentation for that library will list the test cards you can use with it.
How to use test cards safely in your development environment
Before you use a test card, make sure your system is in test mode. This is usually a setting in your payment processor's configuration — a toggle or an environment variable that tells your code to use the test API endpoint instead of the live one. If you're unsure whether you're in test mode, check your payment processor's dashboard. It will clearly label whether you're viewing test or live data.
Never mix test and live modes. Don't use test cards in a live environment, and don't use real cards in a test environment. The first creates confusion about what actually charged; the second risks charging real customers by accident. Keep them completely separate.
When you're ready to go live, switch your system to live mode and use real payment cards from your team members or trusted testers. At that point, test cards will stop working — which is the point. If a test card somehow gets used in production, it will be declined, alerting you that something went wrong with your deployment.
Why test cards matter before launch
Launching a payment system without testing is how businesses end up with charges that don't process, receipts that don't send, or customers who can't complete purchases. Test cards let you catch these problems in a safe environment where no real money is at stake and no customer is affected.
Testing also builds confidence. When you've run through your checkout flow 20 times with different test cards and seen it work every time, you know the system is ready. When you've tested what happens if a card is declined and verified that your customer sees a clear message and a way to retry, you know your error handling works. This confidence matters when you're about to accept real payments.
Test cards are also useful after launch. If a customer reports a payment problem, you can often reproduce it in test mode using a test card that simulates the same error condition. This helps you diagnose whether the problem is with your code, your payment processor, or the customer's card.
Frequently Asked Questions
Can I use test card numbers with a real payment processor account?
Yes. Test cards work with your real account, but only when you're in test mode. Your real account has two separate environments: test and live. Test mode uses test cards and doesn't charge anything. Live mode uses real cards and processes real money. You can switch between them in your account settings.
What happens if I accidentally use a test card in live mode?
The transaction will be declined. Test cards don't work in live mode, so the customer will see an error message. This is a safety feature — it prevents test data from mixing with real transactions. If this happens, check your deployment to make sure you switched to live mode correctly.
Do I need different test cards for different payment processors?
Yes. Stripe's test cards won't work in Square's test environment, and vice versa. Each processor has its own test system and its own set of test card numbers. If you're using multiple processors, you'll need to use the correct test cards for each one.
Can customers see test card numbers if I leave them in my code?
Test card numbers are public — they're published in documentation — so there's no security risk if they appear in code. However, it's still bad practice to hardcode them. Use your payment processor's test mode configuration instead, so test cards are never part of your actual code.
How often do test card numbers change?
Payment processors rarely change their test card numbers because developers rely on them for testing. If a processor does change them, they announce it well in advance and provide migration guidance. You can assume the test cards you find in documentation today will still work next year.