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 very ideal for all subscription businesses, because it can result in involuntary churn.
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.
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.
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).
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.
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.
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
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.