Mobile payments are becoming ever more popular – I’m beginning to see more people using Apple Pay while out on my travels. I was excited by the recent release of Android Pay in the UK, so much so that I couldn’t resist having a play with the API. You can read about my experience here.
According to the UK Cards Association, as of April 2016 contactless transactions in the UK have increased by 185.9 per cent over the year. So, it’s no surprise that vendors seem keen to leverage this increasing acceptance of this technology, to attract users to their products.
Same as Apple Pay? Not quite
The two main contenders in the mobile payments race are arguably Apple and Google. While each have a similar approach, there are some rather stark differences.
Apple Pay, like Android Pay makes use of an embedded NFC chip within the device to communicate with a contactless terminal. Both services use what’s called Host Card Emulation, where secure tokens are transmitted in lieu of credit card details. As Apple controls its hardware, it has opted to use a hardware chip known as a Secure Element to generate these tokens. In the interests of security, Apple prevents access to the Secure Element and NFC chips, including to developers.
Google on the other hand creates its tokens for Android Pay in the Cloud, which does not mandate that any such chip is present on a device. Subsequently, Google has not restricted developer access to the NFC chip – and this is where I feel the issue lies.
Too many cooks?
Some UK banks, such as Halifax, are on board with Android Pay. Others, such as Barclays have chosen to go it alone. Android users wishing to make mobile payments using a Barclays-issued card, must do so via Barclays’ own Android app. And the confusion doesn’t end there. Some device manufacturers are also getting in on the act. Samsung Pay has rolled out in the US and Korea, while Huawei has launched its own offering in China. There was also talk earlier this year of LG introducing a similar service.
Arguably, many of these competing services enjoy a geographical monopoly when they first launch, as vendors aim to test the water. It’s feasible however that in future we’ll see users having an array of options at their fingertips. For example, a UK Samsung user with both Barclays and Halifax cards could potentially have three payment options, with a separate app for each.
Choice isn’t always a good thing
Android has been praised by some for the choice it offers to its users, but for mobile payments I believe simplicity is the key. Of course for developers or similar minded folk, setting up apps such as those mentioned is easy and often fun. But everyone isn’t so technically savvy. While my mum finds it fairly easy to use Apple Pay, I believe the Android offering would present nothing but confusion. This confusion wouldn’t end upon successful card enrollment; I believe things would get a little clumsy when trying to select an alternative card mid-transaction.
You can of course set your default payment application in Android’s Tap and pay settings, but I feel this is noise that should be abstracted from the user. I really don’t feel people like my mum would think to look for such settings!
Android’s myriad devices don’t help either. As well as navigating the software options, would-be users of mobile payments need to de-mystify device compatibility. It’s not as simple as ensuring one has a newer, flagship device. Near field communication, or NFC, was a startling omission from the otherwise stellar OnePlus 2.
Simplicity is key
For a mobile application to become popular, I feel it must meet some basic standards; it must be simple, reliable and ideally, elegant. Apple Pay is more mature than Google’s offering, so a direct comparison is perhaps a little unfair. That said, I do feel iOS users will find the simplicity of Apple Pay comforting, and most wouldn’t wish for more choice. Apple Pay is of course baked into iOS, and inviting users to enroll during the setup of a new device is a step in the right direction. This opportunity for the early on-boarding of users is one that Google’s approach may struggle to capture.
Security is of course front and center in today’s mobile world and no more than with financial matters. While those entering the mobile payments arena must provide clarity to their users, they also need to gain their trust. Both Apple and Google have received bad press from security scares, but Apple seems the stronger of the pair. I do have faith in Google’s commitment to security and would happily use Android Pay myself. I have less faith however, in the providers of competing Android mobile payment apps, some of whom may be good at banking, but see robust and secure software provision as a secondary appointment.
I really have high hopes for Android Pay and look forward to using it. I’m sure that in time, the numbers using mobile payments will overtake that of contactless cards. In the meantime, I feel it’ll be a bumpy ride, with many reluctant at first. I think it’s a little late for Google to take control of Android mobile payments but it could certainly do a lot more to promote confidence in the service.
Google’s Pay Day Rewards is an interesting idea, but generally I feel the marketing is grossly lacking. Many still haven’t heard of Android Pay, and Google would do well to increase its efforts in marketing the service. If Google truly wishes to target a broad range of users, it must firmly push the message of security and ease of use.
Due to its later release date, Android Pay will always be playing catch-up to Apple’s equivalent service. Had Google taken a more controlled approach to mobile payments I feel this task could have been much easier. I feel Android’s prevalent fragmentation in this area will apply a brake to the adoption of Android Pay, and mobile payments in general.