Skip navigation
All Places > Merchant Solutions - (Digital Payments, Enterprise, Apple, Android, Docs) > Blog > 2017 > April

Apple Pay on Vantiv

Posted by gjsissons Apr 13, 2017

Why one size does not fit all (and you wouldn’t want it to!)


As payment aficionados know, Apple Pay is fast becoming an essential payment technology. While previously only applicable to NFC “tap” payments or purchases from apps adapted to Apple’s payment API, Apple’s announcement of Apple Pay on the Web is a game changer.  Want to know why?


First, there are many more eCommerce websites than payment enabled apps, and as any online merchant will tell you, abandoned shopping carts are a big issue. It’s tedious to key in credit card and shipping details on a phone, and Apple Pay on the Web promises to solve this problem. By enabling the convenience of one-touch payment from Apple devices on mobile-friendly websites, merchants can potentially increase conversions, and simplify the secure exchange of customer data. By providing customers with a more convenient purchase experience, they are more likely to actually use that iOS Wallet app they may have ignored up until now. With Apple shipping approximately 4.6 million new iPhones every week, that’s a lot of potential customers and payments waiting to happen.


Apple Pay and how it works


Before we get into how a merchant can benefit from this technology, a quick primer is in order to explain what Apple Pay is and how it works.  Apple Pay is both a payment technology and a feature on the latest iPhones and Apple Watch. Payment card details can be stored in a wallet app on iOS, enabling consumers to pay in different ways:


  • In-Store – using the NFC/Tap capabilities built into newer Apple devices
  • In-App – enabling one-touch payment from Apple Pay enabled iOS apps
  • And now with iOS10, On-the-Web  – enabling eCommerce websites to recognize Apple Pay capable devices running Safari, and offer Apple Pay as a form of payment


From a “payment geek’s” perspective, underlying all of these payment approaches is a payment token, referred to by Apple as a Device Primary Account Number (we call it a DPAN) stored in the secure element on the Apple device.  The DPAN is not generated by Apple – rather it is generated and vaulted by the credit card company or their token-service provider (TSP) on behalf of the card issuing banks. A one-time exchange occurs when the payment card is initially loaded into the iOS Wallet and the real Primary Account Number (PAN) is exchanged for the DPAN. Apple does not retain your PAN and has no way of obtaining it.


The DPAN looks and feels like a real PAN to merchants and intermediaries in the payment process, but it cannot be used to make a purchase like a real credit card number. The DPAN is sometimes referred to by payment processors (like Vantiv) as the “Network Token,” given that it is issued and handled by the card networks. Along with the storing the DPAN, an Apple Pay enabled device dynamically generates a one-time cryptogram based on the DPAN for each transaction based on transaction specific data. This is packaged along with other information into a PKPaymentToken – essentially an encrypted package that contains the DPAN, the one-time cryptogram, and additional information. What makes this method of payment so secure is that even if the PKPaymentToken is intercepted and decrypted, it is useless to a would-be thief.


What happens when merchants receive the token?


From a merchant (and developer) perspective, the magic starts when the application receives the PKPaymentToken from Apple. Things can get complicated at this point because merchant systems are diverse. If a merchant has an established business with an eCommerce channel, chances are good that Apple Pay is not the only method of payment they accept. They probably already accept credit cards, debit cards, and perhaps other methods of payment like eChecks, PayPal™ or Android Pay™.  Also, they likely have a substantial sunk investment in their online store and the various software interfaces and operational processes that surround it such as:


  • Order management and& inventory systems
  • PCI assessments and audits
  • Reporting and analytic applications
  • Security technologies including encryption and tokenization


As just one example, a merchant may already be using a tokenization technology like Vantiv eProtect™ to help secure their storefront and reduce PCI scope.  What do they do with another token format like the Apple token? How do they integrate it, certify it, and how will it affect the merchants’ operations?  Merchants can’t overhaul their payments infrastructure whenever a new method of payment appears.  Not only is this costly and disruptive, but it’s risky, and impacts their time to market.


Accepting Apple Pay your way


When it comes to payment solutions, one-size does not fit all. Merchants need flexibility; and agile integration approaches that work with what they already have. To simplify integrations, and minimize disruption to existing environments, Vantiv provides multiple Apple Pay integration methods. These are in addition to multiple Apple Pay in-store solutions offered by Vantiv and our partners.


eProtect integrations – Vantiv eProtect is a technology that helps secure cardholder data at the initial point of capture and on an ongoing basis. This can help reduce PCI scope and protect merchants. In the event of a breach, sensitive cardholder data can’t be compromised, because the merchant is never actually in possession of the data. Vantiv eProtect provides a seamless Apple Pay integration method for both in-app and on-the-web  Apple Pay purchases:


  • In the case of Apple Pay In-App integrations using eProtect, on receipt of the Apple PKPaymentToken, the eProtect service is called directly from the iOS app to exchange the PKPaymentToken for the eProtect low-value token. From that point on, there is no change in how payments are processed. Back-end systems simply process the payment using eProtect as they would any other payment. Vantiv handles all the details of decrypting the PKPaymentTtoken, vaulting the DPAN, and processing the transaction through the card networks.
  • For Apple Pay on the Web users, eProtect integrations are simpler still. The eProtect JavaScript that implements the secure capture of payment information is enhanced so that Apple’s “Pay” button is presented on appropriate devices with only minor modifications to existing JavaScript. Apple Pay transactions are handled transparently by eProtect as if they were any other eCommerce transaction with no impact on back-end systems.


Direct handling of the Apple Token – Merchants using an application that does not include tokenization likely accept payment details on their SSL protected website, and relay it over a secure connection to Vantiv, being careful to abide by PCI rules governing how cardholder data is handled. Normally, merchants accepting payments in this manner who want to support Apple Pay would need to adapt software on their systems to decrypt the PKPaymentToken, extract the DPAN and cryptogram themselves, and make software modifications as necessary submit the DPAN to the networks as if it were a regular card transaction.


To avoid this complexity, Vantiv provides the option of accepting the encrypted PKPaymentToken directly as part of a payment transaction using an Apple Pay extension to our LitleXML specification. While this integration method has some impact on existing systems, it is significantly less effort than requiring the merchant to decrypt and parse the contents of the token themselves. This same approach works identically for both Apple Pay In-App and Apple Pay on the Web, providing an easy integration method for customers not using Vantiv’s eProtect with tokenization.


Merchant decryption of the payment token – In other cases, merchants may have good reasons to want to decrypt the tokens themselves. For example, their back-end systems may use the PAN in some fashion to recognize repeat customers or perform reporting or analysis. Vantiv supports this method of integration as well. While decrypting and parsing the token takes a little more effort on the part of the merchant, Vantiv’s software interface allows the DPAN to be used in place of the regular PAN and provides a facility for the cryptogram to be included in the transaction in a fashion that has minimal impact to existing back-end systems.


This method would typically be used by merchants integrating Apple Pay with Vantiv’s core processing systems. This method of integration works also with Apple Pay In-App as well as Apple Pay on the Web on our eCommerce platform.


Learn more at Vantiv O.N.E.


For merchants implementing Apple Pay, flexibility is critical. By choosing a method of integration that minimizes impact to existing systems and processes, integrations can be done faster, at a lower cost and with less technical and business risk. Also, you can position yourself with a payment infrastructure easily able to accommodate other payment methods in future.


To learn more about Vantiv, eProtect, Apple Pay, and the various integration approaches described here, visit Vantiv O.N.E. at  and create your free account to access the Vantiv O.N.E. Apple Community.

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 logo.JPGAndroid 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.


To learn more about Vantiv and Android Pay, join Vantiv O.N.E. and visit the Google Community. We welcome your thoughts, questions and participation!

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!