“Would you like to pay by cash, credit or debit?” As we approach the end of 2015, this question continues to be asked by retail staff across the country, but ‘mobile’ has yet to creep into the vernacular. While mass adoption of mobile payments remains to be seen, the race is heating up with the introduction of multiple big-name players, and newcomers, looking to dominate the digital wallet space.
-Apple Pay, which launched in late 2014 is the first to use a custom integration with Banks for their payment solution.
-Android Pay, is the successor to the Google Wallet experiment.
-Samsung Pay, which was enabled in summer of 2015, offers some unique compatibility features with older merchant card terminals.
-We also have a smaller player, Lucova, which attempts to distinguish itself from the aforementioned by using Bluetooth Low-Energy.
In this article, I’ll give a brief overview of the underlying technology behind each mobile payment method and what differentiates them.
Starting with the iPhone 6 series, users have the ability to enter their credit card information and use their phone in place of a credit card at NFC-enabled card terminals. In the US, where some merchants are still using a card’s magnetic stripe to process payments, a physical credit card will still be required, however this will become less of a problem as merchants move towards the new NFC-enabled terminals.
Apple Pay is initialized by entering a credit card number, which is then uploaded to Apple’s servers and subsequently forwarded to the card’s corresponding bank. Apple has worked out a new custom system with the banks where Apple sends the card information, exchanging it for a unique key that is tied to the card’s account. This unique key is then routed back through Apple’s servers and down to the phone and stored on a special hardware device in the iPhone called the Secure Element. The Secure Element is used for storing encrypted data separate from the phone’s main storage and can be unlocked with the user’s fingerprint.
Each time a payment is made, this key is retrieved from the Secure Element and this key is used to generate a one-time-use token that the bank resolves to the user’s account. The advantage of one-time-use tokens is that once it’s been used, it is no longer valid. This renders any data captured by malicious eavesdropping devices useless. When contrasted with yesterday’s technology, where a single card number or malicious magnetic card swipe was enough to compromise a user’s account, one can see this is a big step forward for security.
Like Apple Pay, Android Pay works only with NFC-enabled card terminals. Unlike Apple’s implementation, Android Pay requires a trickier approach. Due to the fact that Google doesn’t directly control the hardware ecosystem its Android OS runs on, it cannot rely on the availability of an embedded Secure Hardware Element. In the early days of Google’s first payment initiative, Google Wallet, only Android phones that had a Secure Hardware Element were supported which were few and far between.
Later versions of Google Wallet, and the new Android Pay resolve this issue by using Host-based Card Emulation – this circumvents the requirement for a Secure Element in the hardware by allowing the payment application itself to emulate a card and talk directly to the NFC reader. In Android Pay, the keys that would be stored on a Secure Element on an iPhone is instead stored in the cloud on Google’s servers.
In order to work-around the issue of “deadzones” – an area where your phone might not have strong enough signal to access your keys stored in the cloud, Android Pay allows your phone to store a few pre-generated one-time-use tokens for these offline transactions.
One distinction to note between Apple and Google’s token implementation – because Google has not worked directly with banks for the implementation of Android Pay, each one-time-use token used by the system is actually a randomly generated credit card number from a pool of unused numbers. Contrast this with Apple’s system where their custom integration with banks allows them to use a randomly generated token that doesn’t resemble a credit card number at all.
Even though Samsung Pay runs on Android, its payment system is more of a hybrid between Android Pay and Apple Pay with the exception of a unique backwards compatibility advantage. As with Android Pay, Samsung relies on tricking the credit card terminals that an actual card is present. However, because Samsung Pay only works on Samsung devices, Samsung is able to rely on the presence of a Secure Element on the phone to power payments via NFC. Additionally, it is also able to take advantage of a unique feature called Magnetic Secure Transmission. With the Galaxy S6 and newer flagships, each device includes a small coil that is able to output and vary a magnetic field in such a way to trick a terminal into believing a physical card is being swiped as the phone is held near.
While Apple and Google wait for the NFC terminals to become omnipresent, Samsung hopes their technology will give it a head-start in conventional payments vs. its competitors by allowing the user to be confident Samsung Pay will work, regardless if the merchant has NFC-enabled terminals installed.
Lucova’s Payment System
Instead of using NFC or magnetic swipes to communicate payment authorization, Lucova uses the latest Bluetooth Low-Energy (LE) standard. Unlike NFC which requires the user to take their phone/card out of pocket and hold near an NFC reader, Bluetooth LE allows the customer’s mobile device to communicate from much further distances which opens the door for far more functionality than just payments.
Similar to the aforementioned payment solutions, Lucova uses tokenization technology between the customer and merchant devices. When a customer is ready to pay, a bi-directional channel is created between the user and merchant device. The user receives information relevant to the payment such as the staff member’s name, total amount requested, optional tip percentage etc. Once the user presses confirm, a one-time-use token is sent back to the merchant device which then proceeds with the card balance deduction. The user also has the option of enabling hands free payments by setting a pre-defined auto-confirm amount on their device, which allows payment confirmation without ever taking the phone out of pocket.
Due to Bluetooth LE, once the customer enters a Lucova enabled merchant location, their device is able to begin communicating with merchant terminals. For security purposes, during set-up, the user’s app will request a user profile photo. It is this profile photo that appears on the merchant terminal when a user is in vicinity, and is used by the staff to identify the user alongside other factors such as placement in an ever re-arranging nearby-customers list which represents their proximity to the payment register.
The payments landscape in 2016 and beyond is going to change rapidly as users expect to wield more power with their phones. At the core of this will be the ability to offer a truly frictionless experience to consumers which comes down to features like hands free mobile payments. This is something that Google is currently testing and Lucova already has in the marketplace. A revolutionary change in commerce is taking place and who wins the race remains to be seen.
– Martin Konecny, Senior Developer, Lucova