It was curious because it seemed to solve a problem that was already being solved by other players in the card industry. Make no mistake, however: the problem is a big one. Here’s what I mean.

I’ve written extensively about how Payment Cards implement the “pull model”. When you want to pay for something, you hand over your card details to the merchant and then hope that those details don’t get into the wrong hands as they pass from merchant to their acquirer to the switch and finally to the bank that issued the card in the first place.

In particular, the big problem is what happens when companies with millions of cards on file get hacked. Think of major online retailers who save your card details for you. It’s very convenient for you but it only works because they’ve stored your card details on their servers. If they get hacked, then millions of people are at risk of theft and card issuers will have to reissue millions of new cards. It’s a huge pain.

When you allow a merchant to keep your card details on file, you have to trust all the actors in the blue oval not to mess up…

However, there’s a really cool thing you can do to make this system much safer. It’s called tokenization. Here’s the idea:

When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.

Instead, they send the details to their merchant acquirer – e.g. Elavon – and ask them to issue a token.

The acquirer creates a random number that might look like a credit card number in some cases – the token – and returns it to the merchant.

The acquirer records all this information in its own database (i.e. the real card details, the token they issued and which merchant they issued the token to, etc).

The merchant stores only the token in their database, not the real card number.

Now, next time you try to buy something from that merchant, they send the token they’ve stored to the acquirer. The acquirer checks that the token is valid and that it came from the right merchant. And, if so, they convert it back to the real card number and process the transaction as normal.

The really important point here is that we no longer really care as much about the merchant’s security. If they get hacked, it’s not as much of a problem: the tokens are useless to anybody else. The acquirer will only accept them if they’re presented by the original merchant. If the hacker tries to use them somewhere else, they simply won’t work.

Excellent! A really simple system that dramatically reduces the risk of fraud and lowers risk and cost for merchants. You can think of it as if the “circle of trust” has been shrunk:

If merchants use tokenization services, the implications if they get hacked are far less serious. (TSP stands for “Token Service Provider”)

And this is nothing new. Acquirers have offered this service for ages for merchants who wanted to use it.

Great. Problem solved?

Not so quick….

Now think about Apple Pay and think about the challenges Apple faced in getting this to work.

Here’s how contactless payments are supposed to work when you pay for goods in store: the cashier rings up the price and activates the contactless pad so you can pay. You tap your contactless card and you’re done. This piece is completely normal: anybody with a contactless (“PayWave” or “PayPass”) card can do that today. It’s what I’ve done with the PayTag on my iPhone 4 for ages.

But how do you get a phone to pretend to be a contactless card? Well that’s a solved problem too. Android devices have done it in various ways for years, for example.

So what’s the problem? The answer is: security. Sure… you can put somebody’s card details into the “Secure Element” of a phone (or do something clever with Host Card Emulation) but if you’re putting the real card number in there then you face all the same risks a merchant faces… if somebody were to figure out how to hack into your system, you’ve got a big problem on your hands… And in Apple’s case, imagine if almost 1 billion payment cards were compromised!

So it would be much safer if you stored a token on the phone, rather than the card details themselves. That way, if the system is broken, you can just invalidate all the Apple tokens and you’re done.

But there’s a really subtle problem

How does a firm like Apple get the tokens? Remember: they want to emulate a contactless card so that the customer can use the phone to pay at a merchant. You don’t know which merchant acquirer any given merchant uses so an acquirer-specific token is useless!

So Apple can’t use the merchant acquirer services to get its tokens… imagine it put a First Data token on its phones. What happens if you try to pay for something at a merchant who uses Elavon? It isn’t going to work…

And this is where the EMVCo spec comes in. In short, the EMVCo spec proposes is that tokenization be standardized and it implies strongly that it should be the schemes (or maybe issuers) who perform the work, not the acquirers.

Effectively, they’re proposing the circle of trust be tightened even further:

I scratched my head at first… apart from perhaps being a power grab, why would anybody bother change this simple model?

The answer was on page 26, section 3.8 and the introduction of the idea of a “token requestor”. What the EMVCo spec highlighted – and what I missed at the time – was that it isn’t only merchants who might want to create tokens… other players might need to as well… players like telcos and Apple:

Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers.

You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services. Indeed, Visa Inc have written about their service here.

And so I think that’s what’s going on. Apple is acting as a “Token Requestor” in the EMVCo model. When you enter your card details or take a picture of your card with your iPhone 6, Apple will call the Token Service for the appropriate network – let’s assume Visa. Visa will check the details (maybe your postal code, CVV2, etc) and perhaps authorize with the issuer.

And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem. But it will look just like an ordinary card number so acquirers will be able to process it without even realizing it’s a token.

And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it. So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.

In summary, my take on the interesting aspects of the Apple Pay announcement are:

It’s looks like a really nice use of the EMVCo “Token Requestor” concept

It relies on schemes having Token Service Providers up and running so don’t expect it to roll out everywhere, for all schemes, any time soon.

It’s surprisingly vanilla.

It’s conceivable that Apple is taking zero cut from any of this. They’re certainly not in the transaction flow in any meaningful way

But notice how much leverage it gives them over issuers. It would be easy to refuse to include an issuer’s cards on the platform unless the issuer pays up. That has the interesting property that deals could be done on a case-by-case basis and different issuers may have different deals.

This is, of course, just my analysis from public information. I have no inside knowledge and I could be completely wrong. In particular, I’m struggling to reconcile my analysis with some claims that Apple Pay will use a different token for every purchase. I don’t understand how that would work, unless we assume the phone is online at point of purchase? Anybody know for sure? Am I way off the mark?