How Apple Pay works and why it matters for developers • Hacker News Board

Re: How Apple Pay works and why it matters for developers

#21

Post by XorNot » Tue, Sep 09, 2014, 11:33 PM UTC

panabee wrote: post #16

XorNot wrote: post #15

Earlier quoted context omitted.

It really doesn't do this. Apple Pay is not the solution to moving money between parties who aren't registered merchants, with the relevant banking setup. Anyone can be become a merchant with a PayPass reader today. Apple Pay is not changing that, nor can it since that sector is entirely dependent on local commerce/finance laws and payment processor anti-fraud costs.

Apple Pay is focused on easing consumer pain and friction, leading to more competition among service providers and retailers since trying new services will become easier for users.

Ok now I'm not sure which aspect you're talking about.

Because in the physical world the friction is not "oh I need a card" it's physically getting the customer in the door. Otherwise, what's involved is needing merchants to have NFC readers. This might be an exciting new thing in the US, but certainly in my neck of the woods NFC has near universal penetration.

In the virtual world...this problem has been solved over and over and over. I'd argue it would be very surprising to see Apple displace Paypal. Everyone has Paypal - very few people (relatively) will have ApplePay.

Re: How Apple Pay works and why it matters for developers

#22

Post by sytelus » Tue, Sep 09, 2014, 11:33 PM UTC

Schweigi wrote: post #4

Apple Pay uses industry-standard EMV contactless protocols over NFC (and MSD contactless for backward compatibility). This makes it compatible with a wide range of contactless payment terminals in deployment today. So if the last section of the article is correct that means ApplePay will be compatible with Mastercard PayPass terminals? If this is true it would be really easy to roll out ApplePay as for example in Swi…

Perhaps this is why Apple never embarrassed NFC. Doing NFC based payments requires terminal upgrades while credit card companies are already rolling out their own version of no-touch payments.

Re: How Apple Pay works and why it matters for developers

#23

Post by tonyb » Tue, Sep 09, 2014, 11:49 PM UTC

The part I'm not quite following is when the tokenization takes place.

If it takes place per transaction then the PAN must be saved in the phone somewhere and the phone would have to be online to do the tokenization in real-time.

If it is a one-time tokenization that happens when the card is added isn't that token just as valulable as the PAN since the token can be used across merchants? Maybe the 3-D secure piece of the puzzle protects the token but I think this still means the phone has to be on-line to use the NFC payment feature.

Re: How Apple Pay works and why it matters for developers

#24

Post by makomk » Tue, Sep 09, 2014, 11:49 PM UTC

Schweigi wrote: post #4

Apple Pay uses industry-standard EMV contactless protocols over NFC (and MSD contactless for backward compatibility). This makes it compatible with a wide range of contactless payment terminals in deployment today. So if the last section of the article is correct that means ApplePay will be compatible with Mastercard PayPass terminals? If this is true it would be really easy to roll out ApplePay as for example in Swi…

From the merchant's perspective it should be more or less compatible with existing deployments. The problem's with the customer's side - unless their bank has done a deal with Apple they can't use it, and so far I don't think any banks outside of the US have.

Re: How Apple Pay works and why it matters for developers

#25

Post by debt » Tue, Sep 09, 2014, 11:58 PM UTC

tonyb wrote: post #23

The part I'm not quite following is when the tokenization takes place. If it takes place per transaction then the PAN must be saved in the phone somewhere and the phone would have to be online to do the tokenization in real-time. If it is a one-time tokenization that happens when the card is added isn't that token just as valulable as the PAN since the token can be used across merchants? Maybe the 3-D secure piece of…

I would think compromise of the token, while bad, is way less bad than compromise of the PAN. I would think it's much easier to regenerate the one-time token than to create a new PAN.

Re: How Apple Pay works and why it matters for developers

#26

Post by 21echoes » Wed, Sep 10, 2014, 12:06 AM UTC

> Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry

I'm sorry... what? How is this different from Google making Google Wallet back in 2011? They both use the same tech (PayPass, an industry standard), and both are made by an OS company.

Re: How Apple Pay works and why it matters for developers

#27

Post by iknowthisstuff » Wed, Sep 10, 2014, 12:32 AM UTC

ThrustVectoring wrote: post #14

ChrisClark wrote: post #13

Earlier quoted context omitted.

That sounds different than Google Wallet. With an NFC Android phone you can pay at any PayPass terminal, without them needing to change their software.

I will admit that I might be completely wrong about the technical requirements for this. I'm sure that at least the hardware will support it, and from what I understand there may be a difference in how the terminal goes from talking with a payment method to a verified payment.

See here: https://developer.apple.com/apple-pay/Getting-Started-with-A...

"Once authorized by the user with Touch ID, your app receives a payment token from PassKit. The payment token encapsulates the information needed to complete a payment transaction. It includes a cryptogram, unique to the specific purchase, that can be decrypted with your private key or when the payment information is transmitted to a payment processor’s server that has your private key. Figure 2 illustrates a typical payment flow. First the app checks that it can offer Apple Pay as a payment method. In this example, the app needs the postal code from the selected shipping address to calculate shipping cost and update the total amount due. When the user authorizes payment, your app receives a payment token from the Secure Element, via PassKit. Finally the app calls appropriate APIs in the payment processor SDK to pass the payment information to the payment processor, they process the transaction. "

Pg 4. - The payment flow. You are asking about the payment provider. They need an SDK or API from Apple whether it's a POS terminal, or mobile device. Once they implement it they can theoretically accept payments. But will Apple allow this?

Re: How Apple Pay works and why it matters for developers

#28

Post by iknowthisstuff » Wed, Sep 10, 2014, 12:42 AM UTC

debt wrote: post #25

tonyb wrote: post #23

The part I'm not quite following is when the tokenization takes place. If it takes place per transaction then the PAN must be saved in the phone somewhere and the phone would have to be online to do the tokenization in real-time. If it is a one-time tokenization that happens when the card is added isn't that token just as valulable as the PAN since the token can be used across merchants? Maybe the 3-D secure piece of…

I would think compromise of the token, while bad, is way less bad than compromise of the PAN. I would think it's much easier to regenerate the one-time token than to create a new PAN.

The token seems to be generated randomly (per transaction) in the Secure Element. See my above post.

Re: How Apple Pay works and why it matters for developers

#29

Post by gress » Wed, Sep 10, 2014, 12:52 AM UTC

21echoes wrote: post #26

> Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry I'm sorry... what? How is this different from Google making Google Wallet back in 2011? They both use the same tech (PayPass, an industry standard), and both are made by an OS co…

Google wallet was unpopular and was impeded by the cell carriers. It was a business failure, not a technical one.

Re: How Apple Pay works and why it matters for developers

#30

Post by tonyb » Wed, Sep 10, 2014, 1:21 AM UTC

iknowthisstuff wrote: post #28

debt wrote: post #25

Earlier quoted context omitted.

I would think compromise of the token, while bad, is way less bad than compromise of the PAN. I would think it's much easier to regenerate the one-time token than to create a new PAN.

The token seems to be generated randomly (per transaction) in the Secure Element. See my above post.

I don't think that is quite correct. There is per-transaction stuff going on but it isn't being tokenized for every transaction.

The token is stored in the secure element but is generated by the Token Service Provider (for example Visa Token Service).

After reading the EVM token spec linked in the post[1] and the developer guide I think I'm able to answer my own question.

The card is only tokenized once (or at least not per-transaction). For in-app purchases it is using 3-D Secure and for NFC is it using EMV, both of which provide some per-transaction security. Unlike a standard card the token will only work with 3-D Secure or EMV. For example a standard Chip&Pin card could still have it's mag-strip data extracted by a malicious POS system and used at a merchant that only uses magstripe terminals. With Apple Pay (and any other network token based system) a copied token would be worthless because it can't be used at a magstripe terminal.

Basically the phone is acting both as an automated 3-D secure checkout (it is processed by the processors just like 3-D secure but the authentication process is automated) and as a contactless EMV card without the downside of also having a magstrip with the PAN on it.

[1]http://www.emvco.com/specifications.aspx?id=263