1001Ferramentas
Validators

Credit Card Validator

Validate credit card numbers using the Luhn algorithm. Identifies the card brand and verifies the check digit, no data sent to servers.

How does the Luhn algorithm work?

Every credit card brand relies on the Luhn algorithm, also known as modulo 10. Starting from the right, you double each second digit; whenever the result exceeds 9, just subtract 9. The number checks out if the sum of all digits is divisible by 10.

The first digit is what gives away the brand. Visa starts with 4, MasterCard with 5 and Elo with 6.

The whole check runs inside your browser. No number you type ever reaches a server.

From Luhn to PCI-DSS: what credit card validation really means

A credit card number — formally the PAN (Primary Account Number) — is an ISO/IEC 7812 identifier. Validation has three layers, often confused with one another: format (length and digits), arithmetic (the Luhn mod-10 check digit), and brand identification via the leading digits (the BIN/IIN). None of these prove the card exists, is active, has funds, or belongs to the person presenting it; only an authorization call to the issuer answers those questions.

This client-side validator runs the first two layers offline. It is the same logic used by Stripe Elements, Mercado Pago Checkout Bricks and Adyen Web Components to reject typos before a token request hits the network — saving latency and reducing fraud noise on the backend.

BIN/IIN: the first 6 digits identify brand and issuer

The first 6 (now expanding to 8) digits of a PAN form the Bank Identification Number / Issuer Identification Number. They identify the card brand, the issuing bank and even product tier (classic, gold, black). Major BIN ranges:

  • Visa: starts with 4, lengths 13/16/19.
  • Mastercard: 51-55 or 2221-2720, length 16.
  • American Express: 34 or 37, length 15.
  • Discover: 6011, 65, length 16.
  • Diners Club: 36, lengths 14/16.
  • JCB: 35, length 16.
  • Elo (Brazil): specific BIN list (e.g. 40117, 431274, 451416, 50670, 506699, 506715, 509000-509999, 627780, 636297), length 16.
  • Hipercard (Brazil): 606282, length 16.

In Brazil, Visa and Mastercard hold roughly 80% market share. Elo — a joint venture between Banco do Brasil, Bradesco and Caixa — sits near 13%, and Hipercard (Itau-owned) holds about 3%. Anti-fraud platforms like ClearSale, Konduto and Adyen Antifraud use the BIN as an early signal: a Visa BIN from a high-fraud country combined with a Brazilian shipping address raises the risk score before the gateway is even called.

The Luhn mod-10 algorithm

Hans Peter Luhn (IBM, 1954) designed mod-10 to catch single-digit typos and adjacent-digit transpositions — the two most common human errors when copying a card number. Procedure:

  • Starting from the rightmost digit, double every second digit.
  • If a doubled value exceeds 9, subtract 9 (equivalent to summing its digits).
  • Sum all digits.
  • The PAN is valid if sum mod 10 == 0.
4539 1488 0343 6467
digits doubled (R-L, even pos):
8,3,7,9,4,4,1,1
sum = 80, 80 mod 10 = 0  -> valid

CVV, expiry, and what the client cannot validate

The CVV/CVC/CID (3 digits on the back for Visa, Mastercard, Discover; 4 digits on the front for Amex) is generated by the issuer using a secret key and the PAN — it cannot be computed offline and is intentionally non-derivable. Expiry validation only checks that MM/YY is a future date. These two fields, together with the cardholder name, complete a CNP (Card Not Present) transaction but provide no authorization signal until the issuer responds.

Storing the full PAN, CVV or magnetic stripe data on client-side or in unencrypted logs violates PCI-DSS v4.0, the security standard maintained by the PCI Security Standards Council (Visa, Mastercard, Amex, Discover, JCB). Modern fintechs avoid the burden entirely via tokenization: Stripe, Mercado Pago and Adyen replace the PAN with a single-use or scoped token, so the merchant never touches sensitive data.

EMV, 3D Secure and PSD2 SCA

EMV is the chip-and-PIN standard (Europay, Mastercard, Visa) that replaced the magnetic stripe for present-card transactions. 3D Secure 2.x adds a frictionless authentication layer to CNP flows; under EU PSD2 it implements Strong Customer Authentication (SCA), requiring two factors out of knowledge, possession and inherence. In Brazil, Bacen's open-finance regulation is steering issuers toward equivalent biometric step-up.

Libraries and test cards

  • card-validator (Braintree, npm) — brand + Luhn detection used in Drop-in UI.
  • creditcards (npm) — pure Luhn + format helpers.
  • Stripe test PAN: 4242 4242 4242 4242 always passes Luhn, brand = Visa.
  • Adyen / Mercado Pago publish per-brand test PANs in their dashboards.

Anti-pattern alert: do not run Luhn while the user is still typing — it will flash "invalid" until the last digit. Validate only after blur, after pasting, or when the length matches the expected size for the detected brand.

FAQ

Can I detect the brand from the BIN alone? Yes. The first 6 (now 8) digits uniquely identify brand and issuer when matched against a BIN database. Brand-detection libraries ship with the most common ranges already; for Elo and Hipercard you may need an updated list, since their BIN tables grow yearly.

Should the CVV ever travel in a URL or QR code? No. PCI-DSS explicitly forbids storage of the CVV after authorization, and emitting it over any non-encrypted channel is non-compliant. Tokens are the correct vehicle for repeat payments.

Do tokens replace the PAN end-to-end? Yes. Stripe, Mercado Pago and Adyen issue scoped tokens that reference the saved PAN only inside their vault. Your backend stores the token; the PAN never enters your database, drastically narrowing PCI-DSS scope.

Does Luhn-passing mean the card is real? No. Luhn is a typo guard, not a proof of existence. Roughly 10% of randomly generated 16-digit sequences pass mod-10 by chance — only an authorization call confirms the card is real and active.

Is the test PAN 4242 4242 4242 4242 safe to commit? Yes. It is a public Stripe test card that only works in test mode and never charges money. Real cards must never be committed to git or pasted into shared logs.

How to validate a card number

Before sending a card number to the gateway, a quick check catches most typos: the Luhn algorithm. It sums the digits with an alternating weight and sees whether the total adds up. This validator runs that calculation and also identifies the brand from the number's prefix.

It's the kind of check that belongs inside the form itself, handing the answer back to the user without a server round-trip. Just don't read too much into it: Luhn confirms the number is well formed, nothing more. It can't tell whether the card exists, has a balance or is within its expiry. Only the issuer answers that. You can type it with or without spaces.

Validation runs entirely in the browser and no data leaves your device. Even so, the usual advice still stands: avoid typing real cards on sites you don't trust.

Related Tools