Why Apple Pay is Better Than Android Pay: Gene Munster

Often-cited analyst Gene Munster of Piper Jaffray believes Apple Pay has had a slower start than investors expected – only about 20% of new iPhone owners have activated the service – but he is confident long-term usage will grow significantly. He highlights two of the five Apple Pay components listed in Apple’s iOS security guide (via BidnessEtc).

Apple pay

From his perspective – as explained in a note sent to investors – Apple Pay’s advantage over its rival, Android Pay, lies in the use of Secure Element, which compares to the software-based host card emulation (HCE) used with Android-based payments services.

Munster says the presence of the Secure Enclave gives Apple Pay a considerable advantage over Android Pay, as the internal hardware makes it more secure.

The analyst stresses that Secure Enclave – present in iPhones since the 5s model – has restricted access, is encrypted, and handles both fingerprint authentication and gives the green light for transactions.

Secondly, the iPhone also uses a secure element that is an “industry-standard, certified chip running the Java Card platform, which is compliant with financial industry requirements for electronic payments,” Apple says in the guide. As Munster points out, the secure element is able to process the transaction only after it receives authorization from the Secure Enclave.

Munster didn’t to go into details of how HCE works, but of course, security is a significant concern with HCE, since the security component (see NFC-based SIM, which incorporated the secure element) is removed. Instead of placing the secure element in the phone, HCE allows it to be placed in a remote and hosted cloud environment, which is accessible to the mobile wallet app. Single use credentials (“session” keys for example) are then delivered to the mobile app to enable it to perform a single transaction. The risks to these single use credentials should be much lower than the risk to those at the account level. The actual risk will depend on the specific implementation, as detailed in a Consult Hyperion white paper.