A test card number is a non-functional card number published by a payment processor for use in its sandbox, so developers can simulate payments without touching real money. It passes format checks, including the card brand prefix and the Luhn checksum, but it is not tied to any cardholder account. No funds move, no authorization settles, and no real card data needs to enter the test environment.
What Is a Test Card Number Used For?
Developers use test card numbers to exercise a checkout flow before a site goes live. The numbers confirm that the payment form accepts a valid card, that the server handles the processor response, and that the order record updates correctly after a charge is approved or rejected. Testing also covers the failure paths that are hard to trigger with a real card.
Test numbers are especially useful in automated test suites. A QA pipeline can create a charge, assert the response code, and roll the sandbox forward without waiting on a bank.
Where Do Test Card Numbers Come From?
Each processor publishes its own list, and those numbers only work inside that processor's sandbox. Stripe, PayPal, Adyen, Braintree, and Authorize.net all maintain separate documentation with their own number ranges. A Stripe test number will not authenticate against a PayPal sandbox, so match the number to the gateway you are actually integrating.
Because the lists are versioned documentation, treat them as a moving target. Check the current reference page before you copy a number into a test fixture.
Which Test Card Numbers Should You Start With?
Most teams begin with the primary success card for each brand, then add one decline card. Stripe's documented set is a common starting point and is widely mirrored in tutorials.
- Visa success: 4242 4242 4242 4242
- Mastercard success: 5555 5555 5555 4444
- Generic decline: 4000 0000 0000 0002
- Insufficient funds decline: 4000 0000 0000 9995
Use any future expiry date and any three digit security code. Sandbox environments do not validate the CVV against an issuer.
Do Test Card Numbers Pass the Luhn Check?
Yes. Every published test number is built to satisfy the Luhn algorithm, the mod-10 checksum defined in ISO/IEC 7812 that catches single-digit typos and transpositions. That is why a test number behaves like a real card during client-side validation but is rejected the moment it reaches a live authorization endpoint.
If you are generating your own test values, run them through a Luhn calculator first. A number that fails the checksum will be blocked by your own form before the request ever leaves the browser.
How Do You Test Declines and Failed Payments?
Processors publish dedicated decline numbers that always return a specific error, which lets you verify your error handling without asking a bank to reject a charge. Typical scenarios include a generic decline, insufficient funds, an expired card, and an incorrect security code. Map each one to a user-facing message and confirm the customer sees something actionable rather than a raw gateway code.
How Do You Test 3D Secure?
Some test numbers force an authentication challenge so you can walk through the redirect and the challenge flow. Stripe documents 4000 0000 0000 3220 as a card that requires authentication, and similar values exist for challenge failures and unsupported brands. Verify both the success return and the abandoned challenge, since the second path is where orders commonly get stranded.
Are Test Card Numbers Safe to Use?
Yes, as long as they stay in the sandbox. Test numbers carry no value to an attacker and cannot be used to obtain goods, which is why processors publish them openly. The real risk runs the other way: pasting a live card number into a test environment, or shipping test numbers into production configuration.
Keep three rules. Never enter a real card into a sandbox, never point sandbox keys at a live endpoint, and never commit a real card number to a repository, even in a comment.
What Are the Most Common Testing Mistakes?
- Mixing live API keys with sandbox numbers, which produces confusing errors and can create real charges.
- Hardcoding a single success number and never testing declines, refunds, or partial captures.
- Assuming a CVV of 123 is required, when the sandbox accepts any three digits.
- Skipping the 3D Secure challenge path, which hides redirect bugs until launch.
Build a small fixture file with one number per scenario, and your payment tests will stay readable as the integration grows.