Wallet passes have an unusual failure mode. A bad website looks bad immediately. A bad pass looks perfectly fine on the day it is issued, and only reveals itself weeks later, sitting in a customer's wallet showing a points balance from March. By the time anyone notices, thousands of copies of the mistake are already distributed, and the customer's conclusion is simple: this thing is dead, delete it.
Most failed pass projects fail this way. Not because the pass was ugly or the idea was wrong, but because of a handful of implementation decisions made early, usually to save time. Here are the ones we see most.
Failure one: the pass is not connected to anything
The most common shortcut is treating the pass as a file to generate rather than an object to manage. A script takes a template, fills in a name and a barcode, signs the file, and emails it out. Done, apparently.
The problem is that a pass without a backend behind it is frozen at the moment of issuance. Both Apple Wallet and Google Wallet are built around the opposite assumption: a pass registers with a web service, and that service can push changes to it for years. Skip the service and you have opted out of the entire mechanism that makes a wallet pass different from a PDF.
The symptoms show up on a delay. The customer earns points and the pass does not move. The tier changes and the pass still says the old one. Support starts fielding "my card shows the wrong balance" tickets, and the workaround, asking customers to delete the pass and add a new one, has a completion rate you can guess.
Failure two: the data flows one way, or not at all
Some implementations do have a backend, but the connection only points outward. The pass can be updated, technically, but nothing triggers the update, because the pass platform and the system of record (the CRM, the loyalty engine, the ticketing system) were never wired together.
This is the "two sources of truth" failure. The CRM knows the customer has 840 points. The pass says 512. Neither is lying; they just stopped talking. Every purchase, tier change, and profile edit now needs someone or something to copy it across, and anything that depends on a human remembering to sync will drift.
The fix is boring and structural: the system of record emits events, the pass platform consumes them, and the pass in the wallet is a projection of live data rather than a copy of old data, which is the whole point of managing a pass across its life. If a balance changes and no code runs, the architecture is wrong.
Failure three: updates exist but arrive too late
A nightly batch job feels like a reasonable compromise. It is not, because of when customers actually look at their pass: at the till, seconds after the transaction that changed their balance.
A pass that updates overnight is a report. The customer pays, opens their wallet, and sees a number that does not include the purchase they just made. Technically the system works. Experientially, the pass just told the customer it cannot be trusted, at the exact moment it had their attention. Trust in a glanceable object is binary; a pass that is sometimes stale is treated as always stale.
The fix is the same event-driven wiring as failure two, taken seriously about latency: the purchase event fires, the webhook lands, the pass updates, all before the customer is out the door. Seconds, not cycles. When the update arrives while the wallet is still in the customer's hand, the pass does the one thing a loyalty program most needs its surface to do: prove, at the moment of attention, that the program noticed.
Failure four: identification was an afterthought
A pass has one operational job: identifying the customer at the counter, the door, or the gate. Bad implementations treat this as a detail. The barcode encodes something the till cannot look up. The format does not match what the scanners read. NFC was never configured, so the pass cannot tap where readers exist. Nobody tested at an actual till with actual hardware.
The result is the worst moment in loyalty: a customer holding up a queue while a cashier squints at a phone, then gives up and asks for their phone number. Do that to a customer twice and the pass is deleted, and the program with it. QR and NFC are both first-class ways to identify, and choosing between them is not where projects go wrong; the failure is wiring either of them to a system that cannot answer.
The prevention is unglamorous: decide what the scan or tap must return before designing anything else, encode a value the POS can resolve, match the barcode format to the scanner fleet you actually own, and test at a real till with real hardware before launch. Identification is the pass's job description. Everything else on the pass is decoration if this part does not work in under two seconds.
Failure five: nobody owns the pass, during implementation or after
Ownership problems start before launch. A pass sits between departments: marketing owns the brand on it, IT owns the systems behind it, operations owns the till it gets scanned at. Projects without a named owner on the merchant side stall in exactly that gap. The design gets approved but nobody connects the loyalty engine. The integration works but nobody trains store staff. Each department did its part; nobody owned the pass. The implementations that ship, and keep working, have one person on the merchant side who owns the pass end to end and can pull in the others.
The same gap reopens after launch. Passes stay in wallets for years, which is longer than most marketing campaigns, brand guidelines, and org charts survive. Implementations that treat launch as the finish line leave nobody responsible for what happens after: the rebrand that never reaches issued passes, the expired offer still showing on lock screens, the "2024 member benefits" field that is now two years wrong.
This also covers the endings. Passes that should die, spent gift cards, lapsed memberships, former employees' staff passes, live on because nobody built revocation. A pass you cannot end is not just clutter; for anything that grants a benefit it is a liability.
The pattern underneath
All five failures are the same failure at different layers: treating a pass as a deliverable instead of a live surface. The file gets generated, the project gets closed, and the pass begins a long, quiet decay in ten thousand wallets.
The test for any implementation, before launch, is to ask "and then what?" for each thing that will change. The customer earns points, and then what? The brand refreshes, and then what? The membership ends, and then what? If the honest answer to any of these is "we would issue new passes and hope people add them," the implementation will fail on the same schedule as all the others. If the answer is "the passes already in wallets just change," the hard part is done, and the pass can do what it is actually for: staying correct, quietly, for years.
This is why Stell does not have a "static pass" option. Every pass issued through Stell is connected to the backend from the moment it lands in a wallet: it registers for updates, listens to your systems, and can be changed, messaged, or revoked at any point in its life. Not because every program needs every feature on day one, but because the connection is the one thing you cannot retrofit into passes already issued.
That is the actual value proposition of a pass platform, and it is worth stating plainly. You are not buying pass generation; generating a pass is the easy part, and plenty of tools do it. You are buying the guarantee that every pass in every wallet stays correct, for years, without anyone at your company having to remember to make it so. The failures above are what "we'll handle that part ourselves" looks like in practice. The platform's job is to make them structurally impossible.
