Issue an Apple Wallet or Google Wallet pass with one POST, then keep it current for as long as your customer keeps it. PassIssuer operates everything underneath — signing, push delivery, device registration — so your integration stays one clean surface.
Your backend talks to one REST API. We talk to Apple and Google. That split is the whole product: you send the fields you already have, and everything wallet-specific — the two rendering pipelines, the two credential regimes, the two update mechanisms — happens on our side of the line.
Your system of record: the CRM row, the order, the ticket, the membership.
Templates, issuance, signing, updates, lifecycle events. EU-hosted in Berlin.
The pass in your customer's pocket, repainted by push whenever the record changes.
One POST with the fields from your record. PassIssuer renders the pass and keeps it in sync: REST, webhooks, idempotent retries. Or wire it to your CRM and never touch code at all.
Define a template. Issue a pass from a record in your system — one POST carrying the fields you already store. The response comes back with Add to Wallet links for both Apple Wallet and Google Wallet; put them in an email, an SMS, a signup page, a QR code taped to the counter. When the record changes, update the fields on the issued pass and the wallet repaints it — no reinstall, no new link, nothing asked of the customer. When the program ends, expire or revoke the pass. Every step in that lifecycle reports back to you as an event.
That one request is the entire issuance path. Everything below it — rendering, signing, platform delivery — is our problem, not a sprint on your board. A sandbox issuer and test templates are provisioned for your integration when you start, so you build against real passes on real test devices before anything touches a customer.
Most of the pain in wallet passes is not the API call. It is the ceremony around it: an Apple Developer account, Pass Type IDs, signing certificates that expire on their own schedule, a Google Wallet issuer account, a service account, JWT signing. None of that ships features.
You authenticate with a scoped API credential. PassIssuer holds the Google service account and the Apple signing certificates on your behalf, so your team never touches wallet-provider credentials, never manages certificate rotation, and never handles JWT signing. One secret in your vault. That is the entire credential footprint of the integration.
If you would rather hold those credentials yourself, that is a legitimate choice — we set out both paths in what is a pass issuer.
A template defines the pass once — layout, colours, logos, field structure — for both platforms. Issued passes are instances of it: your record's data poured into that structure. Change the template and every issued pass repaints. Change the record and that one pass repaints. The pass in the wallet is a projection of your data, not a PDF you emailed once and lost control of.
Barcodes are part of the template. PassIssuer supports every barcode format Apple Wallet and Google Wallet themselves support — if the wallet can render it, your scanner line can read it.
A pass is not a dead-end channel, and an integration that only pushes outward is half an integration. PassIssuer emits lifecycle events — pass added to a wallet, pass updated, pass removed, pass scanned or redeemed — and delivers them to an endpoint you control, straight into your own systems and audit trail.
This is where wallet passes stop being a marketing artifact and start being state you can act on. A pass added is an activation you can attribute. A scan is ground truth of redemption, at a location, at a time — not a self-reported survey answer. A pass removed is a churn signal most programs never see at all. Route the events into your CRM and the wallet becomes a channel your existing automations already understand. Your database stays the source of truth in both directions: you write to the wallet through the API, the wallet writes back through webhooks.
Multi-tenant issuing is baked in, not bolted on. One integration can issue passes under many customer brands — separate templates, separate branding, separate pass populations, one API surface.
If you run a SaaS platform, a POS, a booking system, or an agency, this is the difference between "we integrated wallet passes" and "wallet passes are a feature we sell." Your customers get passes under their own brand in their end-users' wallets. You get one credential, one webhook stream, and one integration to maintain. You never open an Apple Developer account for a client, and neither do they. There is a fuller write-up in wallet passes for platforms.
The API is the spine, not the only door. The dashboard issues and updates passes by hand. CSV import moves an existing member list, plastic-card file, or ticket manifest into wallets without a line of code. And direct integration with your CRM, POS, ecommerce, or ticketing stack is built as part of the engagement — integration work is the product here, not a services add-on billed after the fact. Plenty of programs go live on imports and dashboard workflows first and wire up the API when the volume justifies it.
An in-house wallet pass build is not one project; it is two platforms' worth of permanent operations. Signing infrastructure. Certificate expiry. Push delivery and its failure modes. Device registration state for every pass in the field. Two vendors' review processes and format changes. All of it sits on PassIssuer's side of the API.
The platform is EU-hosted in Berlin and operated by Ongoing Things UG. We support security review during procurement, and a DPA is available. Pricing is on the pricing page — this page is about the machine.
No. PassIssuer holds the Apple signing certificates, Pass Type IDs, and the Google issuer and service accounts on your behalf. Your team authenticates with a scoped API credential and never touches wallet-provider infrastructure. That is the point of the platform.
You update the fields on the issued pass through the API, and PassIssuer pushes the change to the device — over APNs for Apple Wallet and Google's update infrastructure for Google Wallet. The customer does nothing; the pass they already added simply repaints. Device registration and push delivery are operated entirely on our side.
Yes — multi-tenant issuing is a first-class capability, not a workaround. One integration issues passes across many brands, each with its own templates and design, while you keep a single API credential and a single webhook stream. It is built for SaaS platforms, POS vendors, and agencies shipping white-label wallet passes.
A sandbox issuer and test templates are provisioned for your integration when you start. You issue real passes to your own test devices, exercise updates and webhooks end to end, and validate the flow before anything reaches a production customer.
Your brand assets, the shape of the record a pass should mirror, and a conversation about your stack. From there we provision your sandbox and templates and scope the integration with you — including direct CRM, POS, or ecommerce wiring where that is the right path.
The platform is EU-hosted in Berlin and operated by Ongoing Things UG, a German company. We support security review as part of procurement, and a DPA is available.
Tell us what you issue — stamps, tickets, memberships, gift cards — and what stack it lives in. We'll scope the integration with you, sandbox first.
Talk to us about integration