Whenever a customer makes an Applepay payment a unique network token called a DPAN (Device Primary Account Number) is created and stored securely on the customer’s Apple device. This token acts as the payment information for all purchases and keeps the raw card number safe from bad actors.
However, Apple Pay’s DPAN (Device Primary Account Number) may not be ideal for all subscription businesses, because it can result in involuntary churn.
Possible causes for such involuntary churn
Device stickiness
The DPAN is always tied to a specific device. If the user switches devices or upgrades their phone, the DPAN is subject to change. And can lead to payment failures if your subscription business relies on the previous DPAN, requiring the customer to update their payment details.
Customer updates payment method
If the customer updates the credit card, the recurring payment tied to the DPAN becomes irrelevant. Because DPAN does not support the updation of stored payment method data for the specific subscription.
Lack of portability across processors
Exporting/importing credit card data is quite seamless with most payment processors. However, in the case of Apple Pay cards, not all payment processors support import and export seamlessly.
This can create a potential disruption in your subscription business that is very much dependent on Apple Pay cards. Here is an example of a payment processor that does not support import (example Stripe) and one that supports import (example Braintree).
Cross-platform flexibility
Digital Subscriptions often require cross-platform flexibility (web, mobile, tablet and television). But DPANs are very specific to Apple devices. This limits the usage across non-Apple platforms making the system less versatile.
How to adapt your ApplePay Strategy to reduce involuntary churn?
Migrate from ApplePay DPANs to MPANs
Apple Pay now supports MPAN (Merchant PAN) which allows tokens to be device agnostic and stay relevant even if the customer updates the payment method. Also, as the name suggests, the tokens are scoped to the Merchant, rather than the Device (as in the case of DPAN).
Work with a certified token service provider to get ApplePay MPAN implemented for your business.
The TSP will offer the latest ApplePay experience which includes the metadata and ApplePay payment sheet updated for recurring payment acceptance
The TSP will also have to expose two endpoints for
- Token update - to receive and handle merchant token life-cycle updates from Apple Pay. Some TSPs may provide a wrapper payment method token which takes care of token life-cycle updates under the hood. This can significantly reduce the tech implementation effort for your business during the migration process
- Token invalidation - to invalidate the the recurring payment whenever the customer voluntarily cancels the subscription
As a subscription business, you will have to implement the invalidate token API to enable customers with subscription cancellation
Portability of ApplePay tokens
As your subscription business grows, you may wish to smart route Apple Pay recurring payments to an alternative payment processor for either improving auth rates, or to reduce cost of payments. Or you may wish to move from one payment processor to another for a better performance or cost advantage.
For authorization rate improvement or churn prevention you may want to retry the ApplePay transaction with an alternate PSP. However, this could be done only if you have implemented the flow of pre-decrypting the ApplePay token before authorization with PSP. Most PSPs support both flows (i) using PSP token for ApplePay, and (ii) using a pre-decrypted ApplePay token (for example, Checkout.com supports for both flows)
While migrating from one PSP to another, if the payment processor does not support seamless import/ export of Apple Pay payment method data (DPAN and Network Transaction Identifier) it might hamper your business continuity for recurring payments. Hence, consider using a neutral payment platform which allows
- Seamless import/ export of Apple Pay payment method data
- Support vaulting of Apple Pay tokens to process the payment with any payment processor
- PCI compliant to handle sensitive card information for de-tokenization and re-tokenization
Support QR code based payment links for non-apple platforms
In case you have a business requirement for supporting Apple Pay payments for devices that are not compatible with ApplePay (such as TV, Tablets etc.,) you may consider implementing a QR scan based payment link.
The user can scan the QR code through an Apple device and complete the payment using Apple Pay.