I very rarely talk about payments on this blog, but every once in a while I get to talk about something I think might be interesting: network tokens!

Who has my card number?

Many years ago, merchants selling products online and in person were handling your card details directly. That meant that if they didn't know what they were doing, they could leak your raw 16-digit card number, expiration date, and cvv. If you've got all three of those, you can run a transaction on that card basically anywhere in the world.

However, over the past decade or more, e-commerce payment collection has changed to a system where the merchant never sees the card data at all. The next time you're on a website entering your card number, right-click and inspect the text fields for the card data and you're almost certainly going to see that is actually a text field served inside an iframe hosted by a big name in payments that you've heard of. In the modern world, merchants don't want your card number, they never want to see it, it's just a liability for them. Even in a "save my card for later" situation, the payment provider holds onto the card data and gives the merchant a token that they can use to charge that card again. When the merchant wants to charge that customer again, they make an authenticated payment request with that unique token and the payment provider sends the raw card to the payment processor in the background.

Digital wallets like Apple Pay and Google Pay have added even more security in the flow by never transmitting the raw card data at all. Instead, they transfer an encrypted blob of data, that data is decrypted by the payment provider, and then a DPAN is sent to the processor. We're into the weeds here, but a DPAN is different from the FPAN that you see on your physical card, so you can read more about the differences between the two in this post I wrote last year. The super short version is that if someone steals your FPAN data (aka the numbers and expiration date on your physical card) they can attempt real transactions on basically any checkout page on the internet. If they steal your DPAN or the encrypted data straight from the digital wallet, it's effectively useless since they don't have the proper keys to do anything with that data. I'm omitting a lot of details here, but you'll forgive me for not wanting this post to be 10,000 words long, so just now that's the gist. In recent years, the major card brands have teamed up to make a Click to Pay button that works similarly to Apple and Google Pay, but that is cross-platform and is not tied to a third party like Apple or Google, it's managed directly by your card issuer.

But anyway, unless you're using a digital wallet today, all the card data is stored with the payment provider. If the merchant has a data leak, there should be no issue since they never had your card number in the first place, but if the payment provider has a data leak, the attackers will have raw card data (number and expiration, but not CVV since the CVV is only stored long enough to send it to the processor before being deleted). Thankfully this very rarely happens, but it can theoretically happen (it's also why payment companies pay so much for security to make sure it never does).

Network tokens

Network tokens aim to make the sort of security that you get from Apple/Google Pay buttons and make that standard across the industry. We're in the middle of a transition period as we move to this system across the board, but it's quickly becoming widely adopted and the major card brands like Visa and Mastercard have signaled that they intend to remove the raw FPAN data entirely from the transaction flow by 2030, with earlier dates set across the world. As always, the US will likely be slower to adopt this, and places like Europe, Asia, and Latin America are ramping up quicker.

The ideal network token flow is very similar to what I described in the Apple and Google Pay section, but the gist is that while the customer will still key in/autofill their FPAN into a form on the web, ideally that form will keep the number in memory just long enough to see if they have a network token already on file for that card, and if not requesting one from the card brand, and then deleting the FPAN once they have the network token. When the transaction is submitted, a one-time-use cryptogram is generated that is unique to that merchant and that transaction, and is submitted to the processor with the token and all other payment data (amount, name, products, address, etc.). In the event a customer uses Click to Pay or Apple/Google Pay, they never even key in the FPAN, meaning a token is the only thing passed back and forth, which is even better.

To put this very simply, let's say your physical card has "4111111111111111" printed on it, and that's what you key into the checkout page. The network token for that will be something like "4482966703373579". That network token means nothing to you the customer, but your bank knows that number is associated with your "4111111111111111" account. However, it won't just accept any old payment request to the token value, it requires a highly secure cryptogram to be generated using a secret key associated with that merchant to actually run a payment.

The effect here on security is pretty clear and pretty good for everyone involved. The customer keys in or autofills their card number that they're familiar with and is what is shown on their physical card, the merchant never sees that number at all due to modern card collection technology, and the payment provider (gateway) tosses the FPAN as soon as it has a network token, meaning the only participants in the payment flow who retain the actual account number are the customer and the card issuer. This reduces the risk for everyone by making it so as few people as possible have actual account data.

The great thing here is that network tokens don't remove any of the other highly secure payment methods that already exist. Apple and Google Pay will continue to work just as they always have and card present EMV (tap and dip) keep using their existing security systems.

My job has me regularly talking with the card brands, and it's clear from our discussions that they are intent on getting the raw card data out of the transaction flow entirely. In fact, they're really pushing for people to use their Click to Pay button or Apple/Google/Shop/Samsung Pay buttons, and make customers keying in their actual card number into a website a thing of the past.

So there you go, 1,000 words on a detail of how payments are handled and how things are changing in the background in a way you likely would never have even noticed. I'm writing about this largely for my Apple-centric audience and in my ongoing fight against the "only Apple does this" mythology that I think has a tendency to build up as we tend to only pay attention to what Apple is doing in payments, assuming the rest of the industry is standing still. As I always say, Apple does amazing work in payments and they're worthy of praise for numerous innovations along the way, but they're not the only ones doing good work.