What developers need to know

Merchants selling services or digital goods on-line often employ a subscription model, where consumers are billed a set amount monthly rather than paying the full amount up front. Not only is this attractive to consumers, it helps merchants reduce sticker shock while enjoying a predictable revenue stream less affected by spikes or troughs in sales.

While consumers may think of mobile wallets in the context of tap payments at the point of sale, they are increasingly being used for in-app and mobile web purchases. With the convenience mobile wallets provide, merchants are understandably interested in using mobile wallets for subscription payments as well.

An abundance of wallet frameworks

For developers, combining subscriptions and mobile wallets can be tricky business. While issues vary by wallet provider, below are some considerations specific to Apple Pay:

Core to the security model of Apple Pay is the notion of a one-time payment token. This is attractive to consumers, because even if the payment token is compromised, the design is such that the token can't be used for a separate purchase in future. Such a scheme seems (on the surface at least) to be at odds with the idea of a recurring payment stream.

While Apple makes it clear that Fixed and Flexible Frequency Subscriptions are supported with Apple Pay (see Apple Pay description here), merchants are pointed to their payment provider for details. As developers know, the devil is often in the details!

Developers of applications involving the sale of digital goods are pointed to the In-App Purchase Programming Guide describing the use of the Apple Store Kit framework. While the Store Kit framework explains managing subscriptions through the Apple store, this may be the wrong business model for the merchant. Merchants with an existing on-line store already accepting card payments may be better served by using the Apple Pay PassKit Framework (for iOS in-app purchases) or the Apple Pay JS Framework (when adding Apple Pay to their mobile website)

Similar issues are at play for developers seeking to integrate with Android Pay. Developers have the choice of selling digital goods from within Android apps using Google Play in-app billing (which like its Apple counterpart is subscription payment friendly), using the Android Pay API for in-app payments, or the emerging W3C Payment Request API for mobile web payments. Other mobile wallets involve the use of still additional APIs depending on the mobile wallet and payments use case.

Most on-line sellers, will want to offer their consumers multiple payment methods. This means that in practice, developers may find themselves needing to support multiple frameworks to provide the richest set of payment options.

Evolving Network guidelines

In addition to fast evolving wallet frameworks and APIs, the rules around the use of stored credentials & tokenization schemes for subscription payments are evolving as well.

With its October 2016 release, VISA is implementing changes related to merchant-initiated transactions. Several of these changes will impact recurring / subscription payments using stored credentials including Apple Pay and Android Pay.

By April of 2017, installment transactions involving the use of a stored credential will need to be identified (VISA ID #0024724). Effective October 2017, initial transactions and installment transactions will need to be identified with an indicator with an indicator, and subsequent transactions in a recurring stream will need to contain the transaction identifier of the initial transaction (VISA ID #0029843). Discover is also extending their tokenization service to recurring billing transactions with similar requirements (See Vantiv Fall 2016 Network Updates – Discover Enables Recurring Billing and Partial Shipment Transactions for Tokenization).

Because of these changes related to the handling of subscriptions involving tokens, merchants may need to manage these recurring payment streams on their own until such a time as value-added software solutions that automate the handling of recurring payments catch up with network requirements.

Implementing subscription payments today

The good news is that subscription functionality with popular wallets is available today on Vantiv’s payment platforms. Vantiv can help developers can build payment enabled apps and websites that enable popular wallets to fund subscriptions while complying with network requirements.

Merchants accepting wallet payments will want to present traditional payment card alternatives as well because not all consumers will have a wallet enabled on their phone or tablet. For eCommerce merchants extending the functionality of their websites to support mobile wallets, Vantiv’s eProtect can be a good solution since it abstracts away much of the complexity of dealing with different payment types. The result is a single payments integration approach regardless of whether a consumer opts to pay with a Credit Card or via Apple Pay or Android Pay.

While eProtect is not strictly required to accept subscription payments with digital wallets Vantiv O.N.E. members can review a detailed example involving Apple Pay and Recurring Payments here. Other methods of integrations involving mobile wallets are detailed in the Vantiv O.N.E. mobile payments space in Apple Pay and Google communities respectively.