PAN (Primary Account Number)

The primary account number, or PAN, is the long number printed on a payment card. It is what the card networks read to work out which bank issued the card and which account to charge. Most run to 16 digits. American Express uses 15, and a few card types run to 19. None of it is random, and each block of digits has a job to do. Reading the number in blocks is a quick way to see how a card payment finds its way home.

That same structure is why the PAN carries so much weight in security rules. It is the one field that, on its own, points at a real account at a real bank, so a copy of it is worth money to a thief the moment it is taken. The card industry treats it as the core of what it calls cardholder data. The PCI Security Standards Council document library sets out the current rules for handling it. A good deal of payment security exists to keep this one number out of places it has no business being.

Reading The Number In Blocks

The first digit marks the industry, which is why Visa cards begin with 4 and Mastercard with 5 or 2. The first six to eight digits form the issuer range, better known as the BIN range. That range tells a network which bank to send the request to, and it is also the basis of BIN routing. The digits after it point to the account. The last digit is a check digit worked out with the Luhn formula, and it catches most typing errors before a request ever leaves the page.

What The Issuer Range Gives A Merchant

More than teams tend to expect. The range shows the country, the card brand, the product type, and whether the card is debit, credit or prepaid. All four of those have a price attached. Fees differ by product, approval odds differ by country, and some features only work on some card types. A shop that reads the range at checkout can change what it offers before the shopper commits, and can spot a card outside its usual mix early enough to do something useful about it.

The Case For Not Holding It

Keeping card numbers on your own systems drags a lot of kit into scope for a security audit, and the audit is usually the bigger cost. So the habit has moved. A payment token stands in for the number, and the real value sits with a provider set up to hold it. tokenisation at the shop level covers one business. A network token goes further, because the card networks keep it current when the card behind it is reissued after a loss.

Virtual Numbers Behave The Same Way

A virtual card number can be issued for one supplier, one amount or one short window, which caps what a leak is worth, and a Visa account number works in much the same space. Both look like an ordinary PAN in the payment message and sit under the same handling rules, so treating them as a lighter field is the kind of mistake that only shows up during an audit.

Masking, And Where Full Numbers Escape

Showing the last four digits is normal practice, and it is what lets a customer tell one saved card from another. Where a full number has to appear, such as in a dispute file, it belongs somewhere locked down with a record of who looked. The awkward truth is that card numbers seldom escape through the payment system itself. They escape through a debug log written during an incident, a CSV export nobody scoped, a screenshot pasted into a support ticket, or an email sent by someone trying to be helpful.

Chip And Wallet Payments Do Not Expose It

A chip card does not simply hand the number over. The EMV chip rules wrap the PAN in a code unique to that one payment, so a copied message will not work at another terminal. Tap and phone wallets go further again, presenting a device token in place of the number, and the token is useless anywhere else. The terminal still needs the issuer range to route the request. That is why the first digits travel in clear while the rest do not, and why a shop can read the card type without ever seeing the account.

Three Mistakes Worth Designing Out

Logging the full number while debugging is one of the common ones. That log store then sits well outside the scope everyone agreed six months earlier. Emailing a number to settle a query moves the risk into an inbox someone else will search two years later. Treating a token as though it were a card number in reports breaks matching the moment a second provider is added, because tokens are tied to the provider that issued them. A payment gateway that takes card data in a hosted field is designed to help keep all three out of the business.

Where To Put The Effort

Decide early whether the business needs to touch a card number at all. The answer is usually no, and bolting it on later is costly. Use hosted fields and tokens from the first build. Keep the issuer range, which is useful for routing and carries none of the same risk. Watch the places numbers leak, not the places they are stored. And pair all of this with monitoring, since a leaked number tends to show up as a run of odd payment attempts days before it shows up as a loss. Tools such as payment fraud detection are designed to help spot that pattern, and this piece on the benefits of tokenisation covers the wider move away from stored numbers.

‍