Wallet passes — loyalty cards, coupons, and event tickets saved to Apple Wallet or Google Wallet — are a different kind of customer touchpoint than a message. A message arrives, gets read, and scrolls up the thread. A pass gets saved once and lives on the phone until it is revoked or expires, updateable long after the message that delivered it is gone. This guide explains where passes sit in an omnichannel strategy, how they interact with your SMS and RCS engagement, and how Orbit ships the full pass lifecycle.
Where a wallet pass sits vs a message
Messaging channels are for sending something now: a campaign, a notification, a conversation. A wallet pass is for holding something durable: the loyalty card with its points balance, the coupon that redeems at the till, the ticket or boarding document that scans at the gate.
The practical differences:
- A pass survives the thread. The SMS that delivers the save link is a moment; the pass it installs is persistent. A customer who deletes the message still holds the card.
- A pass is updateable after delivery. Push a new points balance or a new seat assignment and the pass on the phone refreshes — no new message required, though you would typically send one to announce it.
- A pass is scannable collateral. Its barcode (QR, PDF417, Aztec, or Code 128) is the thing a point-of-sale or gate scanner reads — a message's job is only to hand the pass over.
- No app to install. Like RCS, passes ride in the phone's built-in wallet app, so the bar to "save my card" is one tap, not an app-store download.
Think of messaging as the pipe and the wallet pass as the artifact that pipe delivers. Retail loyalty enrollment, event ticketing, and coupon campaigns all follow the same shape: engage over a message channel, then anchor the durable credential in the wallet.
How passes interact with SMS and RCS engagement
Passes do not replace your messaging channels — they depend on them. Every pass issues with a save link, and any channel that can carry a link can deliver a pass: SMS, WhatsApp, email, or an RCS card with a tap-to-open action.
Two patterns dominate:
- Enrollment deep link. A customer joins your loyalty program, and the welcome SMS (or RCS message) carries the save link: "Add your card to your phone wallet." Because RCS messages support rich cards and suggested actions, the same enrollment reads better over RCS when the recipient supports it, with SMS as the automatic fallback.
- Lifecycle announcements. The pass itself is your persistent surface; messages announce what changed on it — "You've earned 200 points," "Your coupon expires Friday" — and the recipient opens the wallet to the updated card.
Because Orbit runs all of these channels behind one account, the same contact, consent record, and conversation carry across the delivery step and every follow-up, whether the pass link traveled by SMS, RCS, WhatsApp, or email.
What Orbit ships for wallet passes
The capability is live in the API and the dashboard, and covers the complete lifecycle:
- Three pass types — loyalty cards (points, tier, membership number behind a barcode), coupons (offer, redemption barcode, optional expiry), and event tickets (seat, gate, or order details).
- Issue — one API call returns both platform payloads: the Apple Wallet pass structure and a signed Google Wallet "Save to Wallet" link. Issuing is idempotent, so a retry never mints a duplicate pass.
- Update — patch points, tier, expiry, or seat on an active pass; each update signals holders' phones to refresh. Updates are partial — only the fields you send change.
- Void — permanently revoke a pass; it renders as expired in the wallet and stays visible for audit.
- Deep links — the Google save link (and the Apple pass payload once Apple credentials are connected) drops into any message; route it through Orbit link shortening when you want a short URL.
- Dashboard issuance builder — operators issue, update, void, and copy save links from the dashboard without touching the API, on the same shared ledger the API reads.
- Platform status check — one endpoint reports whether Apple and Google credentials are connected, plus the pass types and barcode formats your issuance form can offer. Passes you issue before credentials are connected start producing working save links the moment they are — no re-issue needed.
Connect your Apple pass-type/team credentials and your Google Wallet issuer credentials when you are ready for downloadable payloads; until then the pass content is still stored and readable.
The full reference, including request fields and error codes, is in the wallet passes channel docs. For how the messaging side fits together, see the RCS Business Messaging guide and the messaging platform.
Frequently asked questions
What is a wallet pass?
A wallet pass is a digital card — a loyalty card, coupon, or event ticket — saved to the Apple Wallet or Google Wallet app that is built into the phone. Unlike a message, it persists on the device until it is revoked or expires, and its content can be updated after it is saved.
How do customers receive a wallet pass?
Every issued pass comes with a save link. You deliver that link through whichever channel the customer opted into — SMS, RCS, WhatsApp, or email — and one tap adds the pass to their wallet. Orbit issues the link and sends the message from the same account.
Can a pass be updated after it is saved?
Yes. An update to an active pass (points balance, tier, coupon expiry, seat assignment) signals the holder's phone to refresh, so the pass in the wallet reflects current content without being re-sent.
What pass types does Orbit support?
Three: loyalty cards, coupons, and event tickets, with a choice of QR, PDF417, Aztec, or Code 128 barcode formats. Both Apple Wallet and Google Wallet payloads are produced for every pass.
Do I need to connect Apple and Google credentials before issuing passes?
No. You can issue and manage passes before either platform is connected — the pass content is stored and readable. The downloadable payloads (Apple pass structure, Google save link) appear as soon as the matching credentials are connected, and existing passes start producing working save links without re-issuing.
Is there a non-API way to issue passes?
Yes. The dashboard includes a wallet-passes issuance builder where operators issue, update, and void passes and copy save links, on the same ledger the API reads.
Published 25 August 2026. Part of the Orbit resources library — foundational guides for teams building on communications infrastructure.