Why Web Push Provisioning is a Win for Developers
- Michał Stachera
- 4 days ago
- 5 min read
Before a card ever reaches a digital wallet, it undergoes a transformation known as tokenization. At its core, tokenization is the process of replacing sensitive data-like your 16-digit Primary Account Number (PAN) - with a unique, non-sensitive identifier called a token.
In the payment world, this token acts as a digital stand-in. It allows the transaction to be processed without ever exposing the actual card details to the merchant or over the airwaves. If a token is intercepted, it is useless to a hacker because it is mathematically bound to a specific device (like an iPhone) or a specific merchant.
This security foundation is what makes modern mobile payments possible, and it is the "secret sauce" behind the latest shift in fintech: Web Push Provisioning.
Why Web Push Provisioning Matters
For years, if a developer wanted to help a user move their tokenized card into a digital wallet securely, they had to build a native mobile app. This was known as In-App Provisioning.
Web Push Provisioning (WPP) breaks that wall. It allows developers to trigger the "Add to Wallet" flow directly from a web browser (Safari or Chrome). By leveraging the same EMV tokenization standards used in apps, WPP enables a secure, encrypted handshake between a website and a mobile OS, bypassing the need for an App Store download entirely.
The Implementation: A "Light Lift" for Developers
One of the most appealing aspects of WPP is that implementation is a fairly straightforward and light lift for card programs. It includes integration into existing APIs as well as Apple and Google wallets without the overhead of native mobile development.
At a high level, this integration requires two main components:
Front-End: Adding a specific JavaScript Library to your web page to handle the user interface and the trigger to the mobile OS.
Back-End: Integrating with your card issuer’s APIs to deliver the necessary parameters (the encrypted token bundle) to the provider.
Because WPP uses standard web protocols, developers can avoid the "App Store tax" on time and resources, often moving from sandbox to production in a fraction of the time required for native apps.
How Web Push Provisioning Works
At its technical core, Web Push Provisioning acts as a secure bridge between the stateless nature of the web and the highly secure environment of a mobile operating system.
When a user initiates the process by clicking an "Add to Wallet" button, your frontend triggers a request to your backend to fetch a unique, encrypted provisioning bundle from the card issuer. This bundle - which contains the tokenized card data - is then passed to a platform-specific JavaScript library (such as ApplePayJS). The browser then hands off the process to the device's native OS, which displays a secure overlay for the user to confirm the addition via biometrics.
This seamless transition ensures that sensitive card information is never exposed to the browser or the merchant's servers, maintaining a high security standard while providing a frictionless user experience.
The Developer Advantage
1. Eliminating "App Fatigue"
Users are increasingly reluctant to download a new app for a single task. WPP allows you to provide a "Top of Wallet" experience the moment a user finishes an application or receives a virtual card, right from their browser.
2. Lower Maintenance & Unified Codebase
Instead of maintaining separate Swift (iOS) and Kotlin (Android) libraries for card provisioning, developers can manage a single web integration. This reduces technical debt and ensures a consistent experience across different devices.
3. Instant Revenue
In fintech, "Time to First Spend" is a vital metric. By allowing a user to provision their card immediately after approval via the web, you remove the friction of app installation, leading to higher activation rates and faster transaction volume.
Comparing the Provisioning Landscape
Feature | Manual Entry | In-App Provisioning | Web Push Provisioning |
Security | Low (PAN exposed) | High (Tokenized) | High (Tokenized) |
UX Friction | High (Manual typing) | Medium (App download) | Low (One-click) |
Dev Complexity | Low | High (Native SDKs) | Medium (Web + API) |
Best For | Legacy systems | High-frequency apps | Instant issuance & Web-first brands |
Critical Considerations
While the "lift" is light, developers must still navigate a few guardrails:
Domain Verification: You must prove ownership of your domain to Apple and Google via hosted configuration files (e.g., .well-known directories).
Strict UI Compliance: Both wallet providers have rigid branding requirements for the "Add to Wallet" buttons; these must be followed exactly to pass review.
Secure Backend: Your backend must be capable of handling the PGP encryption required to wrap the tokenized data before it is sent to the browser.
To get your Web Push Provisioning (WPP) integration out of the sandbox and into production, you have to satisfy the "trust" requirements of Apple and Google. Since you are essentially asking the OS to handle financial data on behalf of your website, domain verification is non-negotiable.
Here is a developer’s checklist to ensure your domain is ready for the "Add to Wallet" handshake:
1. SSL/TLS Requirements
[ ] HTTPS Everywhere: Your site must be served over a secure connection. Self-signed certificates will not work; you need a certificate from a trusted Certificate Authority (CA).
[ ] TLS 1.2 or Higher: Ensure your server supports modern security protocols. Older versions (TLS 1.0/1.1) are usually rejected by wallet providers for security reasons.
2. Apple Domain Verification (Apple Pay JS)
[ ] Register the Domain: Log into your Apple Developer Account and register your top-level domain and any subdomains where the button will appear.
[ ] The .well-known Path: Create a directory in your web root named .well-known.
[ ] Host the Association File: Download the apple-developer-merchantid-domain-association file from Apple and host it at:
https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association
[ ] Verify Accessibility: Ensure the file is publicly accessible and not blocked by a firewall, IP allow-listing, or a "Coming Soon" splash page.
3. Google Pay Merchant Center Setup
[ ] Business Profile: Register your business in the Google Pay Business Console.
[ ] Whitelisting URLs: Add your fully qualified domain names (FQDNs) to the "Allowed Domains" list in the Google Pay API settings.
[ ] Origin Validation: Ensure your server sends the correct Allow-Origin headers if you are making cross-origin requests for the provisioning payload.
4. Brand & UI Compliance
[ ] Button Assets: Do not host your own "Add to Wallet" images. Use the official CSS/SVG assets provided by Apple and Google to ensure they scale correctly and match their brand standards.
[ ] Visibility Logic: Implement logic to show the Apple button only on Safari/iOS and the Google button only on supported Chrome/Android environments.
5. Backend "Handshake" Readiness
[ ] Merchant Identity Certificate: For Apple, ensure your backend is using the Merchant Identity Certificate (.pem or .p12) to sign the session request when calling the onvalidatemerchant event.
[ ] CORS Policy: Verify that your API allows requests from your specific web domain.
Pro-Tip: The "Redirect" Trap! If your .well-known URL redirects (e.g., from http to https or adding a www), some verification crawlers might fail. It is best to ensure the file serves a 200 OK status directly at the requested URL.
The Bottom Line
The distance between "card issued" and "first transaction" is the ultimate metric for success. For years, developers were forced to choose between the high friction of manual card entry or the high development cost of native mobile apps. Web Push Provisioning (WPP) has emerged as the bridge, allowing developers to deploy secure, "top-of-wallet" experiences directly from the browser. By combining the ironclad security of tokenization with the universal reach of the web, developers can now put cards into users' hands (and wallets) faster than ever before.
