A card test number is a fake card number that a payment processor publishes so developers can run payments in a sandbox without moving real money. Each number is built to return one set result: an approval, a decline, or a 3-D Secure challenge. That lets you check a checkout flow end to end before a real card is involved.
How do card test numbers work?
Test numbers live inside a processor's sandbox, a copy of the payment API that talks to no bank. The processor maps each published number to a scripted outcome, so the same request returns the same response every time. Your code sees realistic responses, webhooks, and error codes.
Most test numbers pass the Luhn checksum. That matters because your form validation and your server-side checks then run on the same code path they will use in production.
What a test number can trigger
- Approved payments with a capture and settlement step.
- Soft declines, such as insufficient funds, that allow a retry.
- Hard declines, such as a closed or stolen card.
- CVV and postal code mismatches.
- 3-D Secure challenges, both passed and failed.
- Refunds, partial refunds, and chargebacks in some sandboxes.
Where do you get official card test numbers?
Use the documentation for the gateway you actually integrate. Numbers from one processor often do nothing on another, because the sandbox behavior is tied to that processor's own routing table.
- Your processor's test card page. Stripe, Adyen, Braintree, and Authorize.net each publish a list of numbers with the outcome tied to each one.
- Your sandbox dashboard. Some gateways show test numbers inside the merchant panel, next to the API keys for that environment.
- Your acquirer's integration guide. Bank-side sandboxes often ship a PDF or portal page with their own set.
- Your own fixtures file. Once you have one number per outcome, store them in code so every developer on the team tests the same cases.
Skip numbers from random generators and forum posts. A generator can produce a Luhn-valid string, but it cannot tell you what the sandbox will do with it, so it tests nothing beyond your format check.
Test card number vs. real card number
The two look alike in format and share nothing else. Confusing them wastes hours and, on a live gateway, can cause real problems.
- Money. A test number moves none. A real number moves funds and creates a settlement record.
- Scope. A test number works only in the sandbox that published it. Live keys reject it at authorization.
- Data rules. PCI DSS forbids using production card data in test systems. Test numbers keep you clear of that requirement.
- Lifespan. Test numbers do not expire the way real cards do, even when the docs list a sample expiry date next to them.
Test numbers exist to exercise software. They are not a way to check whether a card from another source works, and no legitimate processor offers that service.
What should a test set cover before launch?
One approval is not a test plan. Run at least these cases:
- One approved payment per card network you accept.
- Two decline types: one soft, one hard.
- A CVV mismatch and an address mismatch.
- A 3-D Secure challenge that passes and one that fails.
- A full refund and a partial refund against an earlier test charge.
- Zero-decimal and three-decimal currencies if you sell outside the US.
- Webhook delivery, retries, and duplicate event handling.
Questions people ask about card test numbers
Are card test numbers real cards?
No. They are reserved number strings that route to a sandbox account, not to any cardholder. No bank ever sees the request.
Can a test number tell me if a real card is valid?
No. A test number has no link to a real account, and a live gateway rejects it. Checking a real card means running an authorization for a small amount, which needs the cardholder's consent and a merchant account.
Do test numbers expire?
Some do in practice and some do not, and the rule differs by processor. Use the expiry date listed in the docs next to the number, and recheck the page when your tests start failing for no clear reason.
Can I use a test number on a live site?
No. It fails authorization, and repeated attempts can flag the merchant account for fraud review. Keep sandbox keys and live keys in separate config files so the mistake cannot happen.
Checklist before you swap sandbox keys for live keys
- Every test case above passes in the sandbox.
- Decline messages map to readable text in your UI.
- Failed payments do not create an order in your database.
- Webhook signatures are verified, not trusted by default.
- Logs mask the card number and CVV fields.
- Live keys are stored in the secret manager, not in the repo.