A payment form has at least four validation layers: length, brand prefix, Luhn checksum and expiry. A number that fails at layer one never exercises the other three. Every number here passes all four, so your form has to reach the payment processor to reject it.
What you can control
- Correct brand prefixes and lengths — Amex is fifteen digits starting 34 or 37, Visa sixteen starting 4.
- Every number carries a valid Luhn check digit, confirmed in its own column.
- The expired-card option produces past expiry dates, which is the fastest way to test a decline path.
- Four display formats including a masked one, for testing how you show a stored card.
What this is not
These numbers satisfy the Luhn algorithm but are not issued by any bank and carry no funds. Any real payment processor will decline them. Attempting to use one for an actual purchase is fraud.
Questions
Will these work for a real purchase?
No. They pass client-side validation and are rejected the moment they reach a card network, because no issuer has them on file.
What is the Luhn algorithm?
A checksum that catches most single-digit typos and adjacent transpositions. Every card number in circulation satisfies it, which is why forms check it before making a network call.
Should I use these instead of my processor's test cards?
For front-end validation, these are fine and cover more brands. For end-to-end payment flows, use your processor's official test numbers — they trigger specific decline scenarios these cannot.