Welcome to the second of a two-part series on Android Pay for the Mobile Web. In a previous article, I looked at Android Pay, explained why it is important for merchants, and how Android Pay works with Vantiv payment platforms. In this article, I’ll focus on considerations for developers, and discuss some best practices for implementing Android Pay as part of an overall mobile wallet strategy.
Android Pay for the Mobile Web has the potential to increase conversions and revenue by allowing customers to checkout of your web-based store with a single click. It provides the convenience of in-app purchases, but without the need for customers to download and install a merchant-provided app.
Anytime a new method of payment is introduced it can involve additional effort, cost and possible downstream complexities. Implementing Android Pay is very worthwhile, but developers should keep a few things in mind as they plan their mobile integration effort.
Your customers aren’t all using the same wallet
As cool as Google’s PaymentRequest API is, it’s presently supported by the Chrome browser on Android. Moreover, Android Pay can only be used when a consumer has the wallet app installed on their device and it’s loaded with a valid payment card. Similar constraints apply to other wallets including Apple Pay, MasterPass and Visa Checkout. This is probably obvious, but developers can’t assume that all consumers will be equipped to pay with Android Pay. Make sure that your website can fallback to other payment methods. Vantiv’s eProtect-based integration approach is attractive, because payment transactions are coded identically whether a payment card is keyed into the website in exchange for a token (protected by eProtect) or whether Android Pay is used to obtain the token (also using eProtect behind the scenes).
Beware of “provider sprawl”
When implementing a new payment method like Android Pay, be careful that you don’t end up with separate back-end merchant accounts or payment providers to service the new payment method. This can lead to confusion, higher than necessary fees (since your volume will be spread among multiple providers), and back-end integration challenges. Ideally you want to deal with a single provider that can support all your payment channels using the widest variety of payment methods and wallets. Using a different gateway might be tempting to get to market fast, but it can be costly in the long run.
You need a solution that works with what the merchant already has
Unless the merchant you are supporting is a startup, they likely have sunk investments, and transact payments with existing gateways or payment providers. Beware of mobile integration solutions that require coding to a separate gateway, even if they are operated by the same provider. Your payment application or website will invariably need to support multiple payment methods, and being able to consolidate these payment methods with a single integration to a single front-end will dramatically reduce maintenance costs over the long term.
Build for “OmniChannel”
Whether your merchant offers a physical storefront or not, as their business grows, they may need to accept payment from multiple sources including their website, mobile apps, or via an in-store point of sale, or mobile payment acceptance solution. They’ll want to be able to recognize repeat customers regardless of the channel they use for purchasing. By federating consumer identities across channels, merchants can support a variety of new use cases including order-ahead, buy online pick-up / return in the store and more. They can also simplify reporting, and leverage analytics to better understand consumer behaviors.
This can be a little confusing, but presently when a consumer loads their credit card (identified by a "PAN" or "Primary Account Number") into a mobile wallet like Android Pay, what is stored in the wallet is known as a “Network Token” also referred to as a "DPAN" ("Device Primary Account Number"). At present, DPANs are different for each device, so if a consumer loads the same credit card on their phone and their tablet, they will appear as two separate DPANs, both different than the PAN making it difficult to federate identities using the PAN & DPANs alone. The card networks are introducing a new value however called the “PAR” or “Primary Account Reference” and Vantiv will be introducing the PAR functionality as soon as it is available. This will allow merchants to create a better OmniChannel experience because they will be able to link the purchase history from their customers regardless of whether they shop in-store, on-line or on any device using the same payment card.
Think through tricky use cases in advance
There are several cases where Android Pay and other wallets can be tricky. For example, if you are accepting a purchase that involves a future recurring payment stream, be aware that VISA and Discover card brand rules are changing, and you’ll need to stay abreast of these changes to avoid declines as new rules come into effect. There can be similar complexities around handling partial shipment applications, when a purchase is made once involving items that ship on different future dates. Vantiv can help you code your transactions to ensure compliance with evolving network rules related to mobile wallets.
Vantiv Developer Resources for Android Pay
To aid developers in deciding on the right integration method, Vantiv provides a Google community on the Vantiv O.N.E. developer portal dedicated to Android Pay and mobile integrations. The materials are organized by how Android Pay is being used (in-store, in-app or on the web) and Vantiv’s major payment processing platforms.
For most developers, an eProtect integration will make the most sense because it will reduce PCI scope for websites accepting credit cards, while also supporting a variety of mobile and digital wallets. By using eProtect to vault sensitive payment credentials in exchange for a simple low-value token, your application can use a single integration method, authorizing and transacting payments in the same way, regardless of how the consumer chooses to pay. Similarly, merchants can use the same back-end tools for tasks like reporting, chargeback management, fraud analytics and more.