[Schweigi]

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 Switzerland most terminals are PayPass ready.

[johndbeatty]

Apple Pay is very standards compliant and the networks are very global. So I wouldn't be surprised.

[iancarroll]

This is also great for us Android/GWallet/Isis/Softcard users, as more merchants will want EMV and have it implemented.

[ThrustVectoring]

As far as hardware goes, yes - the same antenna you use for talking with a MasterCard can get used for talking to a smartphone.

However, POS software is not at all standardized. You'd likely end up rolling out support for one POS platform at a time. They'll have the hardware you need to support ApplePay, but the rest of the work is probably tricky.

tl;dr POS software systems that accept PayPass can change their software to accept ApplePay.

[ChrisClark]

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.

[ThrustVectoring]

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.

[iknowthisstuff]

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?

[hackmiester]

Another interesting question: If a vendor adds support specifically so that they can accept Apple Pay, will my Android phone start working for NFC payments there?

[iknowthisstuff]

If they implement whatever transaction API is required by your wallet..

[sytelus]

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.

[khc]

Did you mean "embraced"?

[makomk]

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.

[surreal]

In theory (at least that part of) the process should work internationally. It is worth noting though that Google Wallet, which has worked with MasterCard PayPass terminals since 2011, is still only available for US devices with US SIM cards.

[needusername]

It sounds like the acquirer needs to be ready to support network-level tokenization. I have no idea how an acquirer can detect what kind of card it is an compute interchange when everything is in the same BIN.

[lxgr]

The Tokenisation FAQ by EMVCo suggests that the BINs could be selected from the card network's existing ranges, which would allow merchants and acquirers to simply pass them through to the network (where the de-tokenisation is performed): http://www.emvco.com/faq.aspx?id=264#13