The whole pass lifecycle, one platform.
Stell sits between the systems you already run and the wallets your customers already carry. You send events; we handle pass creation, distribution, live updates, NFC identification at the reader, and push, for Apple Wallet and Google Wallet alike.
Three layers, one integration.
Your stack keeps the customer record. Stell operates the pass: its schema, certificates, distribution and state. Wallets and readers are the last mile.
Under a second, stretched out.
The same tap that pays also identifies. The member is read at the terminal before the receipt prints. Stell comes in afterwards, to keep the pass in the wallet true.
Phone meets reader
The reader announces your program. The wallet presents the matching pass with the payment card, in one gesture.
Terminal decrypts the pass
The payload is encrypted for your program alone. The terminal holds the private key and reads the member identifier itself. No lookup, no network.
Sale linked to the member
The POS gets the identifier with the payment result and posts the basket to your loyalty engine. Discounts can apply in the same tap.
Balance written to the pass
Your engine sends the new points, stamp or tier in one API call. The pass updates in Apple Wallet and Google Wallet.
Push if it matters
Reward unlocked? An automation sends a lock-screen notification through the pass. No extra channel.
What the platform does.
One engine, one API. Each capability below is available across the pass types it applies to. This is the matrix teams usually want in front of them before scoping a launch.
| Capability | Loyalty | Tickets | Memberships | Gift cards | Coupons |
|---|---|---|---|---|---|
| Pass creation & designTemplates, both wallets, one payload | |||||
| DistributionAdd-to-wallet links, QR, email | |||||
| Real-time updatesAny field, in seconds | |||||
| NFC identificationApple VAS · Google Smart Tap | |||||
| Push notificationsLock screen, through the pass | |||||
| Campaigns & automationsSegments, triggers, scheduled sends | |||||
| QR & barcode scanningQR, PDF417, Aztec, Code 128, EAN-13 and more | |||||
| Enrollment at the tillPost-purchase sign-up, no form | |||||
| Analytics & reportingInstalls, taps, redemptions |
Launch
From kickoff to the first live tap: a scoped launch, not a project.
- Pass design on your brand
- Apple & Google certificate setup, under your own developer account
- Reader and POS validation in one store
- Staging plus a staff dry run
Run
Day-to-day operation belongs to your marketing and ops teams.
- Portal for pass edits and pushes
- Segments, automations and campaign scheduling
- Install, tap and redemption analytics
Support
We stay on the hook for the parts customers never see.
- Wallet spec changes handled for you
- Certificate renewals, no downtime
- Named contact and shared channel
- Honest incident communication
Who does what.
The honest split, so nobody discovers a surprise in week three.
| Area | Stell delivers | You provide |
|---|---|---|
| Pass design | Templates, artwork specs, both wallet renderings, previews for sign-off | Logo, brand colors, hero artwork assets |
| Integration | REST API, signed webhooks, staging keys, reference payloads | Access to CRM/POS, a technical contact 1–2 days |
| NFC at the reader | VAS and Smart Tap configuration, merchant IDs, test tooling | Reader model list, acquirer contact varies |
| Distribution | Add-to-wallet links, QR posters, landing page, email snippets | Placement in your journeys and stores |
| Rollout | Rollout plan, staff one-pager, launch review | A first store and a launch date |
Bring your own accounts.
The accounts are yours. The operating is ours. Register the pass type identifier and the issuer ID under your own Apple and Google accounts, and Stell takes the certificate lifecycle off your team entirely: issuance, annual renewal, PKCS#7 signing, and spec changes when the platforms move.
Bring your Apple Developer Account
The pass type identifier and its certificates live on your account. We need only enough access to operate them, and how much is your call:
- Add a named Stell engineer to your account, scoped to certificates
- Or give us App Store Connect API credentials scoped to certificates, and renewals run with no named person on your account at all
- If NFC identification is in scope, the account also needs Apple's VAS entitlement. Stell is a VAS Provider and prepares that request with you
Bring your Google issuer account
Issue under your own issuer ID. We take service-account access to manage classes and objects, and the account, and the estate of passes on it, stay yours throughout.
- Already issuing Google passes? They migrate onto Stell under the issuer ID you already hold
- Existing objects keep working and start receiving updates from us, with nothing for members to re-add
The day you leave
The test of ownership is what happens if you decide to leave. When the accounts are yours, so is the estate: serial numbers, authentication tokens and device registrations export on request.
- Passes already installed keep working while the update path is repointed
- No member deletes, re-adds, or notices anything
Bring your architecture. We'll map it.
Forty minutes with a solutions engineer: your POS, your loyalty engine, your reader estate. You leave with a diagram and an honest scope split.