Omnichannel · Mobile App
The member center, app push, and Apple Wallet — delivered as a thin SDK over your existing member portal plus server-side capabilities. Members stay signed in, the card updates itself, and you ship changes without shipping an app update.
Points balance
2,480 pts
Push · 2m ago
Your reward is ready near you 🎁
The problem
A native points/coupons/tier UI means a double-platform build, every change re-shipped through app review — a project most teams can't justify.
Without push and an in-app card, your highest-intent audience only hears from you by email — the channel they check least.
You suspect the app drives store visits, but with no member-keyed signal and no control group, the lift is a guess.
What you can build
The member center is your responsive web portal in a WebView (no native rebuild); push and Wallet are server-side, so the SDK stays light.
Render the real Flash member portal (points, coupons, tier) inside a native WebView with single sign-on. A first-party session cookie keeps members signed in across in-app navigation — and you ship portal changes server-side, no app release.
Register device tokens and push joins the same automation/send stack as email, with a fail-open waterfall and one shared frequency cap. Token registration is live; push delivery is rolling out behind a controlled flag.
Issue the card server-side from one endpoint — no app required. Apple returns a signed .pkpass that auto-updates the moment a member's balance changes; Google returns a save link. Needs your wallet credentials (Apple Pass Type ID + signing cert; Google issuer) configured.
A QR check-in or in-store redeem fires a store-visit trigger — member-keyed, deduped at the database, timezone-bucketed. With a randomized holdout, you can measure real incremental lift, not vanity footfall.
Straight about status
The server side — WebView SSO, push registration, Wallet issuance + auto-update, deterministic store-visit — is built and callable today. You can integrate directly against these endpoints now. The native convenience packages are in active development; we won't claim a shipped binary that isn't.
Member-center WebView SSO
/embed/member/native — first-party HttpOnly cookie.
Wallet card — Apple + Google
Apple signed .pkpass (auto-updates on balance change) and Google save link, one endpoint.
Deterministic store-visit + holdout
QR/redeem trigger; randomized control for true lift.
App push delivery
Registration live; delivery rolling out behind a flag.
Native SDK (FlashPortal/Location/Core)
SPM / CocoaPods / Maven packages — in development.
Background geofence (on-device)
Server pipeline built; on-device detection ships with the FlashLocation package, in development.
Engineering value
Push and location are gated by explicit consent plus the Global Privacy Control signal — no signal, no send. One-tap withdraw, no penalty.
Device tokens, passes and store visits are scoped to your team; the Apple update service proves tenancy by the pass's own secret, not a shared identifier.
A randomized holdout measures incremental store visits against a control group — and we never report self-estimated footfall.
A loyalty experience that lives where members already are — in your app, on their lock screen, in their wallet — without a native rebuild or a per-change app release.
No app release
ship member-center changes server-side
Self-updating card
points/tier refresh the Wallet pass automatically
Provable lift
store visits measured against a holdout
See the member center, push, and Wallet running against your brand — then integrate against the live endpoints today.
