Use case · Platforms

Add wallet passes to your platform - under your customers' brands, not ours.

For ticketing, booking, loyalty, and vertical SaaS platforms whose customers keep asking for Apple Wallet and Google Wallet passes. One API. White-label by default. Nobody has to become a pass-infrastructure team.

The ticketing platform.

Organizers want entry tickets that land in the attendee's wallet - with the organizer's branding, live gate updates, and a barcode your scanners already read.

The booking system.

Studios and salons want the next appointment sitting in the customer's wallet, updating itself when the booking changes. Not another confirmation email.

The loyalty or membership engine.

Your customers run the program in your software. They want the card in Apple Wallet and Google Wallet - looking like their card, not yours, and certainly not ours.

The ask

"Can our customers issue wallet passes through your software?"

If you run a platform, you have heard some version of this. An event organizer wants entry passes in the attendee's wallet. A gym chain wants the member card on the lock screen. A retailer wants the stamp card out of the drawer and onto the phone. And every one of them wants it to look like their program - issued by your platform, branded as theirs.

The feature is genuinely good. Wallet passes need no app install, update themselves, and surface on the lock screen at the right moment. Your customers are right to want them. The trap is concluding that because the ask is simple, the build is.

Build vs. buy

What building pass issuing in-house actually costs.

A single pass for a single brand is a weekend project. Issuing for every brand on a multi-tenant platform is a different animal. Four costs show up late and stay forever:

01

Two platforms, two certificate regimes.

Apple wants a Developer account and Pass Type ID certificates that expire and must be rotated. Google wants an issuer account, a service account, and an approval flow. Multiply by every brand on your platform.

02

Push infrastructure you can't skip.

A pass that never updates is a screenshot. Live passes mean APNs and Google Wallet API update plumbing, device registration bookkeeping, and retry logic - running forever.

03

Rendering rules that keep moving.

Google shipped a full-screen pass redesign in August 2026 that changed how logos, colours, and hero images render. Platform owners who hardcoded layout assumptions got to redo them. This keeps happening.

04

It is never your roadmap.

Wallet passes are a feature your customers want, not the product you sell. Every sprint spent on certificate rotation is a sprint not spent on the thing you actually compete on.

How it works

PassIssuer as the issuing layer under your platform.

The same model our direct customers use - system of record in, wallet credential out - applied one level up: your platform is the system of record, and your customers' brands are the templates.

One API, multi-brand by design

Create a template per customer brand - their logo, colours, fields, barcode format. Your platform calls one endpoint with the record; we render and issue the pass under their brand.

Your users never see us

Add-to-wallet pages, links, and QR codes carry your customer's branding. PassIssuer is the issuing layer underneath, not a logo on the pass.

Updates follow your data

When the booking moves, the ticket transfers, or the balance changes in your platform, push the new field value and every issued pass repaints - lock screen included.

Events flow back

Webhooks on pass add, update, and removal feed your platform's own analytics and lifecycle logic. You stay the system of record; we stay the issuing layer.

Commercially it stays simple too: one agreement with us, your pricing to your customers. We are the infrastructure line item, not a party in your customer relationship. EU-hosted from Berlin, with DPAs and security review support when your enterprise customers ask - and they will ask.

Is this you?

When the platform route makes sense.

  • You run a ticketing, booking, loyalty, membership, or vertical SaaS platform and your customers are asking for wallet passes
  • Passes must carry your customers' brands - white-label, no third-party logo
  • You want one integration that covers both Apple Wallet and Google Wallet
  • You don't want to own certificates, issuer accounts, or push infrastructure per brand
  • You need EU hosting and a GDPR posture your enterprise customers will accept
  • You want scan and lifecycle events flowing back into your own platform

Ship the feature. Skip the infrastructure.

Tell us what your platform does and what your customers are asking for. We will map the template model, the API flow, and a pilot with one of your customers.

Talk through your platform