A credit card test number is a dummy card number that payment processors publish for developers to use in sandbox mode. It passes the same format checks as a real card, but it runs against a test account, so no money moves and no bank ever sees the request.
Developers use these numbers to build checkout pages, force declines on purpose, and check refund logic without touching live card data. Stripe, PayPal, Adyen, Braintree, and Checkout.com all publish their own sets in their developer docs.
What does a credit card test number actually do?
A test number behaves like a real card inside a test environment and like nothing at all outside it. The processor maps each number to a scripted response, such as approved, declined, or expired card.
- It matches the length and prefix rules of the card brand it imitates.
- It passes the Luhn checksum, the math check every card number must survive.
- It routes to a sandbox endpoint tied to your test API keys.
- It returns a fixed result instead of contacting an issuing bank.
How a test number passes card validation
Before any authorization happens, a payment form checks the structure of the number. Test numbers are built to clear every one of those checks.
Length and prefix rules
- Visa: 16 digits, starts with 4.
- Mastercard: 16 digits, starts with 51 through 55 or 2221 through 2720.
- American Express: 15 digits, starts with 34 or 37.
- Discover: 16 digits, starts with 6011.
A number that breaks these rules gets rejected by the form before the processor ever sees it. That is why you cannot just type random digits into a checkout field and expect a test charge.
The Luhn checksum
The Luhn formula doubles every second digit from the right, sums the results, and checks whether the total divides by 10. Published test numbers are generated to satisfy that rule. If you invent your own digits, the form will flag the card as invalid.
Common test card numbers and what they trigger
The numbers below appear in public developer documentation. Each one maps to a specific outcome, which makes them useful for testing error handling as well as success.
- 4242 4242 4242 4242: Visa, succeeds.
- 4000 0000 0000 0002: Visa, generic decline.
- 4000 0000 0000 9995: Visa, insufficient funds.
- 5555 5555 5555 4444: Mastercard, succeeds.
- 3782 822463 10005: American Express, succeeds.
- 6011 1111 1111 1117: Discover, succeeds.
Use any future expiry date, such as 12/34. Most sandboxes accept any three or four digit CVC, but a few require an exact value, so check the docs for your processor.
How to test a payment flow step by step
- Create a sandbox or test account with your payment provider.
- Copy the test API keys into your staging environment. Never mix them with live keys.
- Open your checkout page and enter a success test number with a future expiry.
- Confirm the charge shows in the dashboard with a test label and no real settlement.
- Swap in a decline number and check that your error message matches the decline code.
- Test refunds, partial refunds, and any webhooks your app listens to.
- Run a 3D Secure flow if your processor supplies an authentication test card.
Where should you get test card numbers?
Pull them from the official docs of the processor you integrate with. Stripe, PayPal, Braintree, Adyen, Checkout.com, and Square each publish their own list, and the values change when processors update their test environments.
A copy-pasted list from an old blog post may be stale. When a test number stops returning the expected result, the docs are the first place to check.
Why you should not test with a real card number
Card data stays card data even in a test account. Under PCI DSS, storing or transmitting a real primary account number without a compliant environment is a violation, no matter what the account type is.
There is a second problem. Using a card number that belongs to someone else is card fraud, not testing, and processors close accounts over it. Keep real numbers out of your sandbox and stick to the published test values.
Frequently asked questions
Do test card numbers work on live websites?
No. A live payment gateway rejects them at the authorization stage because the number does not belong to a real account. A test number only works when your code points at a sandbox endpoint with test API keys.
Can a test card number be charged?
No. Test numbers route to a simulated environment. The dashboard may show a pending charge for realism, but no funds leave any account and no settlement occurs.
Are test card numbers the same at every processor?
They overlap in part. Numbers like 4242 4242 4242 4242 appear in several processors' docs, while decline and error codes differ from one provider to the next.
What expiry date and CVC should I use with a test card?
Use any date in the future and any three digit code for most card brands, or four digits for American Express. A handful of processors require a fixed CVC to trigger a specific response.
Is it legal to use test card numbers?
Yes, when you use them in your own sandbox account for development. The problem starts when someone enters a test or real number on a live checkout to obtain goods or services without paying.