Apple and Google both publish their wallet APIs openly. Any competent engineer can read the PassKit documentation, sign a .pkpass file, and have a pass in a wallet by Friday. This is exactly why so many teams decide to build in-house, and exactly why the decision deserves more scrutiny than it usually gets. The demo is genuinely easy. The product is not.
What the demo hides
A wallet pass is not a file. It is a long-lived object with a service contract behind it. The moment a customer adds your pass, their device registers with your web service and expects it to answer, for years.
Building that contract in-house means owning, at minimum:
- A PassKit web service. Apple's spec defines endpoints for device registration, pass updates, and unregistration. Your service must answer them correctly for every pass you have ever issued, indefinitely.
- Push pipelines for two platforms. Apple and Google update passes through entirely different mechanisms. A change to a member's tier has to propagate through both, reliably, at whatever scale your program reaches.
- Certificate and credential management. Pass type certificates expire. Service account keys rotate. Miss a renewal and passes silently stop updating; you find out from support tickets, not from the portal.
- Two divergent data models. Apple's pass.json and Google's class-and-object model do not map one-to-one. Every field your program uses needs a considered translation to each, plus handling for layout limits, localization, and barcode formats.
- NFC certification. Identification in the same tap as payment requires Apple VAS and Google Smart Tap, programs with their own approval processes, key management, and terminal-side integration. Apple in particular reviews each NFC use case before granting the entitlement that enables it, and the request is normally prepared with an approved VAS Provider rather than filed cold. This is typically the point where in-house projects stall.
None of this is impossible. All of it is undifferentiated. Your customers will never choose you because your device-registration endpoint is well built; they will only notice if it isn't.
The maintenance is the product
The build estimate usually covers version one. The cost that surprises teams is everything after: new OS releases change what passes can do and occasionally how they render, wallet platforms add capabilities like poster layouts and new pass actions, and a new wallet gaining ground in your market means a third integration. In-house, each of these is a project competing with your roadmap. On a platform, each is a release note.
There is also the quiet operational load: monitoring update delivery, re-signing after certificate rotation, debugging why one Android model renders a strip image differently. This work has no finish line, and it lands on whichever engineer built the system, forever. When that engineer leaves, the pass infrastructure becomes the system nobody wants to touch, at exactly the moment a wallet platform changes something underneath it.
What buying actually buys
The build-or-buy framing undersells the buy side if you picture a platform as merely the same plumbing, hosted. What a pass lifecycle platform actually delivers is the accumulated answer to every problem on the list above, plus the parts most build plans never reach.
With Stell, one integration issues to Apple Wallet and Google Wallet, and when new wallets are introduced they arrive through the same integration, so the next wallet in your market is our project, not yours. Passes stay live after issuance: balances, tiers, and offers update in every wallet, with lock-screen messages when something changes. QR, barcode, and NFC identification are all first-class, with VAS and Smart Tap certification already in place and, as an Apple VAS Provider, the entitlement request for your developer account written with you rather than left on your desk. And the growth mechanics that justify the program in the first place, like post-purchase enrollment that converts a paying non-member into a member in the seconds after checkout, come built in rather than as a phase-two backlog item.
Teams that build in-house typically ship issuance and stop there, because updates, messaging, and enrollment each cost as much again. The result is a pass that works on day one and goes quiet on day two. The gap between a pass and a pass program is precisely the part that is hard to build.
When building makes sense
If wallet infrastructure is your product (you are a loyalty vendor, a ticketing platform, a pass provider yourself), then build. The control is worth the cost, because the cost is your business.
For everyone else, the honest question is not "can we build this?" but "is this where our engineers create the most value?" A retailer's engineers should be improving the retail experience. The pass plumbing underneath it behaves the same whether you built it or bought it, because customers only see the pass.
The short version
- Issuing one pass is easy; operating a pass program is a permanent service commitment across two platforms.
- The hidden costs are registration endpoints, dual push pipelines, certificate lifecycles, and NFC certification.
- Maintenance never ends: OS releases, new wallet features, and new wallets keep arriving.
- A platform delivers the parts build plans rarely reach: live updates, lock-screen messaging, and post-purchase enrollment.
- Build if passes are your product. Buy if they are your channel.
Stell exists so that the second group can ship in days what the first group maintains for years. One API, every wallet, and the plumbing is our roadmap instead of yours. See what the platform covers, or book a demo and see what the built version looks like.
