Buy the integration, not the number list
Test card numbers are free. Every large payment processor publishes a set of sandbox card numbers with matching expiry dates and CVV values in its public developer documentation. If a vendor asks for money for a "test number" or a "valid CVV," you are not buying test data. Sandbox numbers are built to fail against live authorization endpoints, so any number that clears a real transaction is genuine account data. Buying, selling, or using that data is card fraud and is prosecutable under 18 U.S.C. § 1029. The buying decision that actually matters is the test environment around the numbers: which processor sandbox you use, which scenarios it can simulate, and whether your team can reproduce a failure on demand. Put the budget into a test account with broad scenario coverage and into compliance tooling. Number lists are worth nothing.
What a usable test set covers
- Every network you accept. Visa, Mastercard, American Express, and Discover differ on number length, CVV format, and address verification behavior.
- Approval and decline paths. A solid set includes numbers that trigger specific response codes: insufficient funds, expired card, incorrect CVV, do not honor, and processing error.
- Authentication flows. If you support 3-D Secure or network tokens, you need numbers that force a challenge and numbers that pass without one.
- Documented expiry and CVV pairs. Processors publish the exact values that pair with each number. Mixing pairs produces failures your team will misread as bugs.
- A stated sandbox guarantee. The source should say in plain terms that the numbers cannot authorize a live payment.
Parameter bands to check
Test numbers follow the same formatting rules as live cards, and your validation layer should accept the full legal range rather than one narrow example.
- Account number length: 13 to 19 digits. Reject anything shorter or longer before you call the gateway.
- Luhn check digit: mod-10 checksum. A number that fails Luhn is malformed input, not a decline, and the two should produce different error messages.
- CVV length: 3 digits for most networks, 4 digits for American Express. Never store the value after authorization.
- Expiry: published test numbers ship with fixed future dates. Your form should accept the standard MM/YY entry and reject past dates.
- Issuer prefixes: Visa begins with 4, Mastercard uses 51 through 55 and 2221 through 2720, American Express uses 34 and 37, Discover uses 6011 and 65.
- AVS and postal data: include at least one passing and one failing street or ZIP pair so address verification logic gets exercised.
Pitfalls that waste time or create liability
- Forum lists and "fresh" dumps. Numbers traded on carding boards are stolen or generated, not test data. Using them against a live endpoint is a federal offense and gets merchant accounts terminated.
- Storing the CVV. PCI DSS forbids retaining the verification value after authorization in any form, including logs and test fixtures copied from production.
- Testing in production. Point the test suite at a sandbox host and keep separate credentials. A misconfigured base URL is the most common cause of accidental live charges.
- Treating a Luhn pass as validity. The checksum only confirms the digits are well formed. Validity comes from the issuer response, which the sandbox simulates.
- Ignoring decline codes. Teams that test only the happy path ship checkout flows that break on the first soft decline.
FAQ
Are test card numbers real cards?
No. They are synthetic numbers reserved for sandbox use. They resolve to no account and cannot move money.
Can I use a test number to check whether a card is live?
No. That practice, sometimes called card checking, is a fraud technique. It also produces meaningless results, since sandbox numbers are rejected by live authorization systems.
Do test numbers expire?
Published sets usually carry a fixed future expiry. When processors refresh their documentation, the paired dates can change, so read the current page rather than a copied snippet.
Where should test numbers live in my codebase?
In fixtures or environment variables used only by the sandbox configuration. Keep them out of production config and out of any file that ships to a browser.
Will one processor's test numbers work with another?
Not reliably. Each gateway maps its own numbers to its own simulated responses, so use the set published by the processor you integrated.