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

This article is replicated from its original location on the Vantiv O.N.E. blog, Vantiv’s site for payment application developers. You can read the original article here.

As payment aficionados know, Apple Pay is fast becoming an important 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. Why, you ask?

First, there are many more eCommerce websites than payment enabled apps, and as any on-line 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 the 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 on-line 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 to 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 applepay 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 http://developer.vantiv.com and create your free account to access the Vantiv O.N.E. Apple Community.