A hotel loyalty card that adds itself straight to Apple Wallet or Google Wallet from a guest's own phone, no app download, no certificate for a hotel group to manage.
Ask a hotel group what "digital loyalty" means and most people picture an app: something a guest downloads from the App Store, logs into once, and then forgets about until the next push notification nags them back. That's the default assumption behind most hotel loyalty program app pitches, and it's backwards for most properties. A guest doesn't want another icon on their home screen for a hotel they might visit once a year. What they'll actually keep is a card that lives somewhere they already look: the Wallet app sitting on their phone next to their boarding pass and their gym membership.
In GuestMaker, a member's loyalty card lives on their member portal page, not in a separate download. There's no app store listing, no second account to create, and no login to hunt for the next time they're back at the front desk. The member opens their portal and taps a button, and the card is added straight to their phone's own Wallet app. On an iPhone, that means Apple Wallet, already sitting there; on Android it can mean Google Wallet too, though whether that's actually available depends on whether the hotel group has set it up on its own end, which we'll get to below. Either way, there's no separate app to go find first.
What shows up isn't a screenshot of a card or a static graphic pretending to be one. It's a real Wallet pass, the same format used for a boarding pass or a concert ticket, so it surfaces on the lock screen the way those do, and it survives a guest deleting every other travel app on their phone without touching the one thing that actually keeps them enrolled in the program.
Here's the part that sounds like it should be complicated and isn't. Getting a pass to show up correctly in Apple Wallet requires a Pass Type ID and a signing certificate issued by Apple, the credentials that let Apple's own servers trust that a given .pkpass file genuinely came from who it claims to be. A hotel group building this alone would need to register for that certificate itself and wire it into whatever system actually generates the cards. That's real infrastructure work, and it's exactly the kind of thing that quietly never gets prioritized on a hotel's own roadmap.
None of that happens per tenant here. There's one Pass Type ID and one signing certificate, held centrally, and every hotel group's cards are cryptographically stamped with it server-side. A hotel group never sees or uploads a certificate at all. What they get instead is a single toggle in their loyalty settings, on by default, that turns the member-facing "Add to Apple Wallet" button on or off, plus the option to pick their own card colors. That's the entire configuration surface a hotel group interacts with. Apple Wallet, in other words, is platform infrastructure here, not a project a hotel's marketing team has to run, budget for, or wait on.
A .pkpass file only means something to an iPhone or iPad; there's no Wallet app on a laptop. So the member portal handles that split honestly instead of pretending it doesn't exist. On an iPhone, tapping "Add to Apple Wallet" adds the card directly, no detour needed. On a desktop browser, or on an Android phone, the same portal page shows a QR code in place of that button.
The member points their iPhone's camera at it, and the card lands on their phone exactly the way it would have if they'd started there. It's a small mechanical detail, but it's the difference between a feature that quietly breaks the moment a guest checks their points balance from a work laptop, and one that just routes around the constraint without making the guest think about it.
Google Wallet flips that constraint entirely. A Google Wallet save link works directly from a desktop browser, no phone camera required, because it saves the pass to the member's Google account first and syncs it down to their phone on its own. No QR hand-off step needed there at all.
But Google Wallet is genuinely different from Apple Wallet in a way worth stating plainly rather than glossing over: it isn't platform-wide the way Apple Wallet is. A hotel group has to request its own access to the Google Wallet Business Console, wait for approval (typically a day or two), enable the Google Wallet API on its own Google Cloud project, and generate its own service-account credentials before its members can use it at all. Where a tenant has done that setup, it works properly, member cards save to Google Wallet the same way they save to Apple's. It's just not something that's simply on for every hotel group the day their program launches, the way Apple Wallet is. That's an honest gap, not a hidden one, and it's the reason Apple Wallet is the default story here while Google Wallet is the option a group turns on once it's done the setup on its own side.
A pass that looks right in a test environment and a pass a real iPhone will actually trust are two different claims, and it's worth being specific about which one applies here. A generated pass has been checked against Apple's own full certificate chain, from WWDR G4 up through Apple's own root certificate, using OpenSSL's signature verification tooling. That confirms the cryptographic chain an iPhone inspects before it will display a pass at all is genuinely intact, not just that the .pkpass file opens without throwing an error somewhere in the pipeline.
One thing worth saying honestly rather than quietly working around: the artwork on the pass itself, the small icon shown on the card inside Wallet, is currently a plain square in the hotel's brand color, not a rendering of the hotel's own logo. That's a real, present limitation, and it's a stated future improvement rather than something already live and just undocumented. A hotel rewards program is judged on whether a member keeps and uses the card, and a generic color square still does that job; it just isn't the finished version.
None of this is a clever trick. It's a bet that a loyalty program for hotels only works if members actually keep using it, and the single biggest predictor of whether they do is how much friction sits between "I'd like to join" and "the card is somewhere I'll actually see again." An app download is friction a guest has to justify to themselves for a property they might visit once a year. A card that adds itself to something already sitting on their phone isn't.
If you're building a program from scratch, how to launch a hotel loyalty program covers the decisions that come before any of this. The Wallet toggle itself lives inside the loyalty module, on by default, waiting for nothing but a hotel's own brand colors.
Thirty minutes, your real properties, no generic demo environment.
A referral bonus and a milestone bonus can both fire on a guest's first stay. Here's the real bug we caught, and how hotel referral programs actually pay out.
Letting a guest spend loyalty points like cash at checkout sounds like a UI feature. It's actually a concurrency problem, solved with database holds, not subtraction.
The traditional loyalty build takes months of vendor calls and shifting launch dates. Here's what actually has to get decided, and how to launch fast.
