A simple explanation of how Apple Pay works (probably): It’s all about tokenization

Forget contactless point-of-payment… that’s a solved problem. Apple’s use of tokenization is the interesting part

[USUAL DISCLAIMER: I have no inside info, these are personal views]

I’ve been using a beta version of ApplePay on my iPhone 4 for some time now…

ApplePayBeta

My very old, but very effective, Barclaycard contactless PayTag, stuck to my iPhone 4

The interesting question is how Apple chose to embed the card details inside the phone

To understand why, we have to rewind to March, when something curious happened: a body called “EMVCo” released a technical specification document for something called “tokenization”.

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.

PushPull

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.

PushPull2

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:

PushPull3

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:

PushPull4

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:

“Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to Card-on-file Merchants, Acquirers, Acquirer Processors, and payment gateways on behalf of Merchants, Payment enablers, such as original equipment manufacturer (OEM) device manufacturers, Digital wallet providers, Card Issuers”

(EMVCo Tokenisation Spec, page 26-27, my emphasis)

Of course!

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?

A simple explanation of fees in the payment card industry

I wrote a piece last month explaining how the payment card industry works.  I talked about the various actors (acquirers, issuers, schemes, merchants, etc) and pointed out how weird it is that everybody knows the Mastercard and Visa brand names yet nobody actually has a relationship with them. One of the questions I didn’t address there was fees.  Who makes all the money? Why does it seem so expensive?

Let’s start with the standard four-party model: Merchants, Acquirers, Issuers and Schemes:

Four Party Model Fees 1

The four-party model: Merchants obtain card processing services from Acquirers, who route transactions via Schemes to Issuers, who debit Consumers’ accounts.

A Worked Example

The key point is that one firm from each category is going to be involved in every payment card transaction.  So it’s interesting to ask: how much do they get paid?

Let’s take a concrete example and work it through.  Bear in mind: this is just an example. As you’ll see, there are almost infinite variations and some merchants will pay fees considerably higher than the ones I discuss below.  Also, note: this information all comes from public sources.  I use company names below for clarity but I have no private insight or information into their fee structures

The Scenario

Let’s imagine I’m using a Visa Debit card, issued by a US bank (let’s say Bank of America) to buy $100 of goods from an online retailer.   What happens?  From my perspective, of course, it’s obvious: I’m paying $100!

Four Party Model Fees 2

Imagine I am using my Visa Debit Card, issued by Bank of America to pay for $100 goods from an online retailer.

The Merchant’s Perspective: The Merchant Discount Fee

What does the merchant see?  Well, the merchant will have a contract with an acquirer.  What does that look like?  Let’s take an example.  Costco have a page on their website that refers small merchants to Elavon for acquiring services.  Let’s use the pricing displayed on that page for Online transactions:

1.99% plus 25c per transaction (plus some other recurring/monthly fees, etc)

Many readers will be thinking that seems low but let’s go with it for now.

So, for our $100 transaction, we can calculate how much money the merchant will actually receive from Elavon/Costco:

  • Transaction value: $100
  • Elavon/Costco takes 1.99% + 25c = $2.24. This is often called the “merchant discount fee
  • So merchant gets $97.76

So our picture now looks like the one below:

Four Party Model Fees 3

Merchant receives $97.76 from the $100 transaction. Elavon gets $2.24.  But how is the $2.24 distributed between the acquirer, issuer and scheme?

The Issuer’s Perspective: The Interchange Fee

So we know how much money the merchant has paid to the “credit card industry”. But how is that money allocated between all the participants?   Visa Inc has a very helpful document on their website, which tells us part of the story: Visa U.S.A. Interchange Reimbursement Fees.

The key word here is “Interchange”.  Interchange is the fee that gets paid to whoever issued the card – and it’s set by the scheme (Visa in this case).   You’ll see in that document that this is not straightforward… there are pages and pages of rates:  the interchange fees vary based on whether the card was present or not – and on the type of good or service being bought, whether it was a debit or credit card, whether it was a corporate card, whether it was an international transaction and lots of other criteria…

So let’s just pick a simple example.  We’ll go with page 2 – “CPS/e-Commerce Basic, Debit” (Card not present).

Aside: CPS means that the merchant has complied with various Visa rules (such as validating customer address to reduce fraud risk, etc) and has thus qualified for a low cost option.  

So the issuer is entitled to 1.65% + 15c

  • Transaction value: $100
  • Issuer receives 1.65% + 15c = $1.80.  This is the interchange fee
  • So issuer owes $98.20 to the other participants (Visa, Elavon and the Merchant)

And we already know that the merchant only gets $97.76 of that money (their merchant discount fee was $2.24, remember?).  So that means there is 44c left to share between Visa and Elavon.

The diagram below shows the current state of the calculation:

Four Party Model Fees 4

Interchange Fee (what the issuer gets) is $1.80

So how is the remaining 44c allocated?

We’ve assumed the switch is Visa so we need to know much they charge.  CardFellow.com has a good explanation.

We’ve assumed a Visa Debit card so, according to that site, Visa’s fee, which we call the “Assessment” is 0.11%.   There is a menu of other charges that might apply but we’ve assumed this is a low-risk “CPS” transaction so we’ll assume none of them apply.  (In reality, the 1.55c “Acquirer Processing Fee” probably applies)

  • Transaction value: $100
  • Visa assessment is 0.11% so Visa charges 11c. 
  • So there is $98.09 to pass on to the acquirer.

And if there is $98.09 to pass on to the acquirer and we know that the merchant receives $97.76, that must mean there is 33c left for Elavon.

So there we have it… in this VERY SIMPLE, highly contrived – and probably unrepresentative – example, we end up with the result in the diagram below:

  • Consumer pays $100
  • Issuer receives $1.80
  • Visa receives $0.11
  • Acquirer receives $0.33
  • Merchant receives $97.76 – overall fee $2.24

Four Party Model Fees 6

Final picture showing how the merchant’s $2.24 fee is allocated

As I’ve stressed above, this is just a simple example but it shows two key points:

1) It is the issuer who receives the bulk of the fees (this is, in part, how they fund their loyalty schemes, etc)

2) The schemes actually earn the least, per transaction, of any of the participants.  This underlines, again, how powerful their business model is:  by being at the centre of a very sticky network, they can earn a lot of money overall by charging very low per-transaction fees.   [Edit 2013-08-10 10:35 : it’s also worth noting that the acquirers and schemes have pretty much fixed-cost infrastructures – unlike issuers, who need to hire customer service and debt collection staff in proportion to number of cards issued. So the schemes and acquirers also benefit disproportionately from rising volumes.  So: low fees for schemes/acquirers for sure… but HUGE volume is what enables them to make big profits]

[Note: I use blog posts like this to help clarify my own thinking and understanding – as well as to share knowledge…  and there are one or two pieces here where I’m not 100% confident I got it totally correct… so please do tell me where I’m wrong if you spot something]

[Update 2014-08-09 18:47 Minor typos and replaced last diagram]

Why the payment card system works the way it does – and why Bitcoin isn’t going to replace it any time soon

The Payment Card Industry’s weird business model is a work of genius

Regular readers will know that I am extremely optimistic about the long-term potential of Bitcoin and cryptocurrency technology to revolutionise the financial system. But that doesn’t mean I think they will overturn all aspects of the system.

In particular, I am skeptical of claims that Bitcoin will have a meaningful impact on retail payments and break the stranglehold of the payment card companies.

Of course, many people disagree with me. Articles such as this one from last year are typical of the genre: “credit card companies” are accused of charging obscenely high fees, hindering innovation and being ripe for disruption.

IMG_1600

Payment Cards fees might seem expensive but does it mean they are vulnerable to disruption?

Now, it’s true that the fees do seem expensive at first glance but, as David Evans has argued, it’s not obvious that the Bitcoin payment processors are really that much cheaper, once you take into account their spreads and the costs of getting into and out of Bitcoin at each end.

But the main reason I think the incumbents are in such a strong position is because the industry has extremely strong network effects, which leads to formidable barriers to entry. Would-be Bitcoin entrepreneurs need to understand this structure if they are to succeed.

The Payment Card Industry is marvellous and weird at the same time

When you step back and think about it, the modern payment card industry is a marvel – an underappreciated, underrated miracle of contemporary commerce: you can travel to any corner of the earth, armed only with a piece of plastic bearing the Visa or Mastercard logo. It’s a minor miracle.

But when you look at the businesses of the major card brands, they turn out to be really, really strange companies. They simply don’t do what most of us think they do.

Take a card out of your pocket… chances are, it will be a Visa or Mastercard, or maybe UnionPay if you’re one of my Chinese readers. Let’s assume it’s a Visa card for now. And we’ll worry about American Express later, because they’re different to all the rest.

Here’s one of my Visa cards again:

IMG_1600

A Visa debit card, issued by first direct bank.

Notice something strange. There are two brands on the card. There is the Visa logo and there is one for first direct, the division of HSBC with whom I hold my current account.   Most other consumer products don’t have two firms’ logos on them. Something strange is going on.

Now, it it was first direct that issued the card to me, not Visa.

It is first direct’s website I visit to see my balance, not Visa’s

And it’s first direct I would call if something went wrong, not Visa.

I don’t have any relationship with Visa at all.

There’s no Visa call centre I can call if I have a problem with my card and there’s no Visa app on my phone.  This is strange: a hugely powerful global brand and yet the billions of consumers who use it don’t have a relationship with them.

It gets stranger. Another little-known fact is that no retailer anywhere in the world has a relationship with Visa either!  So we have one of the world’s most recognizable brands and nobody who uses their “product” has any relationship with them.

It’s worth thinking through why this might be and why it is such a powerful model.

How would you build a credit card system if you were doing it from scratch?

Imagine you run a bank in a world before credit cards.   Wouldn’t it be great if your customers could go to local shops and “charge” their purchases to an account that you hold for them?   You could make money offering credit to the customers and make some more money charging the merchants for providing this service.

This is what Bank of America did in California in the 1950s. They issued credit cards to lots of their customers in various cities and signed up local retailers to accept them. Great – the payment card industry was born! You could think of the model looking something like this:

Cards Picture 1

A simple card scheme: a bank issues cards to its customers and reimburses local merchants who accept those cards

But this model has two really unfortunate problems:

  • Your competitors are going to copy this and you’ll soon have schemes like this popping up all over the country, all run by different banks, on different systems, racing to sign up consumers and merchants onto their product
  • Your customers will travel. And they will be very upset when they discover they can’t use your card in a merchant who only takes a different bank’s cards

You would end up with the situation in the diagram below: a merchant who banked with Bank B wouldn’t accept cards issued by Bank A. Why would they? They had no relationship with Bank A and who’s to say cards from Bank A would even work with their machines?!

Cards Picture 2

Why would cards issued by Bank A be accepted by a merchant who uses Bank B if Bank A and Bank B operate competing schemes?

If you were running one of the banks, how might you respond to this problem?

One answer might be to view this as an arms race: perhaps the best strategy is for banks to enter an all-out war… sign up as many merchants as they can… sign up as many customers as they can and bet that you’ll be the last firm standing when the industry shakes out. Obvious problem: it would be ruinously expensive and what happens if it ends in stalemate? You still have the same problem.

But there’s another option… what if you cut deals with other banks: agree for them to accept your cards at their merchants in exchange for you accepting their cards at your merchants. This sounds quite promising but… obvious problem: how on earth would the merchant handle this? They’d need a huge book by every till that listed precisely which banks they could accept card payments from and which ones weren’t allowed. It would be chaos… But perhaps it points the way

A flash of insight – who are you really competing with?

Let’s recap: you’re a bank executive trying to build a payment card business. But your competitors are all trying to do the same and it’s going to end in tears: you’ll confuse the merchants with hundreds of different card types or you’ll go bankrupt trying to be “last man standing”.

It feels like having other banks accept your cards at their merchants would be good… but how to make it work?

And this is where a flash of insight changed the world.

Somebody realized that the cards “business” was actually two businesses.

The first business is all about offering credit to your customers, managing their accounts and processing their payments. We could call this card issuing.

And the second business is all about enabling merchants to accept card payments and get reimbursed. We could call this merchant acquiring.


 

Aside: we call it “acquiring” because it’s helpful to model the card payment as a receivable that the processor purchases (acquires) from the merchant at a small discount, which you can think of as the processing fee.


This is the key point: issuing and acquiring are totally different businesses which don’t compete with each other.

Sure… all the issuers compete with each other.

And all the acquirers compete with each other.

But the issuers don’t compete with the acquirers.

Indeed, they have a really strong incentive to co-operate… the issuers want all the acquirers to accept their cards… and the acquirers want to offer their merchants the ability to accept as many cards as possible.

So let’s imagine a group of issuers teamed up with a group of acquirers. And imagine they agreed that the acquirers would all process the cards of all the issuers in the group: every issuer’s card would be accepted by every acquirer.   They could use this forum to hammer out some standards: they would agree a common way to process cards, timescales for reimbursement, rules for what happens if something goes wrong… they’d define a “scheme”.

Now… this scheme would need two things: consumer recognition and merchant recognition. Consumers would need to know their card would be accepted at a participating merchant. And participating merchants would need to know a given card was part of the scheme.

So we need a brand. This brand would be something you could put on the cards and place in the shop window. It is how a merchant would know an issuer’s card was part of this scheme and it is how card holders would know a merchant was able to accept cards from that scheme.

One of these schemes is, of course, Visa. Another is Mastercard. And so on. And this is why cards carry two brands…. One to identify the issuer and one to identify the scheme.

In this way, the card schemes have created a system that allows merchants, who only have a relationship with their own bank, to accept payment cards issued by hundreds of other banks, without having to have any relationship with those banks at all.   The only thing that matters to them is that the issuer’s card is issued on the relevant scheme.

And this model has really strong network effects… the more issuers and acquirers in the scheme, the more useful the scheme is to card holders and merchants. It’s self-reinforcing.

Talk is cheap… how does it work in practice?

OK. So we have a paper agreement that says an acquiring bank will accept any valid transaction made with a Visa-badged card.   But how? How do they get approval from the issuer for the transaction? How do they get reimbursed? How does it work in reality?

Do all members of a scheme have to have a relationship with every other member so they can route the transaction to them for payment? That would be expensive and error-prone.

So this is where the scheme re-enters the picture.   In addition to maintaining a powerful brand and setting the rules, they also run a switch: the merchant acquirers send all their Visa transactions to Visa itself… and Visa then forwards them on to the appropriate issuer.   Similarly for Mastercard and the other schemes.

So we end up with a hub-and-spoke model… with Visa at the centre. (And Mastercard and Union Pay and so forth).

Cards Picture 3

Issuers and Acquirers are members of a “scheme”, which sets the rules and acts as a central “switch” to route transactions. It means merchants with one bank can accept payments from customers of another bank, without having to maintain bilateral relationships

So now we can see why card schemes are so successful: their globally-recognised brands create networks that anybody aspiring to issue or process cards need to be part of. It’s a self-reinforcing virtuous circle that is extremely hard to disrupt

And this is why Visa’s “customers” are the issuing and acquiring banks… not end-consumers… Visa exists so that issuers can receive broad acceptance of their cards… and so that merchants can, in turn, offer broad acceptance.

But the schemes depend on consumer recognition – hence why they spend so much money advertising to consumers, even though the consumers are not their customers.

What does this have to do with Bitcoin? Push versus Pull

Notice something really important: this is a pull system… the reason you need all this infrastructure is because your card information has to get all the way from the terminal in the merchant back to the issuer so the issuer can pull the money from your account and send it back to the merchant.

By contrast, Bitcoin is a push system: once you know the merchant’s “account” details, you can just push the payment to them. So why do you need all these intermediaries?

If you were a Bitcoin payment firm trying to break into the retail market, perhaps that’s where you’d start? After all, it’s true that most of the payment card infrastructure simply isn’t needed in the Bitcoin world.

But notice how I set up this story. The infrastructure was the last thing I talked about. For me, the two most important things are:

1)   Global acceptance.

2)   The rulebook

Think about what Visa and Mastercard have achieved: they offer global acceptance and predictable behavior.   Wherever you are in the world, you can be pretty sure somebody will accept your card and you know how it will work and that there is a well-understood process when things go wrong. This offer is powerful. Ask yourself: if you could only take one payment instrument with you on a round-the-world trip, what would it be? If you couldn’t stake a stack of dollar bills, I suspect you’d opt for a credit card.

And this predictability – a consequence of the rulebook – is important: consumers enjoy considerable protections when they use a major payment card. They can dispute transactions and, in some countries, their (credit) card issuer is jointly liable for failures of a merchant. Consumers like to be nannied… even if they have to pay for the privilege!

So for those who aspire to overturn the incumbents, you need a strategy for how you will become the consumer’s “default” or preferred payment mechanism.

American Express has achieved this through a joint strategy of having large corporates mandate its use for business expenses and offering generous loyalty benefits to consumers… they effectively pay their customers to use their cards.

PayPal has achieved it through making the payment experience easier – but note, even here, many PayPal payments are fulfilled by a credit card account!

And this is why I harbor doubts about whether Bitcoin will become a mainstream retail payments mechanism, at least in the major markets… why would a consumer prefer it over their card?  Perhaps the openness and possible resistance to card suspension/censorship will attract sufficient users.  But it’s not obvious.

For me, the opportunity lies elsewhere: high-value payments, smart property and so forth.  But I could, of course, be wrong.  It wouldn’t be the first time…

An aside on history and factual accuracy

I know this account would scandalize a historian but that’s OK: It’s not intended to be historically accurate… the idea is to share intuition on why things are the way they are.

Some of the more important topics I’ve ignored or deliberately simplified include:

  • I’ve not explored the difference between Visa Inc (public company) and Visa Europe (owned by its members)
  • I’ve ignored the “three-party” schemes like American Express.
  • I’ve also ignored fee structures and the importance of interchange.
  • I’ve also not discussed the role of processors… specialist firms who effectively outsource the work of issuers and acquirers
  • Security
  • … and lots more

 

We shouldn’t assume that the best technical solutions will prevail: on “push” versus “pull” payments

I’ve just posted a new piece on the IBM “Insights on Business” platform discussing “push” and “pull” payments.  I point out how push payments, in general, would remove whole classes of threat from the retail payments landscape but that there are some real problems around adoption that may prove insurmountable.

Who will decide the future of retail payments?

Ultimately, we need to remember that consumers actually like their credit cards and most phone-based solutions today are clunky.  So some recent research from Denmark that studied how real people respond to different options is very enlightening.  It’s obvious that we should spend more time thinking about things from users’ perspectives, but difficult to do in reality!