Visa Card Number Format Explained

Every Visa card number begins with 4, carries a Luhn check digit in the final position, and is 13, 16 or 19 digits long — almost always 16. The three-digit CVV2 on the back is computed by the issuer and is not part of the number.

That is the format. What makes Visa interesting is the first digit, which Visa owns outright in a way no other network does, and the two lengths that are not 16.

This is the reference; if you need numbers to test with, the Visa card generator produces them.

The format at a glance

Why 4, and why it matters

ISO/IEC 7812 divides the first digit — the Major Industry Identifier — into ten categories, and assigns 4 to banking and finance. Visa holds all of it.

That sounds like trivia and has a practical consequence. Compare what identifying each network takes:

Visa is the only major network identifiable from a single character with no ambiguity, no overlap, and no boundary conditions. In progressive brand detection — showing the right logo as someone types — Visa is the case that resolves on keystroke one, while a Mastercard number may need four before you can be certain.

The corollary is that the leading 4 tells you the network and nothing else. It does not tell you the issuing bank, the country, the product, or whether the card is debit or credit. For any of that you need a BIN lookup, because none of it is encoded in the digits.

The three lengths

16 digits is the standard and covers nearly everything issued today.

13 digits is legacy. Visa issued them before 16 became the norm, and the specification still permits them — which means a validator built on ^4\d{15}$ rejects a format Visa has never withdrawn. The account identifier is simply shorter; the arithmetic is identical.

19 digits is the extended format, appearing on some products and in some markets. It is the length that causes damage, because the failure is silent rather than loud: a field capped at 16 characters truncates on entry, and a VARCHAR(16) column truncates on write with no error. The row saves and the stored number is wrong. The length rules across networks cover how to size fields and columns once for every card you accept.

Product families, and what the number does not reveal

Visa is a family of products sharing one prefix:

• Visa Classic, Gold, Platinum, Signature, Infinite — tiers, distinguished by BIN assignment rather than by anything in the format
• Visa Debit — same 4, same lengths, indistinguishable from credit by format
• Visa Electron — issued on 4026, 417500, 4405, 4508, 4844, 4913, 4917
• V PAY — a Europe-only chip-and-PIN product, also on 4
• Visa Purchasing, Corporate, Fleet — commercial products on separate BIN ranges

Electron is the one worth understanding, because the difference is behavioural rather than structural. Electron transactions require an online authorisation with a real-time balance check and do not permit going overdrawn, which is why the product was widely issued on accounts where an overdraft was not on offer. Nothing about that shows up in the number’s shape — a valid Electron number such as 4026 1738 4512 9037 is a perfectly ordinary 16-digit Visa number, and only the prefix marks it out.

The general rule holds across all of them: the number identifies the network, and the BIN database identifies everything else.

The security code

Visa’s is called CVV2: three digits, printed on the signature panel on the back of the card, and not part of the card number. Mastercard’s equivalent is CVC2 and American Express’s is a four-digit CID on the front — same mechanism, different brand names and, in Amex’s case, a different length.

Two properties matter when you build a form. The code is never derivable from the number: the issuer computes it from the account number, expiry and service code under a pair of keys that never leave its hardware security module, which is precisely the security property it exists to provide. And it must never be retained after authorisation — not encrypted, not hashed, not in a log. It proves the card was in someone’s hand at the moment of entry, and storing it destroys the only thing it was for.

For a Visa form specifically, that means a fixed three-character field is safe only if you accept Visa alone. The moment American Express is in scope, the field’s length has to follow the detected brand.

Validation rules for your form

const VISA = /^4\d{12}(?:\d{3})?(?:\d{3})?$/;   // 13, 16 or 19 digits

// Visa Electron sits inside the Visa range on specific prefixes.
const VISA_ELECTRON = /^(?:4026|417500|4405|4508|4844|4913|4917)\d{12}$/;

function isVisa(pan) {
  const digits = String(pan).replace(/\D/g, '');
  return VISA.test(digits) && luhnValid(digits);
}

Three things that pattern gets right and most do not. It accepts all three lengths rather than only 16. It is anchored at both ends, so it cannot match a prefix of some longer string. And it pairs the format test with a checksum test rather than treating either as sufficient — 4026 0000 0000 0000 matches the Electron prefix pattern above and fails Luhn, which is exactly the case that shows why both checks are needed.

Cases worth having in your suite:

All of the valid numbers above are synthetic and Luhn-valid; paste them into the validator to confirm.

History

Visa began as BankAmericard, launched by Bank of America in Fresno, California in 1958 — the first successful general-purpose consumer credit card. The programme was licensed to other banks through the 1960s, spun out into a member-owned association in 1970, and renamed Visa in 1976, a name chosen to be pronounceable in every market it operated in.

The 4 assignment dates from the standardisation of card numbering, when the ISO framework allocated the first digit by industry and the banking category was divided between the networks that existed. Visa’s share of it has never changed since, which is why a Visa number issued in 1980 and one issued this year share their first digit and their check-digit rule, differing only in length and in what the middle digits encode. Visa’s own numerics documentation covers the current assignment rules, including the migration to eight-digit BINs.

Common integration mistakes

1. Assuming 16 digits. ^4\d{15}$ is the single most copied Visa regex and it rejects both the 13-digit and 19-digit formats.
2. Truncating 19 digits. An input maxlength of 16 or 19, or a VARCHAR(16) column, corrupts the number without raising anything. Size for 19 digits, or 23 characters if you keep the spaces.
3. Treating Visa Electron as a separate network. It is a Visa product on Visa prefixes; routing it as its own brand produces a card your gateway does not recognise.
4. Inferring debit or credit from the number. Nothing in the format carries it, and code that guesses will be wrong for a substantial share of cards.
5. Storing the number as an integer. Nineteen digits exceeds a 64-bit signed integer, and leading digits are meaningful — card numbers are strings from input to storage.

The first two account for most Visa-specific bug reports, and both are invisible until a customer with an unusual card tries to pay. Neither shows up in analytics either, because a customer whose valid card is rejected at the form does not file a ticket — they leave, and the event is recorded as an abandoned checkout rather than a defect.