Apple Web Push Provisioning: What Comes Next After Integration?
Your Apple Web Push Provisioning integration is live, end-to-end testing was a success, and the solution has passed official certification at an accredited lab like Fime. It might feel like the heavy lifting is out of the way. However, one crucial operational phase remains: configuring the card presentation UI displayed to the end user during the Apple Wallet provisioning flow.
In classic app-to-app Push Provisioning, issuer card art and product configurations are typically managed centrally via the Mastercard Digital Enablement Service (MDES) or the Visa Token Service (VTS). It is natural to assume that the artwork residing in MDES or VTS will automatically be used during Web Push Provisioning. Unfortunately, Apple’s ecosystem operates differently.
Separate Card Art Configuration on the Apple Portal
During Web Push Provisioning, Apple requires issuers to supply a pre-registered card template identifier registered within Apple's environment. In Apple’s PassKit framework documentation, this parameter is designated as cardTemplateIdentifier.
This is not the card art ID configured in MDES or VTS. Apple mandates an identifier generated directly within its own ecosystem. Consequently, even if your card design has been fully approved by the payment network (Scheme), it still requires an additional visual configuration step with Apple.
The workflow begins by creating a Card Art asset in the Apple Register portal. There, you configure the card art background, network logos, partner/brand logos, color schemes, and app icons.
Next, you generate a Card Template, to which Apple assigns a unique UUID (cardTemplateIdentifier). You must store this UUID, map it to the corresponding card product, and pass it in the request payload when initializing the Web Push Provisioning flow.
Crucially, Apple does not provide a public API for programmatic Card Art and Card Template management. Setting this up manually for a single visual asset is straightforward and takes only a few minutes. However, complexity scales quickly when supporting multi-tenant setups, multiple currencies, co-branded products, and varied design variants. Every new template requires preparing visual assets, manually configuring the portal, capturing the generated UUID, mapping it to your backend product catalog, and running verification tests.
Why Isn't the MDES/VTS Visual Asset Enough?
Apple requires visual card assets before the actual tokenization process finishes. Because the user needs to see a realistic representation of their card the moment the Web Push Provisioning sheet opens, Apple loads its own local Card Template initially.
The artwork hosted on MDES or VTS comes into play later. Once tokenization is authorized, the Token Service Provider (TSP) pushes the digitized token payload, product metadata, and final card visual asset to Apple Wallet.
In practice, this creates a two-layer visual process:
Initial Provisioning Sheet: Driven by Apple’s web portal configuration (cardTemplateIdentifier).
Post-Tokenization State: Delivered dynamically by MDES or VTS once the token is active in Apple Wallet.
If these configurations are not aligned, the user experience suffers - they might see one card design during the provisioning prompt and a completely different design once the card settles into Apple Wallet.
If you don't need to present a highly tailored card variant at the very start of the flow, you can initialize the process using a generic, approved asset template. Once tokenization completes, Apple Wallet can fetch the final card art directly from MDES or VTS. While this fallback approach simplifies initial setup, you must verify that the final artwork is correctly configured with the Token Service Provider. If it is missing from MDES/VTS, the card may permanently retain the temporary asset used during the Web Push Provisioning stage.
Managing Apple Pay and Google Pay in a Single Card Program
When launching a card program supported across both Apple Pay and Google Pay, configurations must be coordinated across multiple platform environments.
Mastercard products rely on MDES, while Visa products rely on VTS. Adding Apple Web
Push Provisioning introduces an additional layer: managing Card Art and Card Templates in the Apple Register portal. As a result, a single card product will hold distinct IDs and visual assets across payment schemes and Apple's portal.
Best Practices for Multi-Platform Asset Management
Maintain a Single Source of Truth: Create one master set of approved high-resolution design assets, then export platform-specific renditions for Apple, MDES, and VTS according to their exact aspect ratios and compression rules.
Maintain an Asset Mapping Registry: For multi-program or BIN-sponsor setups, keep a centralized matrix capturing:
Client / Partner Name
Product & BIN Range
Payment Network (Mastercard / Visa)
MDES / VTS Asset IDs
Apple cardTemplateIdentifier (UUID)
Design Version & Deployment Status
Keeping a synchronized registry prevents cross-mapping UUID errors and ensures updates are never applied to one environment while being forgotten in another.
Apple Web Push Provisioning: Summary
Apple Web Push Provisioning allows cardholders to add payment cards to Apple Wallet directly from a web browser without installing a native mobile app or entering card details manually. While it offers a frictionless UX for the consumer, it introduces specific backend and operational configurations for issuers and FinTechs.
Beyond core API integration and lab certification, you must configure Card Art and Card Templates in the Apple portal, capture the generated cardTemplateIdentifier UUID, pass it during initiation, and align it with your TSP assets in MDES or VTS.
At Sparados, we have hands-on experience navigating this end-to-end process. We help FinTechs, issuers, and paytechs implement Apple Web Push Provisioning, manage complex tokenization workflows, and launch seamless Apple Pay and Google Pay programs. Whether you need technical integration support or guidance on operational readiness, our team is ready to help.
FAQ
Is MDES/VTS card art enough for Apple Web Push Provisioning?
No. Apple requires its own cardTemplateIdentifier to display the card during the initial web provisioning UI. MDES or VTS delivers the permanent card art only after tokenization completes.
What is a Card Template ID?
It is a unique identifier (UUID) generated in Apple's portal when you set up a Card Template. In Apple's PassKit documentation, it is referenced as cardTemplateIdentifier.
Can we generate or customize our own Card Template ID?
No. The ID is automatically generated by Apple upon template creation in the Apple Register portal.
Does the user need to install an app for Web Push Provisioning?
No. Web Push Provisioning allows users to initiate card provisioning directly from a web browser without downloading a native iOS app.
Is the configuration process identical for Mastercard and Visa?
The Apple-side setup and Web Push flow remain similar, but the Token Service Provider layer differs: Mastercard uses MDES, while Visa uses VTS.
Sources:
