On this page

If you are among the 2 billion people worldwide who use Apple Pay or Google Pay, you may have set up your payment credentials for subscriptions or recurring payments on a merchant’s eCommerce site. When these credentials are configured for payments, they are device tokens (DPANs). Card schemes, such as Visa, Mastercard, and American Express, use DPANS linked to a mobile device to represent each unique card number when a card is added to Apple Pay or Google Pay.

DPANS can be used for recurring bill payments and subscriptions through standing instructions. Merchant-initiated transactions (MIT) utilizing DPANS are also employed to describe this scenario.

Recently, one of my subscriptions was cancelled, and I was not aware until I attempted to access the service. After several phone calls with customer support, it was determined that my payment was declined. When I contacted the card issuer to understand why the transaction was declined, they revealed that because I had changed my phone, my DPAN was declined.

While paying with DPANS provisioned on Apple and Google mobile devices is convenient and secure for cardholders, the fact that the associated DPANS are bound to the cardholder’s mobile device creates a few challenges, including:

  • Since DPANS are bound to the cardholder’s mobile device, a new DPAN must be issued when the cardholder changes their device. This implies that subscription transactions with the prior DPAN will be declined because it will have been deactivated.
  • DPAN transactions cannot be restricted to a particular merchant domain. This implies that unauthorized users could use a mobile device to make payments anywhere Apple and Google Pay are accepted.

Major card brands are exploring methods to minimize the impact of DPANS on MIT. Visa announced that all device-bound standing instructions with DPANS issued after July 30th, 2025, will be declined. This date has been postponed twice previously, but merchants are being advised to DPANS with merchant tokens (MPANs) for all recurring payments.

MPANS are bound to the merchant where they will be used. They provide a natural merchant domain restriction that addresses a major risk issue with DPANS. Since MPANS are bound to the merchant, they do not have to be updated when the cardholder changes their mobile device. As such, MPANS are a more secure and stable replacement for DPANS.

Transactions executed with DPANS issued before July 2025 will be grandfathered. However, Visa reserves the right to decline MITS transactions using DPANS. Merchants are advised to convert their DPANS to MPANS before July 2025.

Should merchants and other payment providers relying on DPANS for essential recurring payments be concerned? Thankfully, the answer is no. This is because ACI Worldwide and other providers in the market have created a path enabled by the card schemes to execute a seamless DPANS for MPANS exchange. This process can be executed as a one-time project or as a gradual migration.

For a one-time migration, all DPANS in a merchant’s credential-on-file database will be converted to MPANS by July 2025 for a smooth transition. This approach is preferable over gradual migration, which involves requesting MPANS during transactions and may result in declines if not completed within the timeout period.

Making the switch to merchant tokens or adding network tokens to your current payments system is easier than you think. To learn more about how network tokens differ from merchant tokens and what problems they solve, read “Important facts you need to know about network tokens — the complete guide for merchants.

Reference glossary:

TermMeaning
Device Primary Account Number or DPANA data element used to represent the actual card number that is loaded into Apple/Google Pay and is bound to a single device
Merchant Initiated Transaction (MIT)A transaction automatically generated by a merchant with payment credentials previously provided by the cardholder.
Merchant Primary Account Number or MPANA data element corresponds to the card number entered by a user into Apple/Google Pay; this data element is associated with a specific merchant, rather than the device.
Credential on FileThis feature enables merchants to store payment details, initiate payments either manually by the end user (Consumer Initiated Transaction, or CIT) or automatically by the merchant (Merchant Initiated Transaction, or MIT).

About the author

Dennis Odiwo

Global Merchant Solutions Leader

With more than 25 years of expertise in the payments industry, Dennis is a seasoned leader with a deep understanding of bank and merchant payments. He is responsible for ACI’s SaaS solutions in Europe and North America, ensuring stability, performance, functional relevance, and profitability. He plays a crucial role in driving product strategy, operational efficiency, and customer success, helping stakeholders navigate the complexities of modern payments with cutting-edge technology. Dennis enjoys spending time with his family and friends, as well as watching and playing soccer and basketball.


Product Manager – Merchant Payments

Dennis has more than two decades of experience in the merchant payments space. He leads global innovative product initiatives within ACI, such as tokenization, real-time payments, and many more that support merchants in their digital payments transformation journeys. Before ACI, he worked as a Principal Architect for S1, which ACI later acquired. Dennis is passionate about technology, payments and sports.