One card record, three ways to deliver it
A customer whose phone has neither Apple Wallet nor Google Wallet still gets a working loyalty card. It opens in the browser, shows the same stamp count your cashier sees, and holds its state after they close it. What it gives up is push: no lock-screen line, no proximity reminder.
The reason parity is possible is that the card isn't a file. It's a record keyed on your program plus the customer's mobile number. Apple Wallet, Google Wallet, and the browser card are three renderings of that one record. Which one a customer receives depends entirely on the device that scanned your QR code.
The enrollment page reads the browser's user agent and picks a path. An iPhone or iPad is handed a .pkpass file that opens straight into Apple Wallet. An Android phone is handed a Save to Google Wallet link. A desktop browser is offered both, because a laptop can't tell you which phone the person is carrying.
The important consequence: the customer joined the moment they submitted the form. Minting the pass is the last step, not the enrollment itself. A wallet install that fails is not a signup that failed.
The devices that really do fall through
Start with the honest list. Android phones shipped without Google Mobile Services have no Google Wallet to save into, which covers most Huawei models sold after 2019. Managed work phones are the second case: an employer's device policy can disable or hide the wallet app outright, and no web page can override that.
Third is the in-app browser. A customer who opens your link inside Instagram or a WhatsApp preview is sitting in a stripped-down webview. File downloads behave inconsistently there, and older iOS webviews are missing browser APIs that modern pages assume exist. Telling that customer to reopen the link in Safari or Chrome fixes most of it in one tap.
Fourth is the case nobody expects, because it isn't the device at all. Some carrier DNS setups and Android Private DNS profiles resolve trywaya.com fine but refuse to resolve the API host behind it. The page renders, then every request fails at the network layer. We retry those calls through a same-origin proxy on our own domain, which is why enrollment still completes on connections that look broken from the outside.
Fifth is the desktop signup. Someone reads about your program on a laptop and joins there. They see both wallet buttons, and often neither helps, because the wallet lives on the phone in their pocket.
What the browser card keeps, and what it gives up
Parity holds on everything that decides whether loyalty actually works. The web card shows the same stamp count, the same reward wording, and your colors and logo. Scans from any of your branches roll into the same record. Your dashboard counts that person exactly like a wallet customer: visits, redemptions, new versus returning, and whether they've gone quiet.
What it gives up is push. A wallet pass refreshes itself in the background and can put a line on the phone's lock screen. A web page can't do either. So there's no lock-screen message when the customer earns a reward, and no passive geofenced reminder when they walk past one of your branches.
That makes the web card a pull surface rather than a push one. The customer has to open the link to see where they stand. Any mobile browser can add a link to the home screen, and telling customers to do that narrows the gap to something most people accept.
How the counter serves a customer with nothing on screen
This is the part that makes the whole fallback workable, and it's rarely written down. Your staff don't need the customer's card at all. The dashboard has a phone lookup: type the mobile number, and that customer's card comes up ready to stamp or redeem. Scanning the QR on their screen is faster, but it is optional, not required.
That one feature absorbs a long tail of failures. A dead battery, a deleted pass, a phone left in the car, a wallet that never installed, a customer who signed up on a laptop last week. Anyone who enrolled can be served from the number they typed into the form.
None of this touches your till. There's no POS integration and no extra hardware to buy. Staff work from an ordinary phone or a browser, using the web dashboard or the merchant iOS app, beside whatever payment terminal you already run.
Handing the customer back to the wallet later
Moving someone from the web card onto a real wallet pass is one scan, not a migration. Enrollment is unique on program plus mobile number. When that same number enrolls again from a wallet-capable phone, the existing card is re-issued to the new device instead of a second card being created.
In practice: the customer re-scans your counter QR code on the new phone, types the same number, and the pass arrives with their current stamps already on it. Nothing resets, nothing duplicates. The same mechanism covers a phone upgrade or a backup restore that dropped the pass.
One caveat worth knowing before you build a process on it. The first time a given number installs an actual wallet pass, that counts as a new device enrollment and goes through the same plan check a fresh signup does. Later re-issues of a pass that already exists don't. On the Free plan's hard stop at 100 customers, already-enrolled customers keep their cards and keep collecting either way.
What it costs, and what to verify before you decide
Pricing is public and flat. Free is 0 SAR forever: up to 100 customers, 100 wallet messages a month, 1 stamp card, 1 branch, your own card design, the full dashboard, no credit card. Growth is 85 SAR a month or 867 SAR a year: unlimited customers, up to 10 cards, 3 branches, 5 staff accounts, 5,000 messages a month, all card types, and Excel import. Premium is 149 SAR a month or 1,520 SAR a year for unlimited cards, branches, staff, and messages. On paid tiers the metered thing is wallet messages, not customers.
For competitor context, dated and worth checking yourself before you commit: as of August 2026, Btaqa publishes tiers at 108, 250, and 380 SAR a month, OneCup is about 150 SAR a month, and Watily is 149 SAR a month with loyalty bundled into a wider plan. Niqati is the best-known name in the Saudi market and prices by quote. All of them ship wallet passes, and I'm not claiming otherwise. The structural difference is where you start: each of those begins with a paid subscription.
Two things worth stating plainly. There is no POS integration, and there is no SMS channel. Wallet messages are delivered to the wallet pass itself, which is precisely why a web-card customer can't receive them. For scale context, the numbers on our Arabic homepage: 100+ shops across Saudi Arabia, 5,000+ customer cards living in wallets, and a 4.9 out of 5 average rated by 90 merchants.
Frequently asked questions
Do my customers need Apple Wallet or Google Wallet to use a loyalty card?
No. A customer with neither wallet gets a browser-based card that holds the same stamps and the same reward as a wallet pass. They open a link instead of a pass, and your cashier can also look them up by mobile number with nothing on the customer's screen at all. Nobody downloads an app either way.
What happens if a phone has no Google Wallet at all?
The signup still completes and the card still exists, because enrollment happens when the form is submitted, not when the pass installs. Phones shipped without Google Mobile Services, including most Huawei models sold after 2019, fall back to the browser card with full stamp parity. The only losses are lock-screen notifications and branch-proximity reminders, both of which need a real wallet pass.
Can a customer sign up from a laptop or desktop computer?
Yes, and the card is created either way. A desktop browser is offered both the Apple Wallet and the Google Wallet option, since the page can't tell which phone the person carries. Most desktop signups end up using the web card, then move the pass onto a phone later by re-scanning the QR code with the same mobile number.
If a customer switches phones, do they lose their stamps?
No. Cards are unique per program and mobile number, so enrolling again with the same number re-issues the existing card rather than creating a second one. The customer re-scans your QR code on the new phone, types the same number, and the pass arrives with the current stamp count already on it.
Does the web card receive notifications?
No. Lock-screen messages and passive geofenced branch reminders require an Apple Wallet or Google Wallet pass, so web-card customers don't get them. There's no SMS channel either, so plan on reminding those customers at the counter, or move them onto a wallet pass the next time they have a compatible phone.