How the Luhn checksum is calculated
The Luhn algorithm, also called mod 10, is specified for payment cards in ISO/IEC 7812-1. Start at the rightmost digit and move left, doubling every second digit. When doubling gives a two digit result, subtract 9. Add everything up. If the total ends in zero, the number passes. The last digit of every card is a check digit chosen to make that happen.
Take 4111 1111 1111 1111. The doubled positions hold the 4 and seven 1s, which become 8 and seven 2s, a subtotal of 22. The other eight digits are all 1s and add 8. The total is 30, so the number passes. Change the final 1 to a 2 and the total becomes 31, which fails.
What the checksum catches and what slips through
Luhn was designed to catch keying mistakes. It detects every single wrong digit and almost every swap of two neighbouring digits. The one swap it misses is 09 for 90. It also misses a few doubled-digit errors, such as 22 typed as 55. For a number copied from a card or read out over the phone, that covers the mistakes people make most.
It is not a security feature. The formula is public, one in every ten random digit strings passes it, and card number generators produce passing numbers on demand. Treat a pass as evidence that nothing was mistyped, and nothing more.
Reading the tiles and the anatomy table
Result is the verdict: Too short below 12 digits, then Valid or Invalid. Network names the brand matched from the prefix. Luhn checksum shows Passes or Fails on its own, and Length shows the digit count with the lengths that network uses underneath, for example 15 for American Express or 13, 16, 19 for Visa. Result needs both of those to pass.
Number anatomy appears once six digits are in. The first digit is the major industry identifier: 3 for travel and entertainment, 4 and 5 for banking. The issuer ID is the leading block of up to eight digits that identifies the bank. The account digits in the middle are masked as dots, the last digit is the check digit, and the security code length is 4 for American Express and 3 for the rest.
Testing a checkout form with sample numbers
The five buttons load numbers that payment processors publish for test environments: 4111 1111 1111 1111 for Visa, 5555 5555 5555 4444 for Mastercard, 3782 822463 10005 for American Express, 6011 1111 1111 1117 for Discover and 3530 1113 3330 0000 for JCB. They pass every format check and belong to no account, so a live gateway declines them.
Use them to confirm that your form accepts 15 digit Amex numbers, copes with spaces and dashes, and switches the brand logo as the prefix is typed. Then break one on purpose: alter a single digit and check that the form rejects it. Client-side validation saves a round trip to the processor for an obvious typo, but the processor's answer is the one that counts.
What a valid result does not tell you
The validator cannot see whether a number was ever issued, whether the account is open, what its limit or balance is, who holds it or when it expires. There is no expiry date or security code field, because neither can be checked by arithmetic. Only the issuing bank answers those questions, during an authorisation request sent through a payment processor.
It does not name the bank either. The issuer prefix is shown, but mapping it to an institution needs a database. Put the first six to eight digits into the BIN checker for the issuer, card type and country. Network ranges also change over time, so a newly assigned prefix can show Unknown here and still belong to a real card.