The most dependable format check for a payment card number is the Luhn checksum paired with an issuer identification number (BIN/IIN) range lookup. Neither test works alone: the checksum catches mistyped digits, and the BIN range catches numbers that no issuer could have assigned. I scored each method on three criteria: what it actually proves, how often it creates false confidence, and whether using it pulls your system into PCI DSS scope.

What a card number validator really checks

A payment card number is structured, not random. Under ISO/IEC 7812, the leading digits identify the issuer, the middle digits identify the account, and the final digit is a check digit. A validator that follows the standard examines structure only. It reads digits, applies a formula, and returns yes or no. It never contacts an issuer, never sees a balance, and never confirms that an account is open.

That gap matters because "valid" means two different things in practice. A number can be well formed and belong to nobody. A number can be well formed and belong to a closed or frozen account. Only an authorization request through a payment network answers the question most people are really asking.

Option 1: The Luhn checksum

The Luhn formula, sometimes called mod 10, is the check digit scheme in ISO/IEC 7812. Start at the rightmost digit and move left, doubling every second digit. If a doubled value tops 9, subtract 9. Add everything together. A total that ends in zero passes.

Pros

  • Runs offline in microseconds with no network call
  • Catches every single mistyped digit and almost every adjacent transposition
  • Trivial to implement in any language for form validation

Cons

  • About one in ten random digit strings passes by chance
  • Says nothing about whether an account exists or is open
  • Cannot detect a wrong but well formed number

Use it when

You are validating input on your own checkout or billing form and want to stop typos before a payment request leaves your server.

Option 2: BIN and IIN range checks

A bank identification number, now usually called an issuer identification number, is the leading block of digits that maps to an issuing institution and a card product. Range tables let a validator confirm that a prefix was actually assigned and that the length matches the brand.

Pros

  • Rejects prefixes that no issuer has ever been allocated
  • Confirms card length and rough product type
  • Useful for routing and for fraud rules on your own traffic

Cons

  • Ranges get reassigned, merged, and retired, so tables age
  • Identifies an issuer, never an account holder
  • A correct BIN proves nothing about account status

Use it when

You need to route or segment transactions, or you want a second structural filter behind the checksum.

Option 3: Authorization, the only real verification

An authorization request goes to the issuer through the card network and returns an approval or a decline. It is the sole method that confirms a card is open, has available funds, and matches the account holder on file.

Pros

  • Answers the question format checks cannot
  • Produces an auditable record for dispute handling
  • Supports address and security code verification at the same time

Cons

  • Requires merchant credentials and a payment network connection
  • Carries per attempt cost and interchange rules
  • Running test authorizations against cards you do not own is a federal crime, not a test

Use it when

You are a merchant taking a real payment, or you are verifying a card that a customer has presented to you directly.

What no validator can tell you

A format check cannot confirm the name on the account, the billing address, the card's 3-D Secure enrollment, or whether the number appears on a fraud blocklist. It also cannot tell whether the number was reported stolen. Vendors that advertise "100 percent validity" checks are selling a claim that no format test can support, because validity in that sense requires an issuer response.

Legal lines worth knowing

Testing card numbers that do not belong to you is not a grey area. Under 18 U.S.C. section 1029, using or trafficking in unauthorized access devices, which includes payment card numbers, is a federal offense. PCI DSS also restricts how full primary account numbers may be stored and forbids retaining sensitive authentication data after authorization. If you are building a payment form, keep the number out of your logs, out of your database, and out of your analytics.

Recommendation by use case

  • Checkout form: client side length check, then Luhn, then a server side authorization. Nothing else.
  • Cleaning your own records: Luhn plus a BIN lookup finds typos in data you already own and are entitled to hold.
  • Auditing a vendor: ask whether they touch full card numbers at all. A vendor that only sees a token keeps you out of scope.
  • Testing numbers you obtained from someone else: there is no compliant version of this. It is fraud, and format checks do not change that.