What’s the difference between standard tokens and network tokens? Who owns the data stored through tokenization? And what are the implications of storing card data directly instead of using tokenization?
Customer data protection is a critical part of offering payments, and we’re often asked four common questions from partners and their merchants looking to understand their responsibilities. In this article, we answer those key questions about different token types, data ownership and the true compliance costs of storing card data.
Question: What Is the Difference Between Standard Tokenization and Network Tokenization?
Answer: The difference between standard tokenization and network tokenization primarily comes down to who issues and manages the tokens.
Tokens are randomly generated strings of numbers that replace the primary account number (PAN) on a customer’s credit card. The token is stored for the merchant’s future use in a token vault. Meanwhile, the associated PAN is kept safely hidden away by the token provider. With network tokens, this keeps the PAN completely separate from active transaction processing and protects both the merchant and the customer from data breaches.
Standard tokens, also known as gateway tokens or processor tokens, are issued and managed by the customer’s payment service provider.
Network tokens are issued directly by the network that issued the card, like Visa or Mastercard.
Both accomplish the same goal, and both offer advanced security. However, network tokens are generally considered more secure because the token itself is used in the transaction authorization process, whereas gateway tokens continue to use the underlying PAN. Because of this, network tokens offer additional benefits like improved portability, lower fraud rates and potentially lower interchange rates.
Question: Who Owns the Customer Data That I Store Through Tokenization?
Answer: Any time customer data is in play, it’s always best to think of the customer as the ultimate owner and to treat it accordingly. With that being said, in a tokenization arrangement, the tokens themselves are owned and managed by the provider. For example, a network token issued for a Visa card will ultimately be owned by Visa. Visa maintains a secure repository of all its tokens and the data they correspond to. They can also issue and revoke network tokens as needed.
After initial authorization and issuance, merchants can use a token to process additional or recurring transactions, but they don’t own it (and neither do the independent sales organizations or software platforms reselling payments).
Merchants looking to own lists of their own customer card data would need to store PANs themselves. But PAN storage is a high-risk activity that very few merchants are equipped for, and it significantly increases the complexity of PCI compliance. More importantly, there is no real reason a merchant would need a list of its customers’ PANs, so there is no upside to storing card numbers directly instead of accessing repeat payments through tokenization.
Question: What Are the PCI Compliance Implications of Storing Payment Data?
Answer: The more customer payment data a merchant stores, the heavier their PCI compliance burden becomes. That makes storing card data directly too complex and far too costly for the vast majority of merchants.
First and foremost, there is some information that can never be stored, known as sensitive authentication data (SAD). SAD includes customer Personal Identification Numbers (PINs), card verification codes and the complete data stored on a card’s mag stripe or chip, known as “full track data.” Storing any SAD immediately puts the storing party in breach of the PCI Data Security Standard (DSS) and exposes them to significant penalties and liability.
Storing cardholder data (CHD) is allowed, but significantly increases compliance scope, complexity and cost. The primary account number (PAN) is the most sensitive piece of the CHD puzzle, and storing it takes an average merchant from low scope and limited burden to full PCI DSS scope, which requires:
- Hundreds of controls across all 12 key requirement areas of PCI-DSS 4.0
- Thorough digital and on-site physical security protocols
- Increased scanning requirements using Approved Scanning Vendors (ASVs)
- Full compliance reports issued by PCI-DSS-approved Qualified Security Assessors (QSAs)
In contrast, a merchant using network tokenization shifts almost all of that burden to the card network issuing and managing the tokens. The merchant still has compliance responsibilities, but they’re much simpler, often requiring no more than an annual self-assessment questionnaire.
Tokenization isn’t just a security measure — it’s a foundational part of managing customer payment data in a compliant, easily scalable way. At NMI, we offer both network and gateway tokenization to ensure all of our partners and their merchants have access to the ideal data security solutions for their needs. If you have more questions about data storage, security or management, reach out to a member of our team.