A loyalty program has a message problem and an artifact problem. The message problem is reach: the points accrual, the referral reward, and the cart reminder have to arrive on a channel the member actually reads. The artifact problem is persistence: the membership card, the balance, and the coupon have to live somewhere a member keeps them long after the message that delivered them scrolled away. Most loyalty vendors solve the first by renting a messaging pipe and the second by shipping a hosted member portal or a white-label app. A CPaaS that ships wallet passes as a first-class outbound channel solves both on the same contact record — and that changes the build-vs-buy question from "which loyalty vendor do we rent" into "which parts of retention do we still need to rent."
This post works through that decision: what a loyalty SaaS actually bundles, what owning the channel stack on Devotel Orbit buys you, how Apple Wallet and Google Wallet act as the outbound artifact, the recovery craft that a saved pass enables, and an integration test you can run on Shopify before committing either way. If you want the capability tour first, the loyalty, referrals, and outbound capability overview surveys each outbound route; the pass mechanics themselves are in the wallet passes outbound post. What follows is the decision framing those two posts do not carry.
Loyalty provider vs in-house CPaaS
Unbundle the loyalty vendor and it resolves into four parts: a rules engine (accrual, tiers, expiry), a rewards pool (codes, credits, vouchers), a delivery layer (email plus whatever SMS/WhatsApp pipe the vendor rents upstream), and a member surface (hosted portal, white-label app, or nothing). The vendor's margin lives in the bundle: you pay platform pricing for the rules and rewards, and per-message markup on a messaging pipe you cannot renegotiate because it is not yours.
Assembling the same surface on a CPaaS that ships these primitives changes only one thing: who owns the joins. On Orbit the mapping is direct:
| Loyalty-vendor component | Orbit counterpart |
|---|---|
| Rules engine (accrual, tiers) | Outbound → Loyalty — points and tiers accrue against activity |
| Rewards pool | Outbound → Incentives — one shared register both referrals and loyalty draw from |
| Delivery layer | Campaigns and journeys over SMS, WhatsApp, and RCS with the fallback chain you configure |
| Member surface | Outbound → Wallet passes — the member's card on their phone, updated in place |
Two observations fall out of the table. First, the economics consolidate: a referral reward and a loyalty redemption draw from the same incentives register, so the cost of a program is one ledger, not a vendor report reconciled against a message bill. Second, the member surface gets cheaper the moment it is a pass: a wallet card is issued per member, updates in place, and never requires shipping or maintaining an app.
Buy the vendor when governance is genuinely missing — when no one on your team will own reward math, fraud rules, and tier design, a curated program is a reasonable rent. Build when the vendor's bundle is mostly a markup on delivery you can own and a member surface a wallet pass replaces. The middle position most teams land in: keep the rules where they like them, move delivery and the artifact onto infrastructure they control.
Apple Wallet and Google Wallet as outbound
A saved pass is not a message. It is a document the phone holds — a loyalty card with a live balance, a coupon with a redemption barcode — that sits on the lock screen and in the wallet app until it is revoked or expires. The wallet passes outbound post covers the mechanics: issue, update, and void behind the API, save links delivered over whichever messaging channel the member opted into, and passes tied to the same contact record as the rest of your outreach. The buyer-decision point is what that format buys a loyalty program:
- The member surface without an app. The card a member keeps is issued as a pass, not built as software. Enrollment issues the card; accrual patches it; the member never downloads anything.
- Updates land where the member looks. A points or tier change refreshes the saved pass on the phone — the balance the member sees at the till is current, without a re-send and without a portal login.
- One consent and opt-out record. The save link, the balance-change note, and the re-issue all run through the same contact as the rest of the program's messaging, with the same suppression rules applied.
That last property is the one a bolt-on loyalty vendor cannot match: the vendor's member surface lives in a different system from your delivery pipe, so consent state and contact identity drift between them.
The recovery craft — the pass as a renewal lease
Treating a saved pass only as a delivery target undersells it. The stronger posture is a recovery lease: the pass is an artifact with a tenant-owned update path, so a broken incentive, an expired coupon, or an abandoned cart can be repaired by updating what the member already holds rather than starting a new thread.
Cart recovery with a wallet finish. The commerce event stream detects the abandoned checkout and fires the recovery message. For an opted-in member the message can carry more than a link: issue or update a coupon pass scoped to the cart, and the member's incentive is now on their phone — still present after the SMS thread is three days old, still scannable at the till. When the buyer completes, void or expire the incentive pass so the discount cannot be redeemed twice.
Broken-pass re-issue. A member loses a phone, revokes a pass, or lets a coupon lapse. Because issue is idempotent and update is partial, the repair is a re-issue against the same contact — same incentive register, same consent record — not a new enrollment. The member's history on Customer 360 shows the original pass, the re-issue, and the redemption as one thread an agent can read mid-conversation.
Expiry as retention touchpoint. A coupon pass nearing expiry is a scheduled, honest reason to update the artifact and nudge the member. The wallet copy refreshes with the new date; the paired message explains the change from the same account the member already hears from.
None of this requires a new pipeline per case. The recovery flows run as campaigns or journeys over the same outbound surface the batch sends use — the distinction is the artifact they leave behind.
An integration test on Shopify
The cheapest way to judge the framing is to run it against a real store before retiring any vendor contract. The Shopify conversational commerce post covers the integration end-to-end: an HMAC-verified webhook receiver subscribes the store for customer, checkout, order, and refund topics, and checkout events arrive seconds after a buyer stalls rather than in a nightly export.
The test takes a day, not a quarter:
- Connect the store on OAuth and confirm the checkout and order topics are registering events.
- Build one abandoned-checkout recovery flow: a WhatsApp or SMS recovery message on the checkout event, self-cancelling on the buyer's own completed order.
- Wallet-finish the recovered carts: issue a coupon pass against the recovered contact, and void it when the recovery converts.
- Read the result per recovered cart on the ROI surface — voucher deliverability, redemption, and the fallback chain that routed each message — against the same metric from your current vendor's export-and-blast flow.
What you are measuring is whether freshness plus an owned member artifact recovers more carts than your vendor's batch cadence. That number, not the feature list, settles the build-vs-buy question.
Frequently asked questions
Does this replace a loyalty provider?
It replaces the parts priced as a bundle: delivery and the member surface. The rules engine and reward design still need an owner — either the vendor's or yours. Teams keep the vendor when program governance is the scarce resource and build when the bundle is mostly marked-up delivery.
Do members need to install an app to hold their card?
No. The card is issued to the Apple Wallet or Google Wallet app already on the phone. Enrollment delivers a save link over the member's opted-in channel, and one tap stores the card.
Can a saved pass be updated or revoked later?
Yes. Updates patch an active pass in place — points, tier, expiry — and signal the phone to refresh. Voiding revokes a pass permanently; it renders as expired and stays visible for audit.
How do Shopify events reach the messaging flow?
The store's webhook events land on Orbit's verified receiver and upsert contacts keyed on the Shopify customer, so a checkout event can trigger a recovery flow within seconds and every later event for that buyer joins the same contact record.
What stays with the tenant on compliance?
Program-level policy. Consent capture, opt-out keywords, quiet hours, and do-not-contact lists are tenant-configured controls the platform enforces on every send; the legal posture for your programs and jurisdictions stays with your organization.
Published 28 August 2026.