Test credit card numbers are fake card numbers that payment processors and developers use to check whether their systems work without risking real money
A test credit card number is a sequence of digits that follows the same format rules as a real card number but connects to a test environment instead of a live bank account. When you enter a test number into a sandbox or testing system, the payment processor routes it to a fake payment gateway that simulates what would happen in production—it approves or declines the transaction, generates a confirmation number, and records the event—but no actual charge occurs and no real account is touched.
Test numbers exist because building a payment system requires hundreds of small checks: Does the form reject cards that are too short? Does the system store the confirmation number? Does the receipt email send? Does the decline message appear when it should? Running these checks against real card numbers would charge real people real money for every test, which is wasteful and unethical. Test numbers let developers and merchants verify their work in a controlled space.
Different payment processors provide different test numbers, and each one behaves differently—some always approve, some always decline, some simulate specific error conditions. Knowing which test number produces which outcome is essential for testing the full range of what your system needs to handle.
Key Takeaways
- Test credit card numbers are fake sequences designed to work only in sandbox environments, never against real bank accounts.
- Major payment processors like Stripe, PayPal, and Square each publish their own test numbers that behave differently to simulate various outcomes.
- A test number that always approves lets you verify the happy path; a test number that always declines lets you verify error handling.
- Test numbers follow real card number rules (like the Luhn algorithm) so they pass format validation, but they route to fake payment gateways instead of banks.
Where test numbers come from and who publishes them
Every major payment processor publishes a set of test card numbers in their developer documentation. Stripe publishes test numbers for Visa, Mastercard, American Express, and Discover. PayPal publishes test numbers for their sandbox environment. Square, Adyen, Authorize.net, and others do the same. These numbers are public—they are meant to be shared and used by anyone building on that platform.
The processor controls what happens when a test number is used. When you submit a test Visa number to Stripe's sandbox, Stripe's test gateway intercepts it and decides whether to approve or decline based on the specific number and the other details in the request. The transaction never reaches Visa's real network. This is why the same test number will work in Stripe's sandbox but will do nothing in PayPal's sandbox—they are separate test environments.
Test numbers are not secret. Publishing them widely is actually safer than keeping them hidden, because developers need to know what to test against, and there is no security risk—a test number cannot be used to charge anyone because it does not connect to a real account.
Common test card numbers and what they do
Most processors follow a pattern: one test number always approves, one always declines, and others simulate specific scenarios like expired cards or insufficient funds. Here is what you typically find in a processor's documentation:
| Scenario | What it tests | Why you need it |
|---|---|---|
| Always approves | A successful charge from start to finish | Verify the happy path: form submission, confirmation, receipt, database record |
| Always declines | A failed charge and error message | Verify that your system handles rejection gracefully and shows the right message to the customer |
| Expired card | A card with a past expiration date | Verify that your form or processor catches expired cards before sending them |
| Insufficient funds | A decline due to low balance | Verify that your error message distinguishes between "card declined" and "insufficient funds" |
| Incorrect CVC | A mismatch between card number and security code | Verify that your system rejects mismatched security codes |
The exact test numbers vary by processor. Stripe's always-approve Visa is 4242 4242 4242 4242. PayPal's test numbers are different. Square's are different again. This is why you must check your processor's documentation—using a Stripe test number in a PayPal sandbox will not work the way you expect.
How test numbers follow real card number rules
Test numbers are not random strings. They follow the Luhn algorithm, the same checksum rule that real card numbers follow. This means a test number will pass basic format validation—your form will accept it as a valid card number shape—even though it is not connected to a real account.
The Luhn algorithm works by multiplying every other digit by two, summing the results, and checking that the total is divisible by ten. Real card processors use this check to catch typos before sending a request to the bank. Test numbers are designed to pass this check so that developers can test their validation logic without having to disable it.
This is important: a test number passing the Luhn check does not mean it is real. It just means it looks real enough to get past the first layer of validation. The actual approval or decline happens in the test gateway, which knows the difference between test numbers and real ones.
Why you should never use real card numbers for testing
Using a real credit card number to test a payment system is a serious mistake. Every test transaction is a real charge. If you run fifty tests, you charge the cardholder fifty times. You expose the card number to your test environment, your logs, your database backups, and anyone with access to your code. You create a compliance nightmare because you are storing real card data in a place it should never be.
Test numbers exist specifically to avoid this. They are free, they are safe, and they are designed for exactly this purpose. Using them is not just best practice—it is the only responsible way to build and test a payment system.
If you are a merchant testing your own payment setup, use your processor's test numbers. If you are a developer building a payment feature, use the test numbers for the processor you are integrating with. If you are reviewing someone else's code and you see real card numbers in a test file, that is a red flag that should be reported and fixed when ready.
How to find test numbers for your payment processor
Every payment processor publishes test card numbers in their developer documentation. The process is the same for all of them: log into your developer account, find the "Testing" or "Sandbox" section of the docs, and look for a page titled "Test Card Numbers" or "Test Data".
For Stripe, go to the Stripe Dashboard, click "Developers" in the top menu, then "Documentation", then search for "test card numbers". For PayPal, log into your developer account and navigate to the sandbox documentation. For Square, visit the Square Developer Dashboard and find the testing guide. For Authorize.net, American Express, Discover, and others, the pattern is the same: developer docs, testing section, test data page.
Bookmark the page for your processor. You will return to it often. Most processors also publish test numbers for specific card brands (Visa, Mastercard, Amex), specific decline reasons, and specific edge cases. Having the full list nearby saves time when you are debugging why a particular scenario is not working the way you expected.
What happens after you use a test number
When you submit a test card number in a sandbox environment, the payment processor logs the transaction in your test dashboard, just as it would log a real transaction in your production dashboard. You can see the charge, the timestamp, the amount, the status, and any error messages. This log is useful for debugging: if a charge did not go through the way you expected, you can look at the test log and see what the processor returned.
Test transactions do not appear on anyone's real credit card statement. They do not affect anyone's credit score. They do not create a real debt. They exist only in the test environment and disappear when you reset your sandbox or when the processor clears old test data.
Once you have verified your system works correctly with test numbers, you move to production. In production, you use real card numbers (entered by real customers), and the processor routes them to real banks. The flow is identical—form submission, validation, processor response, confirmation—but now real money moves and real records are created.
Frequently Asked Questions
Can I use a test card number in production?
No. Test numbers are rejected by production payment gateways. If a customer enters a test number on your live site, the processor will decline it. Test numbers only work in sandbox environments. This is a safety feature—it prevents accidental test transactions from charging real customers.
What if I enter a test number with the wrong expiration date?
It depends on the test number and the processor. Some test numbers are designed to decline when paired with an expired date; others will approve anyway because they are testing a different scenario. Check your processor's documentation to see which test numbers are meant to simulate expiration failures.
Do I need different test numbers for different payment methods?
Yes. Most processors publish separate test numbers for Visa, Mastercard, American Express, and Discover. Some also publish test numbers for digital wallets like Apple Pay or Google Pay. Use the test number that matches the payment method you are testing.
Can someone use a test card number to commit fraud?
No. Test numbers only work in sandbox environments, and they do not connect to real accounts. Even if someone knew all your test numbers, they could not use them to charge anyone or steal anything. Test numbers are safe to publish and share.
What should I do if I accidentally used a real card number in my test code?
Stop using that card when ready and contact the cardholder to report the exposure. Remove the card number from your code, your logs, and your database. Review your test environment to see what other real card data might be stored there. Report the incident to your payment processor—they may have additional steps you need to take for compliance.