Primary Account Number (PAN)

A Primary Account Number (PAN) is the payment-card account number used to identify an issuer and card account for authorization, clearing, and related processing. It is commonly the long number displayed on a physical or virtual card, but it is not the same as a deposit-account number, PIN, security code, or payment token.

Key Takeaways

• PAN length varies; 16 digits are common, but ISO/IEC 7812 supports PANs up to 19 digits.
• The current structure begins with an eight-digit Issuer Identification Number, often called a BIN.
• The remaining digits include an issuer-assigned account identifier and a final check digit.
• A Luhn-valid PAN can still be fabricated, closed, blocked, expired, or used without authorization.
• PCI DSS protection centers on environments that store, process, or transmit PAN and other covered cardholder data.
• Masking, truncation, encryption, and tokenization are different controls and should not be treated as synonyms.

PAN Structure

A simplified PAN can be represented as:

1[ IIN ][ issuer account identifier ][ check digit ]

The commercial term BIN is still widely used for the issuer prefix. Older systems can use the first six digits as a BIN range, while the current ISO structure defines an eight-digit IIN.

Do not assume the visible PAN maps one-to-one to a single piece of plastic. An account can have replacement cards, virtual credentials, network tokens, or separate PANs for authorized users depending on issuer design.

Luhn Validation

The Luhn algorithm checks whether a number is internally consistent with its check digit. In simplified form, it:

1. works across the PAN digits from right to left;
2. doubles alternating digits according to the algorithm’s position rule;
3. subtracts 9 from doubled results greater than 9;
4. sums the resulting digits; and
5. treats a total divisible by 10 as valid.

Luhn validation detects many common typing errors. It does not contact the issuer or prove that:

• the account exists or is open;
• the card is funded or within its credit limit;
• the expiration date or security code is correct;
• the person entering it is the cardholder;
• the transaction is authorized; or
• the merchant will retain final settlement.

Use generated test numbers supplied by payment processors or networks in development. Do not put real PANs in source code, tickets, screenshots, analytics, or test logs.

PAN vs. Related Card Data

Knowing one element does not validate the others. A merchant should collect and retain only the data required by its payment design and applicable rules.

PAN vs. Payment Token

EMV payment tokenization replaces a PAN in a transaction flow with an alternative value. The token can be restricted by merchant, device, wallet, channel, or other domain controls, reducing the usefulness of compromised transaction data.

Tokenization is not the same as displaying a masked PAN:

• Masking hides selected digits when data is displayed but can leave the full PAN stored underneath.
• Truncation permanently removes a defined segment from a stored or exported value.
• Encryption transforms PAN using cryptography and permits recovery with authorized keys.
• Tokenization substitutes another value and maintains an authorized mapping in a token system or vault.

Each method has different architecture and PCI implications. A format-preserving value that looks like a PAN is not automatically out of scope.

Worked Example: What a Merchant Should Retain

Assume an online merchant authorizes a $240 purchase. Its processor returns:

• an approved authorization result;
• a processor transaction ID;
• card brand and issuer metadata;
• a token for future merchant-initiated transactions; and
• a masked display value ending in 1234.

The customer-service system needs to locate the order and tell two cards apart. It generally does not need the full PAN. The merchant can retain the transaction ID, approved token where appropriate, brand, and a compliant masked or truncated display under its payment-provider and PCI design.

The authorization still does not guarantee final payment. The transaction can fail in capture, be reversed, be disputed, or become a chargeback. The merchant should reconcile authorization, capture, clearing, settlement, refund, and dispute records rather than treat the PAN as proof of payment.

PAN in Card Processing

The PAN can appear, directly or through protected substitutes, during:

• card-present chip or contactless authorization;
• e-commerce and in-app payments;
• recurring or merchant-initiated transactions;
• wallet provisioning and tokenization;
• clearing and settlement messages;
• refunds and reversals;
• dispute and chargeback records; and
• fraud monitoring and reconciliation.

Different participants should not expose the full PAN merely because it travels through the payment ecosystem. Tokenization, point-to-point encryption, hosted payment fields, and processor vaults can reduce merchant handling of raw card data when properly implemented.

PCI DSS and PAN

PCI SSC states that PCI DSS applies to environments that store, process, or transmit covered payment-card account data. PAN is the defining cardholder-data element; cardholder name, service code, and expiration date are also cardholder data when present with PAN.

Practical questions include:

• Where can PAN enter the environment?
• Which applications, logs, backups, and support tools can store it?
• Is transmission encrypted over trusted protocols?
• Are displays masked to the minimum business need?
• Are stored values truncated, encrypted, tokenized, or otherwise protected under the applicable requirements?
• Who can reveal or retrieve the full value?
• Are retention and secure-deletion rules enforced?

Compliance conclusions require the current PCI DSS, payment-brand rules, environment scope, and advice from qualified specialists where needed.

Common Mistakes and Risks

• Assuming every PAN has exactly 16 digits.
• Defining the IIN as only the first six digits in a current system.
• Treating a successful Luhn check as issuer authorization.
• Logging full PANs in error messages, analytics, or customer-support tools.
• Confusing masking with irreversible truncation.
• Assuming every numeric payment token is the underlying PAN.
• Emailing card details or collecting them through an unapproved form.
• Retaining PAN “just in case” without a documented business and security requirement.

Authoritative Sources

• ISO: ISO/IEC 7812-1 issuer identification and PAN numbering
• PCI SSC: PCI Data Security Standard
• PCI SSC: Eight-digit BINs and PCI DSS
• PCI SSC: Scope of PCI DSS for payment-card and bank-account data
• EMVCo: Payment Tokenisation

Related Terms

• Bank Identification Number: IIN forming the leading issuer-identification portion of the PAN.
• PCI DSS: Security standard for covered payment-card account-data environments.
• Bank Account Number: Deposit, loan, or other bank-account identifier, distinct from a PAN.
• Fraud Detection: Analysis and controls used to identify potentially unauthorized transactions.

FAQs

Payment-card standards and network rules can change. This page provides general education, not PCI-compliance, payment-processing, cybersecurity, legal, or fraud-management advice.