

Apple Pay: An in-depth look at what's behind the secure payment system - IBM
http://www.tuaw.com/2014/10/02/apple-pay-an-in-depth-look-at-whats-behind-the-secure-payment/

======
Someone1234
The HK title is identical to the article's title but the article's title is
misleading. Even the author goes into great pains in the first paragraph to
say that this will look at "[the] process in broad strokes" and not really in-
depth.

Plus the article is really low-tech (spending a very long time teaching us
about tokens) and very pro Apple (e.g. making claims that make no sense like
"it may very well be the safest way to make any type of credit card payment"
yeah, except those dozens of other identical systems we already have, and have
had for at least a year!).

I have nothing against Apple Pay at all. I am glad they joined the party. This
article though is meh.

~~~
surreal
Could you elaborate on the dozens of identical systems? I haven't yet managed
to find one where no one except the credit card networks can see my CC number
(and I thought the tokenization spec was only released 6 months ago...)

~~~
DannyBee
Virtual credit card provisioning seems common.

For example:
[https://support.google.com/wallet/answer/2740044?hl=en](https://support.google.com/wallet/answer/2740044?hl=en)

Token-like services are also common for contactless payment systems ...

~~~
surreal
Your linked example is drastically different. Although the merchant only sees
a virtual card number, Google sees, stores and charges your real credit card
number the old-fashioned way.

~~~
DannyBee
You say "Google sees your real credit card number".

(I'll address the rest later)

Somebody sees the credit card number, even in token based systems, even if
it's only for a moment to acquire a token.

In other words, either Apple stills sees it while it acquires a payment token,
or someone does to issue the payment token, as it's the only mechanism that
identifies the account number to get a token for. The tokenization
specification has a whole section on what identification and verification
should be taking place to ensure the "primary account number" (credit card
number) that the payment token is replacing is one the user has authorization
for.

So let's focus on the "stores and charges". Yes, Google stores and charges
your primary account number. This is just because Google happens to be the one
doing the payment processing. Even in a token based system, again, somebody
_on the other side_ knows what real primary account number (credit card
number) this token links back up to so they know what to subtract money from.
The token based stuff is not an full anonymization protocol, it's mainly a way
to securely avoid transmitting and storing credit card info to/by random
merchants. In _that_ respect, the virtual credit card numbers provide the same
protection. They are one time use, and interception or storage by the merchant
can not harm you. Secondarily, the payment tokens are also a way to reduce the
number of networks your credit card number goes over, when used properly. The
virtual credit card numbers perform the same function here too.

The person who knows in either system is usually your payment processor
(though in case it isn't, it's possible for the tokens to be used there too.
however, nothing in Apple Pay currently guarantees _this_ happens with the
tokens). Since that is google here, it makes sense they would have the primary
account data to do the lookup.

If you are expecting tokens to replace credit card numbers all the way to the
issuing bank, you are sorely mistaken. The lookup happens much earlier than
that.

The TL;DR is that virtual credit card numbers are in fact, a method of
tokenization. The only reason they went with "token" is because they don't
have to be credit card numbers, and because not all virtual credit card
implementations have the same guarantees.

In any case, if you want fully tokenized systems, those have existed too, just
not en masse.

~~~
natrius
EMVCo payment tokenization is more secure and more private than Google Wallet.
With Google Wallet, two people know your card number and purchase history:
Google and your issuer. With EMVCo tokenization, just your issuer knows your
card number and purchase history.

It's better. It's the future.

 _" If you are expecting tokens to replace credit card numbers all the way to
the issuing bank, you are sorely mistaken. The lookup happens much earlier
than that."_

I disagree. Care to explain?

~~~
DannyBee
"just your issuer knows your card number and purchase history."

If this was true, i'd agree. But it's not, AFAIK.

"I disagree. Care to explain?"

Nothing in the spec that i have seen requires that it be used all the way to
the issuing bank.

In fact, here is one actual implementation:
[http://www.firstdata.com/downloads/thought-leadership/EMV-
En...](http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-
Tokenization-WP.PDF)

Now look at figure 2 on page 8, and you can see ... It's not the issuer doing
the tokenization or the PAN lookup, firstdata is doing it (in this case), just
as Google is doing it in the Wallet case. Firstdata sells an approved apple
pay solution.

It happens that Apple does not provide payment processing services, and is
thus not doing it. That of course, does not change how many parties see your
card number :)

Now, maybe there are issuers doing the tokenization, storage, and lookup
themselves. But it's not required.

The actual spec leaves these functions to an "Agent" (not an issuer) and
defines an Agent as "An entity appointed by the Card Issuer to perform
specific functions on behalf of the Card Issuer. Some examples of these
functions include card processing, Cardholder verification using the 3-D
Secure protocol, and Token Service"

There is also nothing that assumes they do not appoint multiple agents (and in
fact, specifically forsees this happening), etc.

Love to see something that says otherwise, but i can't find it.

~~~
natrius
That whitepaper is from 2012. The tokenization there is for merchants to be
able to keep a token on file for a customer instead of keeping a card on file.
It's like getting a Braintree or Stripe token to use for payments, but
instead, you're getting a First Data token.

This is how things work in 2014: [http://clover-
developers.blogspot.com/2014/09/apple-pay.html](http://clover-
developers.blogspot.com/2014/09/apple-pay.html)

(Clover is owned by First Data.)

~~~
DannyBee
"That whitepaper is from 2012"

It's pointed to from their apple pay solution as to how it works?

"This is how things work in 2014: [http://clover-
developers.blogspot.com/2014/09/apple-pay.html](http://clover-
developers.blogspot.com/2014/09/apple-pay.html) "

Again, I have not seen a single implementation that claims to actually perform
token usage all the way back to the issuing bank, just some diagrams that say
"it's supposed to work that way" in some magical world where issuing banks run
token service.

(and i've looked at actual implementations).

If you look at the comments on the blog, the author actually agrees with what
i said: "Yes, the token is issued by the payment network, but Apple is not the
payment network. The network would be Visa/MasterCard/AMEX. Apple receives the
token from the payment network when the card is stored in Apple Pay (or
Passport), then the token is provided each time a payment is made."

Note: Issued by the payment network. This is not the same as "bank who issued
you the card". In fact, it's exactly the people I said it was (look at
definition of payment network in the spec).

Also note: Apple sees the card to get the token to store in the wallet (it has
to, unless the client directly understands how to route to an agent for a
given card and connect there, which at least as apple has implemented, it
doesn't). If you remember, above you said in an EMV world, only the issuer
sees the real number. This is 100% false. Apple has no other way to get a
token other than providing the PAN and letting an agent do ID & verification
as part of a token request.

As I also said, the spec _very specifically_ does not require anything else,
delegating token service providing to agents.

Do you have anything to refute that issuing banks are going to be 100%
compliant with the EMV tokenization spec (and apple pay) if they delegate the
vault/lookup to someone else, like the payment processors? (I pasted the
definitions from the spec, it specifically says the card issuer _or_ the agent
can perform this )

How about if they delegate to multiple people?

How about if they delegate to stripe, or google, or whoever?

The tokens only go exactly as far as the parties agree they want them to.

Two parties still see your card in Apple Pay: Whoever initially asks for the
token to store (Apple right now), and whoever is playing vault. Apple just
doesn't store it.

------
zecho
This is great and all, but of the 9 million merchants that accept credit cards
at the point of sale, Apple says only 220,000 locations will accept it at
launch.

Walmart and Best Buy have gone so far as to basically say they have no plans
to implement and maintain NFC at the POS.

~~~
rconti
October 2015 they'll be liable for CC fraud if the transaction in question was
not cleared on an NFC+EMV capable terminals. I don't know where your info is
from, but it's either old, or they'll change their tune fast. Also, some
businesses can avoid PCI audits if 75% of their transactions are cleared on
NFC+EMV terminals. The liability shift you keep hearing about bundles NFC+EMV
together into a single concept. They're inseparable as far as CC liability is
concerned.

~~~
frogpelt
His info is based on the fact that Walmart is all in with CurrentC another
mobile payment system developed by MCX.

Unless Apple can show that Walmart will actually lose customers by not doing
it, I don't see them adopting Apple Pay soon.

EDIT: Nevermind. I wasn't aware that NFC was the only requirement on the
merchant-side for Apple Pay to work.

~~~
DrewRWx
The minute Walmart get a POS that supports NFC, they won't have a choice.

------
spullara
Here is more technical description of how exactly it works if you are
interested in the details:

[http://clover-developers.blogspot.com/2014/09/apple-pay.html](http://clover-
developers.blogspot.com/2014/09/apple-pay.html)

------
muglug
> Note, though, that the precise components of the Apple Pay cryptogram aren't
> publicly known.

So we have a hash function whose workings are known only to Apple and Visa,
MasterCard etc.

I wonder how long that'll last.

~~~
maccard
Its most likely some existing function, btu they aren't specifying which one.

------
pradn
Only if everybody uses phones with Apple Pay compatible payment systems will
every business see the need to support Apple Pay. I hope everyone gets on the
same standard soon.

~~~
mcintyre1994
Do they need anything above and beyond an NFC reader that supports contactless
cards? Contactless is getting really popular in the UK - it's super cool if it
is just that that it needs to work. Contactless on the tube too!

~~~
lstamour
The ones that roll out alongside chip-and-pin seem to be all that's needed to
meet the requirements of this system from a technology standpoint. Behind the
scenes, the hardware passes your fake device-account number as it would a
credit card, and someone turns that into an actual credit card number deep in
a financial system your retailer uses. There's different standards for
contactless payment, though, and I bet Apple's partnering with EMV players
because it wants to be as compatible as possible with existing arrangements.

