Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Am I right to assume that any terminal which accepts Apple pay will work with Android Pay as well? Or is there some tweaking that needs to be done on the side of the banks or businesses? If it's the former, then yeah, Apple Pay and Android Pay really have no reason to oppose each other.

From my understanding, there is some tweaking on the back end, but nowhere as big as the original change. Meaning that if a bank modifies the back end to accept one, they can accept the other with very minimal change.
 
I'm not really sure what you're talking about. Neither system uses your actual account information in a transaction. The tokens are, as you stated, one time use. Those tokens aren't stored by either system. Why would they be stored? 1 time use remember. Can't be used again. I think you may be thinking of the secure enclave (SE). If you are, you're thinking about it incorrectly. Afaik, the SE has nothing to do with CC info or Apple Pay beyond the fact that's it verifies your fingerprint from the Touch ID sensor. That verification allows access to the phone, or in the case of Apple Pay, allows purchases. In the off chance you were referring to the other SE - Secure Element, both systems use secure elements for their payment processes.
With Apple Pay, tokens are generated in a chip called the Secure Element. With Android Pay, they're generated in the cloud, which is what Host Card Emulation is. If you're without Internet and need to use Android Pay, the app will tap into a limited number of stored tokens on the device. (Where and how those tokens are stored isn't clear.) source: http://www.cnet.com/how-to/android-pay-phone-how-it-works/
 
Am I right to assume that any terminal which accepts Apple pay will work with Android Pay as well? Or is there some tweaking that needs to be done on the side of the banks or businesses? If it's the former, then yeah, Apple Pay and Android Pay really have no reason to oppose each other.

Yep, you're right, if a terminal works with one, it should work with the other.

The terminals just need to be able to handle either old (MSD) or new (EMV) contactless protocols. And behind the scenes, the range of numbers being used as account tokens have to be in the routing tables so the merchant acquirers know which bank to forward the purchase authorization request to.

These are the main requirements that apply to both payment methods, and are thus common.

Another helpful aspect is that Apple did not create their own payment standards, nor did they write or control the payment applets used in the Secure Element. All that was done by and belongs to the credit card entities. It's their secret sauce and they don't let it out. Apple simply hosts that code, and provides a UI. This is good, as it will be kept updated by others (although it apparently takes an iOS update to pass on the code, if the iOS update needed to get Discover Card support is any indication).

The only EMV feature that I believe is (so far) uniquely used by Apple Pay, is the ability to bypass the signature on higher amounts IF the terminal has also been updated to recognize and accept the EMV standard Device Cardholder Verification flag that Apple Pay tries to send. But I wouldn't be surprised if this is also now supported elsewhere.
 
Last edited:
The only EMV feature that I believe is (so far) uniquely used by Apple Pay, is the ability to bypass the signature on higher amounts IF the terminal has also been updated to recognize and accept the EMV standard Device Cardholder Verification flag that Apple Pay tries to send. But I wouldn't be surprised if this is also now supported elsewhere.

And that part is what can put Apple Pay over regular card NFC transaction. The ability to pay any amount without the need for the PIN.
 
With Apple Pay, tokens are generated in a chip called the Secure Element. With Android Pay, they're generated in the cloud, which is what Host Card Emulation is. If you're without Internet and need to use Android Pay, the app will tap into a limited number of stored tokens on the device. (Where and how those tokens are stored isn't clear.) source: http://www.cnet.com/how-to/android-pay-phone-how-it-works/
I understand that. It's a one time use token. How is where it's generated relevant to one not being secure? I guess as an academic exercise it might have relevance. As a practical matter, you've lost me. What's the security issue?
 
And that part is what can put Apple Pay over regular card NFC transaction. The ability to pay any amount without the need for the PIN.

Yep, the On Device Verification flag is intended to help mobile contactless payments catch on.

Note that it's possible for a wallet sized card to use the same flag, if for example, someone designed a contactless card that had a thumbprint reader built into it.

Hmm. That would actually be a cool thing for one of those so-called "universal credit cards" (like Swyp, Plastc, Coin) to add. Do any already have one?
 
If you want to see an absolute true culture of credit card use, make a visit to Sweden - there ain't nothing they don't charge on their cards.
True! I don't think I have had any cash on me for the last couple of years. I pay for everything with my card.
 
I understand that. It's a one time use token. How is where it's generated relevant to one not being secure? I guess as an academic exercise it might have relevance. As a practical matter, you've lost me. What's the security issue?
The security issue is that it's stored (we don't know where, but hackers can find out), which means it can be stolen.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.