How Primary Account Number (PAN) Works
The PAN is the central identifier in every card-present and card-not-present transaction. Understanding its structure and how it moves through the payment ecosystem is foundational to designing secure integrations and scoping PCI DSS compliance programs correctly. The number is not arbitrary — each segment carries specific meaning governed by ISO/IEC 7812.
PAN Structure and the BIN
A PAN is divided into three logical segments. The Major Industry Identifier (MII) is the first digit — 4 for Visa, 5 for Mastercard, 3 for American Express. The next 5–7 digits complete the Bank Identification Number (BIN), identifying the issuing bank, card product tier, and country of issuance. The middle segment holds the individual account number, and the final digit is a Luhn check digit that detects transcription and input errors before a transaction is ever submitted.
Card-Present Authorization
At a POS terminal, the PAN is read from the EMV chip or magnetic stripe and transmitted to the acquirer inside an encrypted authorization request message. The acquirer routes the request through the card network — Visa, Mastercard, or Amex — to the issuing bank, which validates the PAN, checks the available balance, applies fraud scoring, and returns an approval or decline code. The entire round trip typically completes in under two seconds.
Card-Not-Present (E-commerce) Flow
In an e-commerce transaction, the shopper manually enters their PAN into a payment form. Best-practice integrations use hosted payment fields or a JavaScript payment library so the PAN is submitted directly to the payment processor — never touching the merchant's web server or application layer. This out-of-scope architecture eliminates the merchant's server from PCI DSS Requirement 4 (transmission security) and Requirement 3 (storage security) simultaneously.
PAN Tokenization at Capture
Modern payment stacks replace the PAN with a tokenization surrogate the moment it is captured. The token is stored in the merchant's systems for recurring billing, refunds, and dispute management, while the real PAN lives only in a secure token vault operated by the processor or a dedicated token service provider. This severs the connection between a merchant data breach and usable card data entirely.
PAN Transmission Security Requirements
Every network hop that carries a PAN must be protected by encryption — TLS 1.2 or higher for data in transit, and AES-256 or equivalent for data at rest. A PAN must never appear in query strings, URL parameters, browser cookies, server access logs, or error messages. These surfaces are rarely covered by standard TLS controls and are frequently accessible to systems far outside the primary PCI DSS assessment boundary.
Why Primary Account Number (PAN) Matters
The PAN is the most valuable single data element in a payment breach. Every other card attribute — expiry date, CVV, billing address — is operationally useful to an attacker only when combined with a valid PAN, which is precisely why PCI DSS was architected around protecting it specifically. A single unencrypted database containing raw PANs can expose millions of cardholders to card-not-present fraud within hours of a breach being exploited.
Three data points illustrate the scale of the risk:
- $4.45 million — the global average total cost of a data breach according to IBM's Cost of a Data Breach Report 2023, a 15% increase over the prior three years. Breaches involving payment card data consistently rank among the most expensive record types when card replacement, regulatory fines, and fraud liability are factored in.
- Over 40% of financially motivated intrusions target payment card data, according to the 2023 Verizon Data Breach Investigations Report. Card numbers remain one of the two most frequently stolen data types in point-of-sale and e-commerce attacks globally.
- Tens of billions of network token transactions were processed annually by 2023 across Visa Token Service and Mastercard MDES combined, reflecting the industry's accelerating structural shift away from transmitting raw PANs across merchant infrastructure and into token-based flows.
PCI DSS Scope Trigger
Any system that stores, processes, or transmits a PAN is automatically drawn into scope for PCI DSS assessment. Removing PANs from your environment entirely — through tokenization, out-of-scope hosted fields, or point-to-point encryption — is the single most effective way to reduce your annual compliance assessment burden.
Primary Account Number (PAN) vs. Payment Token
PAN and payment tokens are frequently confused, including among developers building payment integrations for the first time. A token intentionally mimics the PAN format — same length, same numeric structure — but contains no sensitive account data whatsoever. Understanding this distinction is critical when scoping PCI DSS assessments, selecting data retention policies, and evaluating the actual fraud risk posed by a database exposure.
| Attribute | Primary Account Number (PAN) | Payment Token |
|---|---|---|
| Contains real account data | Yes | No |
| PCI DSS in-scope | Always | Conditionally (depends on token type and vault access) |
| Usable if stolen | Yes — enables CNP fraud | No — valueless without vault credentials |
| Issued by | Card network / issuing bank | Token service provider (TSP) or gateway |
| Format | 8–19 numeric digits | Typically matches PAN format |
| Can be reversed to original value | N/A — it is the source | Yes — by authorized TSP only |
| Merchant database risk | High | Low |
| Supports recurring billing | Yes | Yes — preferred method |
| Bound to specific merchant/device | No | Yes (network tokens) |
Network tokens issued by Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES) go a step further than gateway tokens: they bind the surrogate value to a specific merchant, device, or channel. A token extracted from one merchant system cannot be replayed at another, adding a structural fraud defense that raw PANs can never provide.
Types of Primary Account Number (PAN)
PANs are not a single homogenous category. Different card products and use cases generate different PAN types, each with distinct authorization flows, regulatory obligations, and security handling requirements.
Credit card PANs are the most common form in consumer payments, tied to a revolving credit line. They follow the full ISO 7812 structure and are subject to the complete range of PCI DSS Requirement 3 controls for stored data.
Debit card PANs are structurally identical to credit card PANs but link directly to a demand deposit account. They can route through PIN debit networks (Interac, STAR, NYCE) in addition to the major card networks, and carry additional regulatory exposure under Regulation E in the United States, which governs error resolution timelines and liability caps for unauthorized transactions.
Prepaid card PANs are issued against a preloaded balance rather than a credit line or bank account. They are widely used for payroll disbursement, travel cards, and consumer gift cards. Many prepaid programs issue standard 16-digit PANs that are indistinguishable from credit cards at the point of sale, creating the same PCI DSS obligations for merchants regardless of the underlying funding mechanism.
Virtual card PANs are single-use or restricted-use PANs generated programmatically, primarily in B2B payments and corporate purchasing programs. They can be locked to a specific merchant, transaction amount, or date range — a capability that substantially reduces fraud exposure for accounts payable automation.
FPAN vs. DPAN: A Funding PAN (FPAN) is the physical card number associated with the underlying account. A Device PAN (DPAN) is a device-specific token issued by Apple Pay, Google Pay, or Samsung Pay when a card is provisioned to a digital wallet. DPANs are network tokens that replace the FPAN in contactless NFC transactions, ensuring the cardholder's real account number never leaves the issuer's infrastructure during mobile or wearable payments.
Best Practices
Handling PANs incorrectly remains one of the most common causes of PCI DSS scope expansion and direct breach liability. The guidance below is split by role because the failure modes differ significantly between operational and technical teams.
For Merchants
- Never store the full PAN after authorization unless a documented business necessity exists — for example, certain chargeback dispute processes that require raw card data. Even in those cases, AES-256 encryption with a formal key management policy is mandatory.
- Display only truncated PANs across all customer-facing surfaces, receipt systems, and support interfaces. Last four digits is the standard; showing first six plus last four is permitted for BIN identification purposes only.
- Replace PANs with tokens for all card-on-file use cases. Recurring billing, subscriptions, and split shipment charges should always reference a token, not a stored PAN. Most acquirers and payment gateways provide this capability at no incremental cost.
- Restrict PAN access to the minimum necessary systems and personnel. Implement role-based access controls with audit logging on every access to cardholder data environments — this is a direct PCI DSS Requirement 7 and 10 obligation.
- Regularly inspect physical POS hardware for signs of tampering. Card skimming devices placed over legitimate terminals are a persistent vector for bulk PAN theft at brick-and-mortar locations and fuel pumps.
For Developers
- Use hosted payment fields or iframes so the PAN is submitted directly from the browser to your PSP — never touching your application servers. This is the most impactful single architectural decision available for reducing PCI DSS scope in web integrations.
- Implement automated PAN scrubbing in your logging pipeline. A Luhn-validated regex applied at the log sink will detect and mask card-format strings before they are written to any storage or monitoring system. This prevents PAN leakage via error messages, stack traces, and verbose debug output.
- Never include PANs in URL parameters, query strings, or HTTP GET requests. These are logged by every reverse proxy, CDN edge node, and browser history layer in the request path — surfaces that are rarely included in PCI DSS assessment scope but are frequently accessible to breach actors.
- Implement P2PE or E2EE at the terminal layer so PANs are encrypted before leaving the card reader. This ensures the PAN never appears in plaintext anywhere on your internal network during card-present transactions.
- Use the card-verification-value (CVV) only at the moment of authorization. PCI DSS explicitly prohibits storing CVV after an authorization response is received. A system that retains both a stored PAN and a stored CVV represents maximum fraud exposure and is among the most severe PCI DSS violations.
Common Mistakes
Even teams with mature security postures regularly make PAN-handling errors that silently expand compliance scope and breach exposure over time.
1. Logging raw PANs in application output. Developers frequently add verbose logging during integration development and neglect to remove it before production deployment. A single log line containing a full PAN constitutes a PCI DSS violation, and in aggregate — across high-traffic systems — can expose millions of card numbers if logs are misconfigured for external access or centralized in a monitoring platform outside the cardholder data environment.
2. Storing PANs in analytics or CRM systems. Order management platforms, marketing CRMs, and customer data warehouses often capture form submission payloads indiscriminately. Without explicit field exclusion, iframe isolation, or tokenization at capture, PANs can silently populate systems that have broad internal user access and are rarely assessed for PCI DSS compliance, dramatically expanding the in-scope environment at assessment time.
3. Confusing display-layer truncation with storage-layer protection. Showing •••• •••• •••• 4242 on a receipt does not mean the full PAN is protected in the database. Truncation is a presentation control only. The underlying stored value must independently be either truncated, irreversibly hashed, or encrypted — and auditors will verify both the display and the storage record separately.
4. Skipping PAN format validation on input. Failing to run a Luhn check and digit-length validation at form submission allows malformed data — and occasionally injection payloads — into the payment processing flow. A Luhn validation rejects the majority of mis-keyed card numbers before they ever reach the processor, reducing decline rates and easing debugging of integration issues.
5. Transmitting PANs inside webhook and callback payloads. Legacy integration patterns from early payment API design sometimes include raw PANs in server-to-server callback bodies sent to merchant back-ends. This creates uncontrolled PAN distribution across systems that were never designed to handle cardholder data. All modern integrations should transmit only tokenized card references in any webhook, IPN, or callback message — never a live PAN.
Primary Account Number (PAN) and Tagada
Tagada's payment orchestration layer is specifically designed to keep raw PANs out of merchant infrastructure. The platform receives tokenized card references from connected payment service providers and routes transactions using those tokens — no live PAN ever transits the Tagada API in a correctly configured integration.
Zero-PAN Merchant Architecture with Tagada
When a PSP is connected through Tagada, card tokenization occurs at the PSP layer before the transaction reference enters Tagada's routing engine. Your integration inherits the PSP's PCI DSS compliance posture for PAN storage and transmission, while Tagada handles orchestration logic exclusively with tokenized data. The practical result is a merchant environment where a full PAN may never appear in your logs, application database, or server memory at all — a significant reduction in both compliance scope and breach risk surface.
This architecture also enables concrete business outcomes beyond compliance. Merchants routing through Tagada can instruct the platform to prefer network-token transactions — Apple Pay, Google Pay, and other DPAN-based flows — over manually keyed FPANs. Network-tokenized transactions typically receive improved authorization rates from issuers, who treat device-bound tokens as a stronger authentication signal than a raw card number entered by a human. For high-volume e-commerce merchants, that authorization rate uplift translates directly into recovered revenue on every billing cycle.