One pass. Every wallet.
Apple Wallet and Google Wallet deliver the same promise with different machinery: push, updates, NFC and location work differently under the hood. Stell abstracts those differences, so you build against one API and every customer gets the full experience.
What each wallet supports.
Every capability below ships through the same Stell API call. The notes show how each wallet delivers it, differences you never have to code around.
| Feature | Apple Wallet | Google Wallet | Samsung Wallet |
|---|---|---|---|
| Where it works | |||
| Country availabilityWhere customers can hold a pass in the wallet | Everywhere iPhone is sold, passes are not region gated | Most countries, but not China, South Korea, Turkey or Russia | Around 36 markets across Europe, Asia and the Middle East |
| Preinstalled on the phoneNo app download before the first pass lands | Built into iOS | Preinstalled on most Android phones in supported countries | Built into Galaxy phones in supported markets |
| Getting the pass | |||
| Add via link or QROne tap from email, SMS, web or a poster | Add to Apple Wallet | Add to Google Wallet | Add to Samsung Wallet |
| Auto-import from emailThe wallet picks up passes from the inbox | Gmail import | ||
| Digitize a card from a photoCustomers turn any physical card into a pass themselves | iOS 27 and later | Photo import | |
| View passes on the webSee and save passes in a browser, not just the app | wallet.google.com | ||
| Same pass on every deviceThe pass shows up on all the customer's signed-in devices | Syncs through iCloud | Follows the Google account | Follows the Samsung account on Galaxy devices |
| Smartwatch supportPasses follow to the paired watch automatically | Apple Watch | Wear OS | Galaxy Watch, select card types |
| Cloud sync and restorePasses survive a new phone or a reinstall | iCloud sync | Lives in the Google account | Samsung account |
| Offline accessPass and barcode available with no connection | Stored on device | Cached on device | Cached on device |
| Identifying the member | |||
| NFC identificationIdentify the member in the payment tap | Apple VAS | Smart Tap | |
| QR and barcode scanningWorks with the scanners you already own | |||
| Rotating barcodesCodes that change on a timer to prevent screenshots | Generated on device | ||
| Biometric lock before NFCRequire Face ID or Touch ID before the tap hands over | |||
| Reaching the customer | |||
| Real-time updatesPoints, tiers and offers change on the pass in seconds | Signed update, pushed | Server-side object write | Server-side card update |
| Push notificationsLock-screen messages tied to a pass change | Change messages | Update notifications | Update notifications |
| Location-based surfacingThe pass appears when the customer is near your store | Relevant locations | Nearby pass notifications | |
| Live ActivitiesLive status on the lock screen through a flight or event | Boarding passes and event tickets | Flight progress notifications | |
| Time-based relevanceSurface the pass ahead of an event or booking | Relevant date | Event and transit passes | Flight and expiry reminders |
| On the screen | |||
| Full-screen poster layoutsEdge-to-edge artwork for events and memberships | Event tickets iOS 18, other passes iOS 27 | ||
| Buttons and links on the passSend members to booking, menus or your app | Featured actions, iOS 27 | App and web links | Card links |
| Install your app from the passThe pass offers your app, no store visit needed | Associated app installs straight from the pass | App link opens the Play Store listing | App link on the card |
| LocalizationPass content in the language the phone speaks | |||
| Running the program | |||
| Design changes to live passesRestyle every issued pass without reissuing | Re-signed and pushed per pass | One template edit | Template edit |
| No wallet-side content reviewShip a new pass design without waiting for approval | Certificates only, no design review | Google approves pass classes before production | Samsung reviews partner templates |
| Expiration and archivingExpired passes leave the active list on their own | |||
| Account-bound passesLock a pass to one customer's account at issue | Apple Account binding | Saved to a Google account | Delivered to a Samsung account |
| Sharing controlsDecide whether a pass can be passed on | |||
Adding the second wallet is not a second project.
The differences in the table above are real, and none of them reach your code. It is not two integrations behind a shared wrapper: the same endpoints serve all platforms, and the only thing that changes between them is which wallet you name when the pass is created.
| Step | The call | Apple and Google |
|---|---|---|
| Issue a pass | POST /v1/passes | Identical body. One enum value says which wallet, and the add link comes back with the pass |
| Update a pass | PATCH /v1/passes/{id} | Identical. Lands on the installed pass, no re-save |
| Void a pass | DELETE /v1/passes/{id} | Identical |
| Receive events | Signed webhooks | Same events, same payloads, wallet type included |
What does differ, stated plainly.
A pass belongs to one wallet
Passes are issued for the wallet they will live in, so a customer who wants theirs on both an iPhone and an Android phone holds one of each. Worth designing your member record around from day one, even if you launch on a single wallet.
Delivery timing is the platforms', not ours
Pass generation is ours and happens in milliseconds. How fast an update then surfaces on the phone belongs to Apple's push infrastructure and Google's device sync: Apple is typically seconds, Google commonly longer, and neither publishes a guarantee.
Rendering differs, deliberately
Each wallet has its own layout rules, field limits and artwork specs. Templates account for both, so a pass looks native on the platform it lands on rather than identical on neither.
One API call, both wallets.
Bring your loyalty program or ticket flow. In thirty minutes we'll show the same pass landing in Apple Wallet and Google Wallet, updating in real time.