What is a pass issuer?

The source

"Pass issuer" is Google's term, and it's precise.

Google Wallet's developer documentation defines a Pass Issuer as the entity that creates passes, issues them to users, owns them, and can update them — see Google's Pass Issuer definition. Google is explicit that this includes aggregators: companies that issue passes on behalf of other organisations.

The pass issuer is defined by the role, not by the brand on the pass. Whoever holds the account, signs the payloads, and pushes the updates is the issuer. If that's you, you're the issuer. If it's a provider working from your data, the provider is — Google designed the system to allow exactly that.

Terminology

Pass issuer vs. issuer account vs. issuer ID.

Three things get conflated constantly, so let's separate them once.

Pass issuer

An entity — a company, playing a role. Defined by what it does: create, issue, own, update.

Issuer account

The Google Wallet API account that entity holds. An object in Google's system, created through the Google Pay & Wallet Console.

Issuer ID

The numeric identifier Google assigns to that account. Every pass class and pass object lives under one.

The issuer ID represents accountability: who can create classes, mint pass objects, and push updates to phones. It says nothing about whose logo renders on the pass. One issuer ID can carry passes for many brands — that's the aggregator model, and it's not a workaround. It's in the terminology page.

Apple Wallet

Apple has no "issuer" — the role exists anyway.

An Apple Wallet pass is a signed bundle. To create one, you need an Apple Developer account, a Pass Type ID registered under it, and a signing certificate issued against that Pass Type ID. Every pass you generate is cryptographically signed with that certificate. Whoever holds the certificate is — functionally, unarguably — the issuer. Apple just expresses the role in X.509 instead of prose.

Updates work the same way: the signer runs web service endpoints that devices register against, and sends silent pushes through APNs to tell a phone its pass changed. So "who issues Apple Wallet passes?" has a one-line answer: whoever controls the Pass Type ID and its certificate. Same role as Google's pass issuer, different plumbing.

One more thing Apple's model adds: those signing certificates expire every year. Miss the rotation and you can't sign new passes. This bites teams that built wallet support once, shipped it, and moved on. It is the single most common way a working pass integration breaks.

The role

What a pass issuer actually does.

Generating a pass file once is the easy part. Being a pass issuer is an operations job, and the operations are the point.

A pass on a phone is a promise that it stays correct. Points balances change. Tickets get rescheduled. Tiers upgrade. Offers expire. The issuer is the party that pushes every one of those changes to every installed pass — through Google's update API on one side, and through APNs plus device-registration endpoints on the other. Two platforms, two completely different update mechanisms, one job: the pass in the wallet matches reality.

That's why the issuer role matters commercially.

Build vs. buy

Do you need to become a pass issuer yourself?

Build it yourself.

You take on the role directly. That means, concretely:

A Google Wallet issuer account, a service account, and JWT signing for every pass you create
An Apple Developer account, a Pass Type ID, and signing certificates — plus annual certificate rotation, forever
Pass generation for both platforms' formats
Update infrastructure: APNs integration, device registration endpoints, and Google's update API
Monitoring, so you find out a push broke before your customers do

Use a pass issuer provider.

You send customer, member, or ticket data — over an API or a CSV. The provider operates everything in column one and returns Add to Wallet links.

Your CRM, ticketing system, or database stays the source of truth; the provider's job is getting that truth into the wallet and keeping it there. This is precisely the aggregator arrangement Google's terminology anticipates: the provider is the pass issuer of record, issuing on your behalf, and your brand is what the customer sees.

Some companies genuinely should build it. If wallet passes are your product — if you're a ticketing platform, a transit operator, an airline — the issuer role is core infrastructure and you should own it outright, with a team that treats it like production software. Because it is.

Most companies are not that. For most companies, the wallet pass is a feature of a loyalty program, a membership, an event — not the business itself. Building two platforms' worth of signing, push, and registration infrastructure to support a feature is a bad trade. You'll build it once, staff it never, and discover the cost the day a certificate expires or an update API changes. Most companies should not become pass issuers themselves. They should use one.

The division of labour

What a pass issuer handles when you hire one.

Issuer accounts and certificates

The Google issuer account and service account on one side, the Apple Developer account, Pass Type ID and signing certificates on the other.

Generation and signing

Every pass rendered and cryptographically signed for the platform it is going to, in the format that platform expects.

The update pipelines

APNs and device registration on Apple, the update API on Google. Two mechanisms, one outcome: the pass in the wallet matches reality.

Certificate rotation

Handled before it becomes an incident, rather than discovered the day new passes stop signing.

Multi-tenant issuing

One integration issuing under many brands or locations, if you run passes for more than your own.

What stays with you

Your data, your design decisions, and an Add to Wallet link to put in front of customers.

Where we fit

PassIssuer is a pass issuer provider.

We operate the Apple Wallet and Google Wallet infrastructure — accounts, certificates, signing, push updates, registration — and issue passes from your data, under your brand. There's an API and webhooks for integration, a dashboard and CSV import when you'd rather not integrate at all, live pass updates, geofenced lock-screen messages, and white-label multi-tenant issuing if you're a platform issuing for your own customers.

We're built and hosted in the EU — Germany, specifically — and we store only what the pass needs to render, which keeps the GDPR conversation short. We'll sign a DPA and sit in your security review.

If you want the mechanics of the passes themselves rather than the role, start with how wallet passes work. If you're weighing running your own Google account, we wrote up how to get a Google Wallet issuer account.

FAQ

Pass issuer questions, answered.

What does “pass issuer” mean?

A pass issuer is the entity that creates wallet passes, delivers them to users' phones, owns them, and updates them afterwards. The term comes from Google Wallet's developer documentation, but the role exists identically on Apple's side. It can be the brand on the pass or a provider issuing on that brand's behalf.

What is a Google Wallet issuer ID?

It is the numeric identifier Google assigns to an issuer account in the Google Pay & Wallet Console. Every pass class and pass object is created under an issuer ID, and it determines who can mint and update those passes. It identifies the operating entity, not the brand displayed on the pass.

Who issues Apple Wallet passes?

Whoever controls the Pass Type ID and its signing certificate. Apple never uses the word “issuer”, but every pass is signed with a certificate tied to a specific Apple Developer account, so the certificate holder is the issuer in practice. Those certificates expire annually and must be rotated to keep issuing.

Do I need my own Google Wallet issuer account?

Only if you are operating the pass infrastructure yourself. If you use a pass issuer provider, passes are issued under the provider's account with your branding — an arrangement Google's own terminology explicitly supports. You need your own account when you want to own the signing, update, and monitoring stack directly.

What is a pass issuer provider or aggregator?

A company that acts as the pass issuer on behalf of other organisations. Google's documentation names aggregators as a recognised type of pass issuer. You send the data; the provider runs the wallet accounts, certificates, signing, and update infrastructure for both platforms, and returns Add to Wallet links carrying your brand.

Can a pass issuer update passes after they are installed?

Yes — that is most of the job. On Google Wallet, the issuer updates pass objects through the API and the change reaches installed passes. On Apple Wallet, the issuer sends a silent push through APNs and the device fetches the new version from the issuer's servers. Only the issuer can do this, which is why the role carries ongoing operational responsibility, not a one-time setup.

Looking for a pass issuer?

PassIssuer issues and manages Apple Wallet and Google Wallet passes for businesses — you send the data, we operate the infrastructure. Tell us what you're issuing and we'll tell you exactly how it would work.

Talk to us Start self-serve