A test card number is a fake card number published by a payment processor for use in its sandbox environment. It passes the same format checks as a real card, but it links to no bank account and moves no money. Developers use these numbers to test checkout pages, decline handling, and refunds without touching live card data.
What Is a Test Card Number?
Processors such as Stripe, Adyen, PayPal, and Square publish test numbers in their developer docs. Each value is reserved for sandbox traffic and returns a scripted result: approval, decline, or a specific error code.
Test numbers look like real cards on purpose. They carry a valid issuer prefix, the correct digit count, and a passing Luhn checksum, so a payment form accepts them.
Where test cards sit in a payment flow
A checkout sends the number, expiry, CVC, and postal code to the gateway. In test mode the gateway reads the number, matches it against a table of scripted responses, and returns that response to your app.
Nothing leaves the sandbox. No issuer is contacted, no authorization is requested, and no settlement happens.
How Does a Test Card Number Pass Validation?
Every card number holds three parts: an issuer prefix, an account digit block, and a final check digit. The check digit comes from the Luhn algorithm, a weight-sum formula that catches mistyped digits.
The Luhn check in plain terms
Double every second digit from the right, subtract 9 from any result above 9, then add the digits. If the total divides by 10, the number is Luhn-valid.
Test numbers are built to pass. That is why a form validator with a Luhn rule accepts 4242 4242 4242 4242 and rejects a random string of 16 digits.
Prefixes and lengths
- Visa starts with 4 and runs 16 digits.
- Mastercard uses 51 to 55 and 2221 to 2720, also 16 digits.
- American Express uses 34 or 37 with 15 digits.
- Discover uses 6011, 65, or 644 to 649 with 16 digits.
Sandbox docs match these rules so your form logic, masking, and spacing behave the same way in test and live modes.
Which Test Card Numbers Do Processors Publish?
- Stripe: 4242 4242 4242 4242, a Visa that approves.
- Stripe: 4000 0000 0000 0002, a Visa that returns a generic decline.
- Adyen and Braintree sandboxes: 4111 1111 1111 1111, a Visa that approves.
- Square sandbox: 4111 1111 1111 1111 for approvals and a separate set for declines.
These values appear across the industry because they contain no real account data. Processors do retire and add numbers, so confirm the current list before you hard-code one into a test suite.
How Do You Test Declines, Errors, and 3D Secure?
Sandboxes map specific numbers to specific responses, which lets you script edge cases without a real customer.
- Generic decline: the gateway reports "card declined" with little detail.
- Insufficient funds: a soft decline your app can offer to retry.
- Expired card: tests your date picker and your error copy.
- Incorrect CVC: checks that your form flags the security code field.
- 3D Secure challenge: forces an authentication step before capture.
Log the raw response code for each case. That habit catches broken error handling before launch.
What Other Fields Does a Test Card Need?
The number alone rarely completes a test transaction. Gateways also read the expiry, the CVC, the postal code, and the cardholder name.
- Expiry: any future date works in most sandboxes.
- CVC: three digits for most brands, four for American Express.
- Postal code: some sandboxes use a set value to trigger an address mismatch.
- Name: usually ignored, though a few test scenarios check it against a rule.
How Do You Build a Test Card Workflow?
- Pick one approval card and one decline card per brand you support.
- Store those values in a test fixture, not in production code.
- Run the approval path, then the decline path, then the 3D Secure path.
- Check that your app stores no card data during any of those runs.
- Re-verify the numbers against provider docs each quarter.
A short script that loops through these cases takes an afternoon to write and saves weeks of debugging later.
Why You Should Never Test With a Real Card Number
Live card data pulls your test systems into PCI DSS scope, which adds storage rules, audits, and cost. A single real number sitting in a test database can turn a minor leak into a reportable breach.
- Test data stays out of PCI scope.
- No customer money is at risk.
- No chargebacks or disputes land on a real account.
Test Cards vs. Number Generators vs. Leaked Card Data
Generators produce numbers that pass Luhn but link to nothing. They work for form validation drills and fail against a live gateway, because no issuer will authorize them.
Lists traded as "valid cards" are something else. Those values often come from breaches or carding forums, and using one to obtain goods or services is fraud.
If a number belongs to a real account, you have no lawful reason to type it into a form. Stay with sandbox values from official documentation.
Frequently Asked Questions
Do test card numbers work on live payment pages?
No. Live gateways route to issuer networks, and a test number returns a decline there. They work only when the site runs in test or sandbox mode.
What CVV should you use with a test card number?
Any three digits for Visa, Mastercard, and Discover, and four digits for American Express. Some sandboxes use a set CVC value to trigger a mismatch error on purpose.
Do test card numbers expire?
Most sandboxes accept any future date. Others publish a fixed expiry in their docs, so check the reference page for your provider.
Are test card numbers legal?
Yes, when you use them in a sandbox you control. The values authorize no payment and belong to no cardholder.
Can a test card number buy anything?
No. A sandbox returns a fake approval and nothing ships or settles. Attempting the same number on a live store ends in a decline.