Card Number Validator: How Luhn Checks and BIN Ranges Work

A card number validator checks whether a string of digits is structurally valid as a payment card number. It confirms the length, the issuer prefix, and a checksum called the Luhn algorithm. It does not confirm that the card exists, is open, or has funds, because only the issuing bank can do that.

How does a card number validator work?

Most validators run three independent tests. The first is length: ISO/IEC 7812 allows primary account numbers (PANs) of 8 to 19 digits, though consumer cards are usually 13 to 19. The second is issuer identification, where the leading digits map to a network and issuer range. The third is a mod-10 checksum, so a single mistyped digit fails the check.

What is the Luhn algorithm?

Luhn, also called mod 10, is a checksum published in 1960 that catches most accidental typing errors. Working from the rightmost digit, double every second digit, subtract 9 from any result above 9, then add everything together. If the total divides evenly by 10, the number passes.

For example, 4111 1111 1111 1111 passes Luhn and is a widely used industry test number. Passing proves only that the digits are internally consistent, not that the account is real.

What do the parts of a card number mean?

• Issuer identification number (IIN/BIN): the first 6 to 8 digits, which identify the issuing institution and card product.
• Account number: the middle digits that identify the individual account.
• Check digit: the final digit, calculated with the Luhn formula.

What a validator cannot tell you

Validation is not authorization. A well-formed number can belong to a closed, blocked, or nonexistent account, and a declined transaction says nothing about whether the format was correct.

Validators also never touch the CVV, the expiry date, or the 3-D Secure step. Those are separate verification layers handled by the issuer and the payment network.

Why do merchants validate card numbers?

Checksum filtering catches typos before an authorization request is sent. That lowers decline rates, reduces support tickets, and avoids network fees on transactions that could never succeed.

Validation also feeds tokenization. Once a PAN is confirmed as well-formed, it can be replaced with a payment token so the real number is not stored in the merchant's systems.

What are the compliance limits?

PCI DSS treats the PAN as cardholder data and the CVV or CVC as sensitive authentication data. Sensitive authentication data must not be stored after authorization, and stored PANs must be masked or encrypted.

Building a validator that logs full card numbers creates a compliance problem. Mask to the first six and last four digits, or drop the number once it is tokenized.

Do test card numbers pass validation?

Yes. Published test numbers are designed to pass Luhn so developers can exercise checkout flows. They will never authorize, and any system that treats a Luhn pass as proof of a live account is misusing the check.

Frequently asked questions

Is a Luhn check enough to accept a payment?

No. Luhn is a data entry filter, and the authorization response from the issuer is the only real approval signal.

Can an issued card number fail Luhn?

No. Every issued PAN ends with a check digit that satisfies the formula, so a Luhn failure means the number was misread or mistyped.