Android Pay for the Mobile Web - Part I

Blog Post created by gjsissons on Apr 13, 2017

Welcome to the first in a two-part series exploring Android Pay for the Mobile Web. In this first article, I’ll look at Android Pay, explain why it's important for merchants, and explain how Android Pay works with Vantiv. In the second article, I’ll focus on considerations for developers, and suggest some best practices for implementing Android Pay as a part of an overall mobile wallet strategy.


For merchants, one-touch payments and digital wallets are a big deal. Why you ask?


According to research by McKinsey, mobile purchases will grow from $100 billion in 2015 to an estimated $400 billion by 2020 - a 50% CAGR. Perhaps even more significant, of the roughly $200 billion spent annually across eCommerce & mobile channels presently, nearly 50% of purchases involve stored credentials, a figure that is sure to rise.


Some other notable statistics are as follows:

  • US shoppers spent $22.7 billion USD in eCommerce purchases from mobile devices in Q4 of 2016, a 45% increase over the same period last year according to a report from comScore
  • Retailers are seeing greater engagements from Mobile devices with consumers downloading more retail apps, and mobile now comprises 45% of all traffic to retailer’s sites based on research from Demandware
  • According to data from Barilliance, despite the dramatic increase in mobile shopping, consumers abandon shopping carts at a higher rate on mobile (77.5%) than on desktops (70%) suggesting there is still too much “friction” in the payment process.


What does this mean for on-line retailers? It means they're in a race to provide the convenience of one-touch payments. On small screen devices like phones and tablets it is tedious to create profiles and key in payment credentials. Customers will prefer to shop at retailers where they already have a profile, making new customer acquisition hard. One-touch checkout on web-sites, enabled by mobile wallets like Android Pay, is a game changer. It can re-level the playing field, helping merchants compete in new markets and boost conversions and sales.


In an earlier article I discussed Apple Pay, how it works, and various Vantiv integration resources available to developers. Here I'll take a similar look at Google’s Android Pay, focusing on mobile web payments.


About Android Pay


Android Pay’s web payments solution relies on the JavaScript PaymentRequest API, an open, W3C standard supported presently on Chrome and recent versions of Microsoft Edge. Unlike Apple Pay on the Web, the PaymentRequest API can either accept credit cards (stored securely in Chrome) or payment cards entered via the mobile device’s Android Pay wallet as a payment source.


Like most modern payment technologies, Android Pay uses a token to represent the actual payment card stored in the wallet. When a user adds a card to the Android Pay wallet, Android Pay requests a network token from the bank that issued the card. Once the token is received, it is encrypted and stored by Google so it can be used for payments. Because the bank issues the token (via a token-service provider) only the bank can match the token back to the actual card number. This adds security because even if the token is compromised, the consumer’s payment details remain secure. Unlike Apple Pay which stores encrypted tokens on the phone, Google stores encrypted tokens in the cloud.


How Android Pay works


We’ll skip a few details in the interest of simplicity, but when a user makes an in-app or mobile web payment using Android Pay, the client sends a payment request to Google, and Google responds with the customer’s encrypted, tokenized card along with a cryptogram that serves as a one-time password. One way to submit an Android Pay payment is for the merchant to decrypt the Android Pay token and send the token along with the cryptogram to a processor like Vantiv that supports Android Pay. The payment processor in turn, relays the network token to the card networks who translate the token into an actual card number, and facilitates the movement of funds between the customer’s issuing bank and the e-Commerce provider’s merchant account.


This process works well, and is secure, but it's complicated. The developer needs to worry about managing keys, decrypting the token, and dealing one-time cryptograms for each transaction. Worse, for a web developer, where applications will interact with a variety of clients, this complexity is magnified for every mobile and digital wallet platform that they support. Each wallet has its own nuances and may handle interactions between the device, wallet and payment provider differently via different APIs. Applications built to support multiple payment methods and wallets can get complicated fast.


A Simpler Solution


For a few larger payment providers, including Vantiv, Google offers a simpler approach involving the use of a gateway token provided by the payment provider via a back-end server-to-server connection.


When a web application makes an Android Pay payment request using this technique via Vantiv, the application will pass the payment request to Google, and Google will handshake with Vantiv directly, returning a Vantiv supplied low-value token (referred to by Google as the gateway token) in exchange for the network token decrypted and vaulted by Vantiv. The gateway token (aka the low-value token or LVT) can then be used by the developer’s app or website to authorize a payment across any of Vantiv’s major payment front-ends.


Behind the scenes, the integration leverages Vantiv’s eProtect service, a secure middleware solution used in a variety of situations to reduce PCI scope by avoiding the need for payment applications to handle actual payment credentials. Vantiv handles details like decrypting the network token, storing it in a secure vault, retrieving the token when the gateway token is provided as a payment source, and interfacing with the card networks to process the payment.


A step-by-step diagram of how this works is shown in the figure below. For Android Pay capable devices with one or more valid payment cards stored in the Android Pay wallet, the process starts at “Step 1”. The Mobile Website will also need to handle payments made from devices not supporting the PaymentRequest API, or for consumers with no card in their wallet. In this case, they can simply use Vantiv’s eProtect client-side JavaScript library to securely capture the card data and exchange it for the same type of low-value token used by Android Pay as the gateway token (“Step 1a” through “Step 3a”).


Regardless of the payment method, this means that the interaction with Vantiv is essentially the same starting at “Step 6” where the low-value token is accepted by Vantiv as the method of payment.




Why does this matter? It means that the application can process a payment the same way regardless of whether the payment is made with a credit card, Apple Pay, Android Pay or other methods. This promotes simplicity, reduces cost, and allows the same back-end reporting and management tools to be used regardless of the payment method or mobile wallet.


In the next article, I’ll provide some additional details and considerations and best practices for developers coding mobile wallet integrations with Android Pay.


To learn more about Vantiv and Android Pay, join Vantiv O.N.E. and visit the Google Community.


I'd welcome your thoughts, questions and feedback!