How is a card number structured?
Under the ISO/IEC 7812 standard, the PAN is made up of the issuer identification number, an individual account identifier and a check digit, with a maximum length of 19 digits. The issuer identification number, the BIN, used to be six digits and moved to eight digits in the 2017 revision of the standard. The last digit is calculated with the Luhn algorithm, which lets a checkout catch most typing errors before the number is sent.
Why does it matter?
The PAN is what fraudsters want and what security rules are built around. Anyone who stores, processes or transmits it falls under PCI DSS, and the cost of compliance grows with every system that touches it. As an illustrative example: a store that receives card numbers on its own servers has its web servers, databases, logs and backups in PCI scope. If customers enter cards in a provider’s hosted checkout and the store only receives tokens, most of those systems leave scope.
How should a PAN be handled?
As little as possible. Keep it out of logs, emails and support tickets, mask it on screens to the minimum digits a task needs, and replace it with a token wherever a reference is enough. The BIN and the last four digits are usually all that support, routing and reporting need.
Where does Omno use it?
Customers enter card numbers in Omno’s hosted checkout or in Card Fields on the merchant’s own checkout, and card data goes to Omno’s PCI DSS compliant environment, so the merchant’s systems receive tokens and transaction details instead of PANs. Card attributes such as the BIN and issuing country can be used in routing rules, and saved cards are stored as tokens at the platform level.