Plenty of tools will make you a wallet pass. Upload a logo, pick a color, generate a file: done. And for about a week, it feels done. Then a price changes, a tier gets renamed, a customer moves cities, and the passes sitting in ten thousand wallets are quietly wrong.
That gap between generating passes and managing them is what pass lifecycle management means. It treats the pass the way you treat any other live product surface: something with a beginning, a long useful middle, and a deliberate end. It is also the job Stell was built for, which is why the platform is organized around these stages rather than around a file export button.
The six stages
1. Design
The lifecycle starts before the first pass exists. Design is where you decide what the pass is: the brand it carries, the fields it shows, the barcode format it displays, and whether it is tap-capable. Good design here is restraint. A pass is a glanceable object, not a brochure, and the best ones show the customer exactly what they care about (their points, their tier, their next reward) and nothing else.
Because the design lives in a template rather than in each pass, this stage happens once and improves continuously. Change the template in the Stell portal, and every pass issued from it follows. One design decision serves Apple Wallet and Google Wallet at the same time, so you are not maintaining two versions of the same idea, and when new wallets are introduced, the same template will serve them too.
2. Issue
Issuance is distribution: getting the pass from your system into a customer's wallet. The channels matter less than the principle, which is to meet the customer where they already are. A link in a receipt email. A QR code on a poster. An invitation at the till after payment. An API call from your CRM when someone signs up on the web.
One channel deserves special mention because it is the one most programs miss: the seconds after payment. A customer who has just paid is your highest-intent non-member, standing at your till with their phone in hand. Post-purchase enrollment turns that moment into a membership, with the pass in the wallet before they reach the door. Stell treats this as a core issuance channel, not an afterthought.
Issuance also has two distinct moments, and conflating them is a common way to misread a program's health. A pass is created when you issue it, and it becomes active when the customer actually adds it to Apple Wallet or Google Wallet, which may be seconds later or never. Stell reports both as separate events, so the gap between them is measurable: how many invitations turned into passes in wallets, per channel, per store. That number tells you whether your enrollment is working long before the loyalty metrics do.
One decision at this stage shapes everything downstream: issue passes connected to your backend, not as static files. A connected pass can change. A static one is frozen at the moment of issuance, and that single shortcut is the most common way pass projects fail.
3. Use
This is the stage the customer sees: the till, the door, the gate. The pass identifies them, by tap where NFC readers are available and by scan everywhere a barcode reader exists. Both are first-class; the same pass carries both, so identification works with the hardware in front of it rather than dictating a hardware project.
What matters operationally is that every use is an event your systems can see: who, where, when. Each identification should reach your endpoint as an event over a webhook, carrying the pass, the store, the terminal, how the member was identified and what they earned or spent. The till event becomes a customer record, not just a beep. Usage is not just redemption. It is the signal that feeds everything else.
Two properties of that feed decide whether you can trust it: whether events are signed, so you can verify one came from your platform before it touches a points balance, and what happens on a retry, since a feed that can deliver the same event twice needs a handler that will not award the points twice. Ask any platform both questions. If the answer to either is vague, the feed is a demo, not an integration.
4. Update
Passes stay in wallets for years. Businesses change weekly. Update is the stage that reconciles the two: point balances after each purchase, tier upgrades the moment they are earned, a new offer replacing an expired one, a rebrand rolling out to every wallet at once.
Real-time matters here more than it first appears. A points balance that updates overnight is a report. A balance that updates while the customer is still at the till is an experience: the receipt in their pocket agreeing with the pass on their lock screen. This is why Stell syncs with your CRM continuously rather than on a schedule; the pass should never be the stale copy of the relationship.
5. Engage
A pass is also a channel. It can put messages on the lock screen when content changes, and surface itself when the customer is near a store or when an event is about to start. Used well, this is the most respectful marketing channel you have. Messages arrive on an object the customer chose to carry, about a relationship they opted into, with no per-message cost pushing you toward volume. Push notifications are part of the platform, not a paid add-on, so the economics never push you toward silence or spam.
Used badly, it is deletion fuel. The lifecycle mindset helps: engagement is a stage in a long relationship, not a campaign metric. Message when you have something worth saying.
6. Retire
Every pass should end on purpose. Tickets expire after the event. Gift cards close at zero balance. Employee passes are revoked the day someone leaves (immediately, not at the next sync). Memberships are reissued under a new program rather than abandoned.
Retirement is where governance lives: a pass that cannot be revoked is a liability, and an audit trail of what was issued, used, and ended is what lets you answer questions later, whether they come from finance, security, or regulators. A lifecycle platform keeps per-pass state for exactly this reason: you can always say what a pass showed, when it changed, and when it stopped.
Why the loop matters more than the stages
Written as a list, the lifecycle looks linear. In practice it is a loop: usage data informs engagement, engagement drives visits, visits trigger updates, and what you learn feeds back into design. A generated pass file participates in none of this. A managed pass participates in all of it.
That is the practical test for any wallet project, whatever platform you choose: for each stage, ask "and then what?" What happens when the price changes? When the customer earns a tier? When an employee leaves the company? If the answer is "we generate new passes and hope people add them," you have a generator. If the answer is "the passes already in wallets just change," you have lifecycle management, and a program that compounds instead of decaying.
Stell exists because that second answer is hard to build and easy to buy. Design once, issue everywhere, and let the platform keep every pass current, useful, and accountable for as long as the relationship lasts. If you want to see the loop running on your own program, book a demo and bring a real scenario: a points change, a tier change, a rebrand. Watching a pass follow your business in real time is the whole argument.
