How Does Android Pay Differ from Apple Pay and Samsung Pay?

Google announced Android Pay yesterday at its I/O conference. The internet giant outlined a set of APIs that will allow developers to add an Android Pay button to their app and banks to enable payments in their existing applications, facilitating in-app and in-store payments on Android devices with KitKat 4.4 and above. This is a big deal. With 70% of Android handsets incorporating NFC and 50% supporting KitKat 4.4+, that’s a big audience.

We already know that American Express, Discover, MasterCard and Visa are on board. MasterCard has mooted its launch date to be ‘in the coming months’. So, the global support network is in place, but broader questions remain: Will it take on Apple Pay? How will it compare, or even compete, with Samsung’s offering? 

Comparing Android Pay to Apple Pay & Samsung Pay

Google’s open approach contrasts starkly with that of Apple, which has continued to maintain tight control over all integrated hardware and software components. Apple Pay utilizes an embedded secure element (eSE) in its proprietary handsets.

Conversely, Google holds just a tiny percentage of the device market (with its Nexus handsets). Its strategy is to win the battle for OS dominance and leave dedicated device manufacturers like Samsung to do battle with Apple in the hardware space. It is winning, too; in Q1/15 the Android OS accounted for 78% of the global market. By rolling Android Pay into its OS Google can, over time, enable more than three quarters of all handsets, everywhere.

Samsung’s proprietary offering, Samsung Pay, like Apple Pay, makes use of embedded secure elements (eSE). It doesn’t, however, control the end-to-end process and still supports host card emulation (HCE) leaving the issuers with options, unlike with Apple’s solution. 

What does Android Pay mean for banks?

If the issuing bank is hidden behind the ‘Pay’ button, they lose their branding and give up their independence. They can launch only when the schemes are ready and have to send all transactions to the schemes for de-tokenisation. This is already a concern with the Apple Pay model, but banks have no other choice. Android Pay offers banks more options, however, so they may well look for other routes to market in addition to the schemes.

Currently, the issuer-controlled HCE option seems to offer more flexibility, more control and lower long-term costs. It also has the added benefit of supporting all Android NFC/4.4 devices across the world, unlike Apple Pay and Samsung Pay which are, for now, limited to the US. Additionally, the launch of Android M (the next Android operating system) with its fingerprint authentication API’s, will allow this functionality to be implemented and driven right from the issuer’s own mobile banking app. An attractive prospect indeed. 

Deploying mobile payments on Android

From a bank’s perspective, if they want to get onto an iPhone, they have to do it Apple’s way. If they want to get on to Samsung’s devices, they have a range of options: 

1. Sign up with Samsung Pay. In this model banks can rent access to the eSE and connect to one of a range of trusted service managers (TSMs) that are connected to the service. In this way, Samsung Pay recreates the embattled SIM-based model for NFC deployment. The biggest limitation in this instance, however, is that it is only supported by Samsung devices. 
2. Sign up with Android Pay. At this early stage, it looks like Android Pay will require banks to partner with the card schemes. Card credentials will be hosted in an HCE/cloud server and tokenisation will be rolled into the offering from the scheme. 
3. Implement HCE and tokenization in house or with their preferred host. Despite requiring a greater upfront investment, taking control and implementing a standalone mobile NFC payment application has a number of benefits for banks. For one, they can reach all Android devices (supporting KitKat 4.4+) and maintain their independence – there is no need for them to send all of their transactions to the schemes. This is a significant advantage for issuer/acquirers who have a large volume of on-us transactions that they currently switch directly to their own authorisation systems without touching the scheme network (and incurring the associated cost).

Will Android Pay dominate the mobile payments market?

Will Android Pay dominate the market for mobile payments and go head to head with Apple Pay? Currently, it is looking unlikely. On initial inspection, the solution appears to be a scheme-hosted HCE service with Android branding, enabling Google to deliver a rapid response to Apple Pay in the US. While Apple Pay will undoubtedly roll out around the world, with most banks ultimately jumping aboard, market fragmentation in Android is likely to inhibit the pace of Android Pay’s deployment.

In the near term, the battle is likely to be more about which service wins on Samsung’s devices which currently account for 25% of the market. There may be no clear winner for some time and therefore no clear Android competitor to Apple Pay.

The good news is that most smartphone users will have a mobile payment option in the very near future as NFC finally comes into the mainstream.