What a card number validator actually does

A card number validator answers one narrow question: could this string of digits be a payment card number? It runs a checksum, checks the length, and compares the leading digits against the issuer ranges that ISO/IEC 7812 assigns to banks. That is the whole job. A pass means the number is well formed. It says nothing about whether the account exists, whether it is open, or whether a charge would go through.

People mix up formatting with authorization constantly. Those are different problems handled by different systems, and only one of them involves the issuer.

The Luhn check

Most validators start with the Luhn algorithm, also called mod 10. Start at the rightmost digit and move left, doubling every second digit. If doubling pushes a value above 9, subtract 9. Add up everything. If the total divides evenly by 10, the check passes.

A single mistyped or transposed digit usually breaks that sum, which is why the check catches most data entry errors. Not all of them. Some mistakes still produce a valid checksum, roughly one in ten.

Length and issuer ranges

• Major card brands run 13 to 19 digits, with 16 the most common.
• The first digit hints at the network: 4 for Visa, 5 and 2 for Mastercard, 3 for Amex, Discover, and JCB.
• ISO/IEC 7812 defines the issuer identification number as the first eight digits, expanded from six in 2017 to keep pace with demand.

A validator will accept 4111 1111 1111 1111, the Visa test number published by processors for sandbox work, and reject most random 16 digit strings. That test number has never been tied to a real account.

What a validator cannot tell you

No checksum confirms an account is open, funded, or authorized. Only the issuer can do that, through an authorization request over the card networks. A validator also ignores the security code, which is generated separately and never derived from the card number, plus the expiration date and the cardholder name.

Tools claiming to tell you whether a card is "live" are describing something else, and that something else is a test authorization against someone's account. Attempting it on a card you do not own is fraud in every U.S. state and most countries besides. There is no gray area there, and no legitimate use case dressed up as one.

Where validators show up in real systems

Checkout forms validate on the client for quick feedback and on the server for trust. Client side checks can be bypassed, so the server repeats the Luhn check before anything else happens. Solid payment flows then hand the number to a tokenization service, so raw digits never sit in a merchant database and stay out of PCI DSS scope.

If you are building a form, treat the validator as a first filter. Reject malformed input early, then let the processor tell you what actually happened.