Sandbox cards vs. generated numbers
There are two kinds of test number, and they're for different jobs. Payment processors publish sandbox cards that behave in a defined way in test mode: Stripe's 4242 4242 4242 4242 always succeeds, 4000 0000 0000 0002 is always declined, and 4000 0025 0000 3155 always asks for 3-D Secure. Use these to test the whole payment flow, including webhooks and error messages. They only work with test-mode API keys.
Generated numbers have a valid network prefix, the right length and a correct check digit, but no processor recognises them. They're for testing the parts of a form that run before payment: input masks, card-brand icons, length limits and Luhn validation.
How the Luhn check works
The last digit of every card number is a check digit calculated with the Luhn algorithm, which catches most typing mistakes before a payment is attempted. Starting from the right, double every second digit, subtract 9 from any result over 9, then add everything up. If the total ends in 0, the number is well-formed.
Passing the Luhn check means only that a number is shaped correctly. It says nothing about whether an account exists — which is why a Luhn-valid test number is safe to use and useless for buying anything.
How card numbers are structured
The first digits identify the network, and the length depends on it:
- Visa — starts with 4, 16 digits, 3-digit CVC.
- Mastercard — starts with 51–55 or 2221–2720, 16 digits, 3-digit CVC.
- American Express — starts with 34 or 37, 15 digits, 4-digit CVC.
- Discover — starts with 6011 or 65, 16 digits, 3-digit CVC.
Testing payment forms safely
Never use a real card in development or staging. Real card data in logs, databases or screenshots brings that system into PCI DSS scope and creates a breach risk. Test cards let you exercise every code path without any of that. Before launch, run one small real transaction in live mode to confirm production keys are configured — that's the only time a real card should be involved.