Pick a validator that runs three checks in order, length, character set, and the Luhn check digit, plus a BIN range lookup, and that runs them on your own server with a duplicate check in the browser for user experience. It should return a boolean plus a specific error reason, and it should never store or log the full card number or the security code. Anything marketed as a way to test whether a card is live, or to buy card data, is a fraud tool, not a validator, and this guide does not cover it.

What a validator does and does not do

A validator confirms that a string is shaped like a payment card number. It applies the check digit math defined in ISO/IEC 7812, applies the length rules for each network, and matches the leading digits against issuer identification ranges to label the brand. It does not confirm that the account exists, that it has funds, that it is open, or that the person typing it owns it. Only an authorization request sent through your payment processor answers those questions, and that request returns an approval code, a decline code, or a referral.

That distinction matters when you scope the purchase. You are buying input hygiene and a better checkout error message, not verification of a customer.

What to look for

  • Server-side authoritative check, with the same rules mirrored client-side for instant feedback.
  • Distinct error codes for wrong length, non-digit characters, failed check digit, and unrecognized issuer range.
  • No network calls, no telemetry, and no dependency on a vendor API for a math function.
  • PAN masking in every log line, trace, and analytics event before the value leaves the request handler.
  • Support for the networks you actually accept, with issuer range tables refreshed on a published schedule.
  • A test suite that ships known-good and known-bad vectors so you can verify behavior after upgrades.
  • A license that permits commercial use and a dependency tree you are willing to audit.

Parameter bands

  • Accepted length: 12 to 19 digits. Most consumer cards are 16. Reject outside the range before any other check.
  • Check digit: required. Expect roughly one in ten random digit strings to pass the check digit alone, so treat this as a typo filter, not proof.
  • Issuer range: six leading digits at minimum, eight where the network publishes them.
  • Latency: under 5 ms for a local check. If a library needs a round trip, it is a service, not a validator.
  • Error taxonomy: four or more distinct reasons. One generic invalid message costs you support tickets.
  • Range updates: monthly or better, since issuer ranges shift as portfolios move.

Pitfalls

  • Treating a passing check digit as a valid card and skipping the authorization step.
  • Storing the card verification value. PCI DSS forbids retaining sensitive authentication data after authorization, and no checkout feature justifies it.
  • Logging the full primary account number in application logs, error trackers, or session replays.
  • Relying on browser validation alone. It is trivially bypassed and is a usability feature, not a control.
  • Third-party validators that transmit the number to an unknown endpoint. That is data exfiltration with a friendly name.
  • Card checking services that claim to confirm live accounts. They exist to harvest numbers or resell them, and using one exposes your business to criminal liability.

FAQ

Does a number with a valid check digit actually work? No. The check digit catches typos and transpositions only.

Should validation run in the browser or on the server? Both, with the server as the authority. The browser version exists to give fast feedback.

Can I store the CVV to speed up repeat orders? No. Storage of the verification value is prohibited, and processors will fine merchants who retain it.

Are open source validators safe to use? They can be, if the license fits, the dependency count is small, and the test vectors match your networks. Read the code before you ship it.

How should I test my integration? Use the sandbox test numbers published by your payment processor. Never test with numbers from any other source.

Someone offered to sell or verify card numbers for me. Is that legitimate? No. Buying, selling, or testing card data you do not own is a crime in the United States and most other jurisdictions, and the offer itself is usually a scam aimed at you.