Your button is not the last tap
The Add to Wallet button doesn't add anything. It hands a file or a link to the operating system, and the operating system then shows its own confirmation screen with its own Add button. The real final tap happens on a screen you don't design, don't style, and don't measure by default.
On an iPhone, your button delivers a .pkpass file. iOS opens it as a full-screen pass preview with Add in the top right and Cancel in the top left. Anyone who taps Cancel, or swipes the sheet away because it looked like an ad, is still counted as a conversion by most analytics setups.
On Android, your button opens a Google Wallet save link. The customer lands in Google Wallet, sees the card, and taps Add to Google Wallet there. Same shape, same second confirmation, different app. Every fix below exists because of that second screen.
Build the pass before the tap, not after
The most common engineering mistake is generating the pass when the button is tapped. Safari on iOS is strict about downloads that start outside a direct user gesture. If your server needs two seconds to sign and zip the .pkpass, the gesture window closes, the download is dropped, and the customer sees nothing at all.
Build the pass on form submit instead. On Waya's enrollment page, submitting the two-field form (first name and mobile number) mints the pass server-side and holds the result in the page as an object URL. The Add to Apple Wallet button then appears in place of the submit button and points at bytes that already exist, so the tap is instant with no network wait behind it.
Serve it properly as well. Use the application/vnd.apple.pkpass content type, an anchor with a download attribute and a filename ending in .pkpass, and no redirect chain between the tap and the file. The download attribute only does its job on iOS 13 and later, and there's no reason to force the file into a new tab: iOS renders the pass preview inline.
Placement, wording, and the two words not to change
Put the button where the customer is already looking. Waya's enroll page swaps the submit button for the wallet button inside the same card, at the same scroll position. Throwing the customer to a separate success page costs you a re-read, and a re-read is a chance to give up.
Use the official artwork and the official wording: Add to Apple Wallet and Add to Google Wallet, each with its own badge. Renaming them to Download card or Get your pass throws away the recognition you're borrowing from the phone the customer is holding. And never write Apple Pay. That's a different product, and it makes the page look like it wants a credit card.
Show one wallet button, not two. Detect the platform from the user agent and render only the one that can work: Apple on iOS, Google on Android. A choice between two buttons is a decision the customer shouldn't have to make, and half the options are dead ends on any given phone.
If your page is bilingual, translate the verb and leave the brand alone. Waya's Arabic enroll page translates the small line above the badge and keeps Apple Wallet and Google Wallet in Latin script, because that's the exact string the customer already recognizes from their own phone.
In-app browsers are the biggest single killer
If your enrollment link lives in an Instagram bio, a TikTok profile, or a forwarded WhatsApp message, a large share of taps never reach Safari or Chrome. They open inside an embedded webview owned by that app. Those webviews handle file downloads and new-tab links inconsistently, so the pass gets built, the customer taps Add, and nothing happens.
There is no clean fix from inside a webview. What works is detecting it and printing one line of instruction: open this page in Safari from the share menu on iPhone, or from the three-dot menu on Android. Ugly, but it converts better than a button that silently does nothing.
The stronger fix is to stop routing enrollment through social links. A printed QR code on a table tent opens the phone's default browser, which is why the poster QR is Waya's primary enrollment path and the link in bio is the secondary one. Old webviews also lack browser APIs that newer code assumes exist, so the enroll page carries fallbacks for things like a missing crypto.randomUUID rather than throwing an error in front of a customer.
Desktop visitors and unsupported devices
Apple and Google differ in kind here, not in degree. A Google Wallet save link is account-based: a customer can tap it on a laptop, sign in to their Google account, and the card appears in Google Wallet on their phone. A .pkpass downloaded on a Windows machine does nothing useful, because Apple passes are added on the device itself.
So a desktop visitor should not be handed a bare Apple button as the main path. Show a QR code that reopens the same enrollment URL on the phone, and let the phone finish the job. Waya today mints both passes for desktop visitors and shows both buttons, which is honest but imperfect: the Google button works, and the Apple file is a dead end on most laptops.
For anything else, keep a plain web card as the fallback: a URL that shows the stamps and the reward with no wallet pass involved. It's the weakest version of the product. There are no lock-screen updates and no automatic refresh, so it should never be the default. It's still better than a page that ends in an error.
What to measure, and a worked example
Five events tell you everything: page opened, form submitted, pass built, wallet button tapped, and pass installed. Waya's enroll page fires page_view, form_submit, mint_started, mint_ready, and add_clicked, which is enough to separate a form problem from a handoff problem. Without the last two you'll keep blaming the form for losses that happen after it.
The install signal is asymmetric between the platforms. When an Apple pass is added, the device registers with your pass web service so it can receive updates, which is genuine server-side proof of an install. A Google save link doesn't report back on its own; you have to configure Google's callbacks to learn about adds and removals.
A worked example, with the assumptions written out. Say 100 people scan the poster in a week. If 80 finish the form, 78 get a pass built, 62 tap the wallet button, and 55 devices register, you're at 55 installs from 100 scans. The form cost you 20 people and the wallet handoff cost you 18, so half your remaining upside is in the taps this article is about. Those numbers are illustrative, not measured across shops.
One limit worth stating plainly: Waya has no POS integration and sends no SMS, so a lost enrollment can't be quietly recovered at the till later. The tap is the whole moment. The mechanics here aren't specific to us either. Niqati, Btaqa, OneCup, and Watily all ship wallet passes as of August 2026, and the same second confirmation screen sits at the end of every one of them.
Frequently asked questions
Why do some customers say the Add to Wallet button doesn't work?
In almost every case they opened the link inside an app's built-in browser, usually Instagram, TikTok, or a WhatsApp preview, and that webview blocked the handoff to Apple Wallet or Google Wallet. The pass is created correctly; the phone just never receives it. Ask them to open the page in Safari or Chrome, or to scan the QR code in the shop instead, which always opens the default browser.
Do customers need to download an app to add a wallet card?
No. Apple Wallet is built into every iPhone, and Google Wallet ships on most Android phones or installs free from the Play Store. With Waya, enrollment is a QR scan, a one-screen form asking for first name and mobile number, and one tap to add the pass. There's no account, no password, and no loyalty app to install.
What should a desktop visitor see instead of an Add to Wallet button?
Show a QR code that reopens the same enrollment link on the phone, because that's where the pass has to land. A Google Wallet save link does work from a laptop and syncs to the phone through the customer's Google account, but an Apple .pkpass file downloaded on Windows can't be added to anything. Treat desktop as a bridge to the phone, not as a place to finish enrollment.
Can I tell whether the customer actually added the pass?
For Apple Wallet, yes: once the pass is added, the device registers with your pass web service to receive updates, and that registration is real proof of an install. For Google Wallet, the save link gives you nothing back unless you configure Google's add and remove callbacks. Tracking the button tap alone will overstate your installs, because the platform's own Add screen comes after it.
Should I rename the button to something clearer, like Get my card?
No. Keep Apple's and Google's official wording and badges on the wallet button itself, because customers recognize them from their own phone and trust them faster than any custom label. Put your own words on the step before it, such as the submit button on the form, which Waya labels "Get my loyalty card". Testing all of this costs nothing: the free plan is 0 SAR forever for up to 100 customers and 100 wallet messages a month, with no credit card.