A card number validator answers one narrow question: could this string of digits be a payment card number? It runs a checksum called the Luhn algorithm, compares the length and leading digits against known issuer ranges, and returns pass or fail. That is the whole job. A validator cannot tell you whether an account is open, funded, stolen, or authorized for a charge. It also cannot make an illegally obtained card number usable, and buying or selling card numbers is a federal crime in the United States. Use validation to catch typos in a checkout form, not to test numbers you do not own.
What a validator actually checks
Most validators run three or four independent tests and report the results separately. Confusing them is the most common mistake.
- Luhn checksum. A single check digit catches any one wrong digit and most adjacent-digit swaps. It is a typo filter, nothing more. Random 16-digit strings pass about one time in ten.
- Length. ISO/IEC 7812 allows primary account numbers from 12 to 19 digits. Real networks use narrower windows inside that range.
- Issuer identification number (IIN), still widely called BIN. The leading digits map to the network and the issuing institution. This is a range lookup, not a live account query.
- Format of the expiry and security code fields. A validator can confirm that the expiry is a plausible month and year. It cannot confirm that either value is correct.
What to look for when you pick a validator
Whether you are evaluating a library, a hosted API, or an internal function, the same criteria apply.
- Runs offline or client side. A pure function or a local library keeps card data inside your own environment. Typing a live card number into a third-party website to see if it validates is a data leak you cannot undo.
- Returns granular results. You want a separate flag for checksum, length, and IIN range so you can show a helpful error instead of a generic rejection.
- Never stores or transmits the security code. The three or four digit verification value must not be written to disk, logged, or sent anywhere except the authorization request. PCI DSS classifies it as sensitive authentication data and forbids retention after authorization.
- Does not log the full account number. Mask to the last four digits in every log line and error message.
- Is actively maintained. IIN ranges change as issuers merge and new ranges are allocated. A library that has not been updated in years will misclassify cards.
Parameter bands worth knowing
These are the ranges a typical validator works within, useful when you are reading its source or writing your own rules.
- Total length: 12 to 19 digits per ISO/IEC 7812, with most consumer cards at 15 or 16.
- Leading digit (major industry identifier): 3 for travel and entertainment networks, 4 for Visa, 5 and 2 for Mastercard, 6 for Discover.
- Checksum: Luhn, applied to the full primary account number including the check digit.
- Checkout behavior: validate on blur or on submit, not on every keystroke, so you do not flag a number before the user finishes typing it.
Pitfalls that cost merchants money
A passing Luhn check is not authorization. Declining a card because your validator rejected a valid number costs you a sale, and accepting one because it passed the checksum tells you nothing about fraud. Client-side validation is a convenience feature and can be bypassed, so the server must repeat every check. Storing the security code even briefly, or including it in a support ticket, violates PCI DSS. Finally, treat any free online validator that asks for a real card number as hostile: the input is exactly what a fraud operation wants, and there is no legitimate reason to submit live card data to a site that only performs a public checksum.
FAQ
Does a valid number mean the card works?
No. It means the digits are internally consistent. Only an authorization request through a payment processor can confirm that an account exists and has funds.
Can I store the security code if I encrypt it?
PCI DSS prohibits storing the verification value after authorization, encrypted or not. Encryption does not change the rule.
Why did a legitimate card fail validation?
Usually a stale IIN table, a length rule set too narrow for that network, or a user typing spaces and dashes. Strip non-digits first, then validate.
Is it legal to check whether a card number is valid?
Validating your own card in your own checkout is routine. Testing numbers you obtained from someone else, or buying and selling card numbers, is criminal activity in the US and most other jurisdictions. A validator is not a loophole.