PAN (Primary Account Number)
13-19 digit card number embossed on payment card. Contains BIN, account identifier, and check digit. Must be tokenized for PCI compliance.
Overview
What is PAN?
PAN (Primary Account Number) is the 13-19 digit card number on payment cards. Structure: first 6-8 digits are the BIN (Bank Identification Number) identifying the issuer, the middle digits are the account identifier unique to the cardholder, and the final digit is a check digit that validates the number using the Luhn algorithm. For merchants, PAN is sensitive data requiring strict PCI DSS compliance — storing it directly is prohibited outright.
At checkout, the gateway validates the PAN via Luhn, extracts the BIN to identify card type, issuing bank, and card level, then encrypts and routes the transaction to the appropriate network. For anything beyond a one-off charge, the gateway tokenizes the PAN instead of storing it — swapping it for a random token kept in a vault — so future transactions reference the token and the merchant's own systems never hold the real card number at all.
That distinction drives PCI scope directly: a merchant storing raw PANs falls under the full SAQ-D questionnaire (329 questions, on-site audits at higher volume, $20K-50K in annual compliance costs), while a tokenized merchant qualifies for SAQ-A (14 questions, $2K-5K annually). The gap matters even more if a breach occurs — forensic investigation, card reissuance, fraud monitoring for affected cardholders, legal fees, and potential class actions can push the cost of a breach touching 10,000+ cards past $500K-2M, a liability tokenization removes entirely since there's no PAN on the merchant's servers to expose.
In practice, the costliest mistakes are rarely deliberate — a merchant storing PANs "for convenience" or logging them into error output during debugging both trigger the same outcome: full PCI scope, and in the logging case an automatic compliance failure requiring a complete log purge and re-audit before processing can continue. Displaying only the last 4 digits, encrypting on capture, and routing card entry through a hosted page or iframe avoids all of it at the source.
In depth
Everything you need to know.
Customer enters PAN at checkout. Gateway validates using Luhn algorithm (mathematical check). Gateway extracts BIN to identify card type (Visa, Mastercard), issuing bank, card level (consumer vs commercial). Gateway encrypts PAN, transmits to processor. Processor routes to appropriate network based on BIN. For storage: gateway tokenizes PAN (replaces with random token), stores token in vault. For future transactions: merchant references token, gateway retrieves associated PAN, processes charge. PAN never stored in merchant systems.
PAN security is critical for PCI compliance and breach liability. Storing PANs in merchant systems creates massive PCI scope: full SAQ-D questionnaire (329 questions), on-site audits for high volume, $20K-50K annual compliance costs. If breached, merchant faces forensic investigation ($50K-200K), card reissuance costs ($5-10 per card), fraud monitoring for victims ($50-100 per person), legal fees, class actions. Breach affecting 10,000+ cards costs $500K-2M+. Tokenization eliminates PAN storage, reducing PCI scope to SAQ-A (14 questions), cutting compliance costs to $2K-5K annually, and eliminating breach liability for card data.
Illustrative example — not a specific client engagement.
- Merchant stored full PANs in database for convenience. Data breach exposed 15,000 cards. Costs: $180K forensic investigation, $75K card reissuance, $1.2M fraud losses, $300K legal fees, 2-year class action. Total: $1.75M. Switched to tokenization - $2K annual compliance vs $1.75M breach cost.
- Subscription service tokenized PANs after first charge. 85,000 active subscribers. Tokens stored, PANs never saved. PCI compliance: SAQ-A ($2K annual). If stored PANs: SAQ-D ($18K annual). Saved $16K annually on compliance, eliminated breach liability.
- Payment platform logged full PANs in error logs for debugging. Discovered during PCI audit. Immediate failure. Required: purge all logs (3-year retention), implement PAN masking, re-audit ($25K cost), 6-month compliance delays. Should have masked PANs in logging from start.
- Never store PANs - use tokenization for all recurring billing and saved payment methods
- Validate PANs client-side with Luhn algorithm - catch invalid cards before API submission
- For display: show only last 4 digits and card type (Visa ending 1234)
- Use hosted payment pages or iframes - PAN never touches your servers, minimal PCI scope
- Encrypt PANs immediately upon capture - TLS 1.2+ for transmission
- For recurring billing: tokenize after first charge, reference token for future charges
- Audit all systems: ensure no PAN logging in application logs, error logs, database queries
- Storing full PANs in databases - massive PCI scope, breach liability, typically $15K-45K extra annual compliance cost
- Logging PANs in application logs - automatic PCI failure, requires immediate remediation
- Displaying full PANs to customers after purchase - PCI allows only last 4 digits visible
- Not validating PAN with Luhn algorithm before submission - wastes processing attempts on invalid cards
- Assuming masked PAN (****1234) is sufficient - PCI requires tokenization for storage, not masking
- Sending PANs via email or unencrypted channels - violates PCI, creates security risk
Keep exploring
Related terms
Put this to work
for your business.
MIDs structures high-risk acquiring across 30+ banks — smart routing, fraud and chargeback control built in. Tell us your category and volume and we'll build the setup around it.