Every well-built payment form rejects a garbage card number before it ever touches a bank — instantly, offline, using nothing but arithmetic on the digits. Three checks do the work: a checksum invented in 1954, a prefix scheme that identifies the network, and a short table of lengths. Understanding them takes ten minutes and permanently demystifies why 4242 4242 4242 4242 is everywhere.
Hans Peter Luhn, an IBM engineer, designed the algorithm that now carries his name, and card networks adopted it in the 1970s. The rule: starting from the rightmost digit, double every second digit. If a doubling produces a two-digit number, subtract 9 (adding the two digits together gives the same result). Sum everything. The number is structurally valid when the total is a multiple of 10.
Walk it with 4242 4242 4242 4242. Reading from the right, the even positions (2nd, 4th, …) hold the 4s and the odd positions hold the 2s. Each 4 doubles to 8 — single digit, no reduction needed. Each 2 stays 2. Eight of each: the weighted sum is (8 eights × 8) + (8 twos × 2) = 64 + 16 = 80. 80 mod 10 = 0, so it passes. Flip the final digit to 1 — the sum drops to 79, and 79 is not a multiple of 10, so the form rejects it. Try our Credit Card Validator to see the weighted sum for any number you type.
The checksum's power is what it catches: every single-digit mistype, and all but a handful of adjacent transpositions (typing "34" as "43"). Those two error classes cover most human typing mistakes, which is why the check has survived seventy years of payment technology.
The first six to eight digits — the Bank Identification Number, formally the Issuer Identification Number — encode the network. The ranges you'll meet in practice:
| Network | Leading digits | Length | Code on card |
|---|---|---|---|
| Visa | 4 | 16, 18, 19 | CVV, 3 digits, back |
| Mastercard | 51–55, 2221–2720 | 16 | CVC, 3 digits, back |
| American Express | 34, 37 | 15 | CID, 4 digits, front |
| Discover | 6011, 644–649, 65 | 16, 19 | CID, 3 digits, back |
| Diners Club | 300–305, 36, 38–39 | 14, 16, 19 | CVV, 3 digits |
| JCB | 3528–3589 | 16–19 | CVV, 3 digits |
Mastercard's 2221–2720 range is the interesting one: introduced in 2016 as the "2-series" to expand the network's BIN capacity, it's why some 2-prefixed cards are Mastercards. The prefix does more work than naming the brand: it tells the form how to group the digits (4-6-5 for Amex versus 4-4-4-4 elsewhere), how long the number should be, and how many digits the security code field should accept — before any network call happens.
Sixteen digits is the norm, not a law. Amex is 15; Diners Club 14; Visa tolerates 18 and 19 for certain prepaid and commercial products; UnionPay runs 14 to 19. A validator that checks Luhn alone will happily accept a 15-digit "Visa" — the length table is what makes the format check complete. The security code follows the same logic: 3 digits almost everywhere, 4 for Amex, with each network using its own name (CVV, CVC, CID, CVN, CVP2) for what is generically the card security code.
Only structure. Three things it does not prove: that the account exists (test numbers pass Luhn by design and always decline live), that it's funded and in good standing (only the issuer knows), and that the person entering it is the cardholder (that's what AVS, CVC checking, and 3-D Secure are for, all of which happen at transaction time against the network). Client-side validation exists to keep typos and junk out of the expensive authorization path — nothing more, and it's genuinely good at that job.
Because it's memorable, passes Luhn with a round sum (80), and Visa-prefixed. Stripe published it as the canonical test number, other processors copied the convention, and today virtually every checkout tutorial uses it. The broader test set covers the format edge cases: 3782 822463 10005 for 15-digit Amex with its 4-digit code (Luhn sum 60), 5555 5555 5555 4444 for Mastercard (sum 60), 6011 1111 1111 1117 for Discover (sum 30). Developers embed them in automated tests precisely because they're well-formed: the validation layer passes them, and the test reaches the code that handles the network's response.
The three checks need no network, so they can run anywhere — including entirely in your browser. Our validator page vendors braintree's open-source card-validator engine (the same library behind major checkout SDKs, MIT-licensed) and computes Luhn, brand, length, and code format locally; the network tab confirms zero requests as you type. That's also the right architecture for forms you build: validate client-side for instant feedback, then let your payment processor do the authoritative check server-side. For the numbers you practice with, use the published test set — never a real card on a page you don't control.
Luhn checksum, brand from the BIN, length and code format — computed locally.
Validate a Card Number →Validation is arithmetic, not magic: a 1954 checksum that must total a multiple of 10, a prefix table that names the network, and a length column. Together they catch the typos before money is at stake — and nothing else. Build them into every payment form, run them client-side, and keep the real existence question where it belongs, with the network at authorization time.
The Luhn checksum (a typo-catching weighted sum that must be a multiple of 10), the BIN prefix (the first 6–8 digits identify the network — 4 is Visa, 51–55 and 2221–2720 Mastercard, 34 and 37 Amex), and per-network length plus security-code rules (Amex is 15 digits with a 4-digit CID; most others are 16 with a 3-digit code). All three run instantly, offline, on the number alone — no bank is contacted.
No single-digit typo can turn one Luhn-valid number into another Luhn-valid number — that's the property the checksum was designed for. Changing any one digit shifts the weighted sum by a non-multiple of 10. Adjacent transpositions (typing "34" as "43") are caught in almost all cases too; only certain 0-and-9 style swaps slip through, which is why validation layers more checks on top.
In order of likelihood: a mistyped digit (breaks Luhn), missing digits (the number is shorter than the network's allowed lengths), or extra digits pasted along with the number. If you copied the number from a statement or email, invisible characters or spaces in odd places sometimes ride along — digits-only normalization fixes that. If every check passes but a real charge declines, that's the network rejecting the account, not the format.