Merchant Features
Discover the benefits, enablement steps, and
resources to get started.
Merchant Tokens (MPANs)
Seamless recurring and deferred payments
Merchant Tokens — also known as Apple Pay Merchant Primary Account Numbers (MPANs) — enable secure, uninterrupted transactions across millions of merchants on the web and in apps. Because tokens operate independently of the underlying financial account, payments continue even after a card is reissued. Provide consumers with clear pricing and billing details in the Apple Pay payment sheet and Apple Wallet — with lifecycle management notifications to help you resolve payment issues before the next billing cycle.
Supported transaction types
Merchant Tokens are designed to support a wide variety of transaction types on the web and in apps. This allows merchants to easily and securely manage:
- Recurring subscriptions: Payments with a fixed amount and set frequency, such as monthly gym memberships or a streaming service monthly plan.
- Recurring billing: Payments with a set frequency and variable amount, such as a utility bill.
- Automatic reloads: Payments that automatically replenish a balance. These can be time‑based (with a variable amount and fixed frequency) or threshold‑based (with a fixed amount and flexible frequency), such as for transit card top‑ups.
- Deferred payments: Payments where the charge(s) are delayed until a much later date — for example, a hotel booking for a stay a month later. In some cases, a deferred payment authorization can include additional charge events — such as incidental expenses charged during or after a hotel stay — where the exact final amount may be unknown at the time of the initial commitment.
- Installment repayments: Payments that allow a consumer to divide a purchase into smaller, scheduled payments of a fixed amount, occurring at a set frequency over a defined period.
Consumer experience
Supported by the majority of global payment networks, Merchant Tokens enable functionality for a variety of transaction types across various cardholder touchpoints:
At checkout
In Apple Wallet
Get started.
Enable Merchant Tokens (MPANs)
Plan
Review the payment models offered to your consumers. For each payment model that is not a standard one‑time transaction, map it to the relevant Apple Pay payment request type.
recurringPaymentRequestWeb | App- Subscriptions (examples: digital content, streaming services, membership programs)
Same transaction amount at fixed regular intervals - Recurring billing (example: utility bills)
Variable transaction amount at fixed regular intervals - Installment loan repayments (example: buy now, pay later loans)
Single purchase paid over a fixed number of regular installments
automaticReloadPaymentRequestWeb | App- Automatic reloads (examples: balance top‑up for transit, stored value cards)
Funds added to a specific account, triggered by a pre‑determined threshold
deferredPaymentRequestWeb | App- Deferred payments (examples: car hire, hotels with incidental charges)
Deferred or fixed date charge, with one or more supplemental charges
- Subscriptions (examples: digital content, streaming services, membership programs)
- Design the approach that best fits your transaction types.
- Review the information to be displayed in the payment sheet for each payment model.
- Ensure that the billing agreement is clear and concise, consistent with the one displayed on your website or app, and contains the relevant information needed for the consumer to understand what they are agreeing to when authorizing payment.
- Follow the Human Interface Guidelines.
- Review best practices relating to the transaction types you will be offering.
- Review the Apple Pay Merchant Token Management API.
- Consider how this can integrate into your solution to ensure payment continuity with lifecycle events and be used to share upcoming and past payments with consumers directly within Apple Wallet.
- Follow Merchant Token best practices, including lifecycle event handling, token usage, recovery, and user experience.
- Experiment with the Apple Pay on the Web Interactive Demo. Select recurring, automatic reload, and deferred payment requests to learn more about the information displayed in the payment sheet in a live example.
Build
- Include the additional fields for each payment request type you support. Reference the technical documentation in the implementation steps above.
- If you are working with a payment service provider to decrypt your Apple Pay payload, work with them to retrieve the merchant token identifier from the payload for lifecycle management updates. Refer to the Apple Pay Merchant Token Management API for more about lifecycle management.
- Follow best practices for payment setup.
- Set up a web service that can receive the lifecycle update events using the Apple Pay Merchant Token Management API.
- Extend your web service to include the ability to send token usage information directly to the consumer’s Apple Wallet app, keeping them informed of any past or upcoming charges.
Test
Once Merchant Tokens functionality has been integrated, test your integration to ensure that all stages of the payment experience work as expected. This includes:
- Verifying payment information: For each payment model you offer, ensure the relevant information is displayed in the payment sheet.
- Detecting the token: When the decrypted Apple Pay payload contains the
merchantTokenIdentifierandmerchantTokenMetadatafields, ensure these values can be stored in your internal systems for use with the Apple Pay Merchant Token Management API. - Storing payment data: Confirm you or your PSP can store the merchant token, as well as the Transaction or Trace ID from the original transaction for any follow‑on transactions.
- Triggering a Lifecycle event: If using the Apple Pay Merchant Token Management API, revoke the payment authorization in Wallet and ensure your web service receives the event notification. Use the event notification to retrieve the event details.
- Sending token usage packages to Apple Wallet: Provide details about the consumer’s purchase, including a description and upcoming charge dates. Confirm that the token usage package is sent and that updated information is correctly displayed in the consumer’s wallet. Refer to Apple Pay Merchant Token Usage Information API for details.
Launch
Optimize
Explore the resources
Guides and guidelines
Documentation
Videos
Payment request type documentation
For web
For apps
Frequently asked questions
Merchant Tokens (also known as Apple Pay Merchant Primary Account Numbers or MPANs) are network tokens designed to facilitate recurring transactions on the web and in apps. These transactions can include subscriptions, recurring billing, automatic reload of balances, deferred payments, and installment loan repayments. For all other types of transactions — including one‑time payments — merchants will continue to use a DPAN.
For more information on recurring payments, MPAN creation, and authorization flows, refer to the Apple Pay Platform Integration Guide (for issuers) and Apple Pay Merchant Integration Guide (for merchants).
MPANs are supported by the majority of global payment networks. As of January 2026, these five networks support MPANs: American Express, Discover, JCB, Mastercard, Visa. If your network is not listed here, reach out to them for the latest information on when it will be supported.
MPANs help facilitate automatic or recurring payments and ensure payment continuity over extended periods. Unlike DPANs, which are specific and unique to the Apple device they reside on, MPANs are not dependent on the continued use of a single device.
In addition, Apple supports APIs and processes that notify merchants about modifications to MPANs over time (for example, by notifying merchants about updates to the MPAN’s expiration). By keeping merchants apprised of such events, Apple helps facilitate an improved user experience, as well as an enhanced operational performance for both merchants and issuers.
This feature can be enabled as part of a new or existing Apple Pay implementation. As with other Apple Pay features, Apple does not charge implementation fees for its enablement.
If an issuer has not implemented MPANs, a DPAN will be returned instead. The cardholder still benefits from the enhanced payment sheet, but the transaction will be processed with a DPAN, and the transaction will not be visible to the cardholder within the Preauthorized Payments view only within Apple Wallet.
Upon their creation, MPANs are assigned an expiration date with specific rules and durations (varying by payment network). When an MPAN’s expiration date approaches, its issuing payment network uses existing Lifecycle Management APIs to communicate the new expiration date to Apple. Apple then transmits this new expiration date to the corresponding merchant using the Apple Pay Merchant Token Management API, ensuring that future merchant‑initiated transactions (MITs) can continue to process successfully.
MPANs are unaffected if the underlying card is reissued due to natural expiration or a lost/stolen event. If the new physical card brings different metadata, for example card art and/or last 4 digits, the merchant will be notified that MPAN metadata has changed so they can update their representation of the payment method. Card Art updates are shared with merchants via MPAN lifecycle management APIs.
Cardholders can revoke or delete a specific MPAN in Apple Wallet on their iPhone or in the Settings app on their iPad. This action won’t cancel a subscription or service, but it will invalidate the MPAN for future charges.
Merchants and issuers may provide their cardholders with other channels (apps, websites, contact centers) to cancel subscriptions and/or delete payment methods. These can also lead to the deletion of an MPAN.
The MPAN will not be affected if a cardholder has a Device Primary Account Number (DPAN) set up on an Apple Pay‑eligible device for a specific card, and then deletes the DPAN from the device after an MPAN has been created.
Recurring (for example, TV streaming plan subscriptions or utility bills), automatic reload (like balance top‑ups for transit), installments (such as buy now, pay later loans), and deferred payments (like hotel bookings) are all supported. For details, refer to Enable Merchant Tokens in MPANs for merchants. Outside of these supported use cases, MPAN cannot be used for unscheduled card on file (UCOF). Any time a cardholder is actively making a one‑time purchase decision, a DPAN‑based Apple transaction flow should be used.
MPANs are automatically requested when using a supported transaction type in Apple Pay. To enable MPANs, include the relevant information in your payment request using one of the below:
recurringPaymentRequest Web | App
automaticReloadPaymentRequest Web | App
deferredPaymentRequest Web | App
For additional information on when to use each of the transaction types above, refer to Get Started above.
MPAN checkout functionality is supported on iPhone, iPad, Mac and Vision Pro, starting in iOS 16.0, iPadOS 16.0, macOS 13.0 and visionOS 1.0.
The Apple Pay Merchant Token Management API functionality is supported starting in iOS 16.0, iPadOS 16.0 and visionOS 1.0; support for additional features, as well as UI enhancements, is available starting in iOS 18.4, iPadOS 18.4, and visionOS 2.4.
When an MPAN is deleted, Apple will send a lifecycle event notification to the tokenNotificationURL provided during the original payment. To ensure you receive these important lifecycle events, you will need to integrate a web service using the Apple Pay Merchant Token Management API.
In the decrypted Apple Pay payment token look for the merchantTokenIdentifier and merchantTokenMetadata values. These values will only be present for an MPAN. The merchantTokenIdentifier value uniquely identifies an MPAN and will be referenced in MPAN lifecycle events. Most merchants will not have access to the decrypted Apple Pay payment token and will need to work with their PSP to identify an MPAN.
No, if a consumer revokes an MPAN and wants to fully terminate the contract, they can visit the merchant website (or follow any merchant‑provided instructions) to manage the contract.
Most Apple Pay transactions are eligible for liability shift, including MPANs. To learn more, refer to Apple’s Fraud Protection for merchants.
Both MPANs (Apple Pay Merchant Tokens or Merchant Primary Account Numbers) and APANs (Account Primary Account Numbers) are network‑issued payment tokens. However, they differ in fundamental ways. An MPAN is always associated with a specific merchant, while an APAN is associated with a cardholder’s Apple Account. For more about MPANs, refer to Apple Pay Merchant Tokens for issuers.
Join the Apple Pay platform.
Recurring payments
Installment loans
- Each new loan agreement must present a new payment sheet.
- Present the number and amount of each payment.
- Display past and upcoming payments in Wallet when sending the token usage information to keep the consumer informed of payments they have made and how many remain.
Subscriptions
- For fixed amount and frequency subscriptions, display payment interval and timing details in both the
regularBillingobject andtotalobject. This displays those transaction details at the bottom of the payment sheet. - Highlight free or paid trial periods (if offered) using
trialBillingalongside theregularBillingto display these on the payment sheet. TheTotalshould match the first charge the consumer can expect.
- For mixed baskets containing subscriptions alongside one‑time purchases, display the subscription details in the
regularBillingobject and set thetotalto include the amount for all items in the first charge. Use the Line Items to show how this first charge is broken down.
Payment setup
Follow payment networks guidelines for CIT (customer‑initiated transactions) or MIT (merchant‑initiated transactions) framework, and adhere to the right values in the authorization messages. Refer to Mastercard and Visa articles, or to your Payment Service Provider (PSP), for additional details.
Optimize your retry mechanism for Apple Pay Merchant Tokens for MITs with a recoverable decline (like insufficient funds).
Merchant Token best practices
Lifecycle event handling
- Merchants will be notified via lifecycle management APIs if:
- the Merchant Token is revoked by the consumer or by the issuer, or
- card metadata (card art, expiration date, or Funding Primary Account Number [FPAN] suffix) is updated.
- Consider how to handle different lifecycle events to proactively resolve payments issues. For example, when a consumer revokes the payment authorization on a token, trigger a notification to the consumer to update their payment details before the next billing cycle commences.
- Send an unlink request to invalidate that token for future use when a consumer cancels a recurring transaction on your website or in your app.
Token usage
- Provide clear, comprehensive payment information directly through Wallet using the Apple Pay Merchant Token Management API (Token Usage Information API section). Sharing detailed information about past, recurring, and upcoming payments gives consumers visibility into their transactions and helps them instantly recognize and understand each payment.
- Pre‑notify consumers of their upcoming payment to reduce the risk of transaction declines due to insufficient funds.
- Inform consumers of any recently completed payments by including them as part of the
pastPaymentobject, helping the consumer keep track of their recent transactions.
Recovery
- When a merchant token is invalidated:
- Allow the consumer to provide an alternate payment method or to modify their purchase.
- Proactively notify consumers and Apple Pay about active subscriptions or transactions. If notified when a Merchant Token is declined, Apple Pay can redirect the consumer to the merchant site to fix the payment issues.
- Merchants should have Apple Pay as an option in all payment recovery flows for better conversion and payment retention.
User experience
- Display the web or app icon representing your business to give consumers visual reassurance that their payment is going to the right place. Refer to Human Interface Guidelines for details on summary view and payment sheet.
- Use a universal link for the
managementURLin the payment request to direct a consumer to a page in the app (if they’ve installed the app) or to a page on the merchant’s website. For more information on adopting universal links, refer to Allowing apps and websites to link to your content. ThemanagementURLmust be a page where the customer can manage the payment method associated with their purchase. It should not be a generic landing page.
Deferred payments
- Show consumers a description of the future charge, charge date, and amount in the Apple Pay sheet. Include a free cancellation date when available.
- Display the payment date and amount in Wallet when sending the token usage information by including it in the
DeferredPaymentDetails.
Automatic reloads
- Allow consumers to set the threshold amount prior to launching the payment sheet.
- Display the threshold amount in Wallet when sending the token usage information by including it in the
AutomaticReloadPaymentDetails.
Continue to maximize your Apple Pay integration
- Monitor key metrics, including:
- Payment sheet presentation success rate
- Authorization completion rate
- Error rates by type
- Payment success rate
- Follow Apple Pay partner news and updates for the latest:
- Announcements
- Features
- Success stories
- Tech notes
More resources
Apple Pay Demo
in an interactive playground.
Apple Developer
build apps for Apple platforms.
Apple Business
presence across Apple apps.
-
In the US, Apple Pay is a service provided by Apple Payments Services LLC, a subsidiary of Apple Inc. Neither Apple Inc. nor Apple Payments Services LLC is a bank. Any card used in Apple Pay is offered by the card issuer.
-
Apple Pay is not available in all markets. View Apple Pay countries and regions.
-
Features are subject to change. Some features, applications, and services may not be available in all regions or all languages and may require specific hardware and software.