Every pass in Google Wallet is published by an issuer, and Google does not hand out issuer status on signup. You create an account, it starts in a sandbox, and real distribution is gated behind a business review. None of it is hard, but the steps are spread across two consoles and three docs sections, and most teams find the sharp edges by walking into them.
Here is the whole path, in order, with the gotchas labelled.
What an issuer account actually is
An issuer account is your business's identity in the Google Wallet API. When it's created, Google assigns you an issuer ID — an auto-generated numeric identifier you don't get to choose. Everything you ever publish hangs off it: every pass class you define is identified as <issuerId>.<yourClassName>, whether it's a loyalty card, an offer, a gift card, an event ticket, or a generic pass.
One issuer ID, all your pass types. You do not need separate accounts per pass type — but as we'll get to, the "one per business" rule has real consequences if you're a platform issuing for many brands.
Step 1: Create the account in the Google Pay & Wallet Console
Go to the Google Pay & Wallet Console and sign in with the Google account that should own the issuer — this account becomes the admin, so use a role account, not an intern's personal Gmail. Enter your public business name, accept the Google Wallet API terms, and use Create a pass → Build your first pass on the dashboard to finalize the issuer account.
At this point you have an issuer ID and you're in demo mode.
Step 2: Understand demo mode before it surprises you
Demo mode is a real sandbox: you can create classes and passes and add them to phones. Two restrictions matter.
First, only admins, developers, and explicitly added test accounts can save your passes. Send the link to anyone else and it won't work.
Second, every pass you issue carries a [TEST ONLY] watermark at the top. It disappears from your passes automatically once you're approved for production — no reissuing needed — but do not schedule a customer-facing launch while you're still in demo mode and hoping the review lands in time.
Step 3: Complete the business profile
This is the step where issuer onboarding quietly becomes a payments-ops task. The business profile requires linking exactly one Google Payments Profile, and its country must match the business profile's country. Multi-country businesses need a separate business profile per country. You'll also provide your website, a support contact, and a merchant category code.
The profile status moves through Incomplete → In Review → Approved, and only Approved unlocks the console properly. If your company doesn't have a clean Payments Profile already, budget time for this — it's the least technical and most bureaucratic part of the chain.
Step 4: Set up API access (if you're calling the API)
If you'll issue passes programmatically rather than only from the console:
- Create or pick a Google Cloud project and enable the Google Wallet API in it.
- Create a service account and download its JSON key.
- Back in the Pay & Wallet Console, add the service account's email address as a developer on your issuer account.
That service account key does double duty: it authenticates REST calls (create, update, expire passes), and it signs the JWTs behind "Add to Google Wallet" links — the https://pay.google.com/gp/v/save/<signed-jwt> URLs that add a pass in one tap with no server call at all.
Step 5: Request publishing access
To leave demo mode you need two things: an approved business profile, and at least one pass class created — Google reviews what you actually intend to publish, so make that class a real one, not test-class-1. (Screenshots of your passes used to be required; they no longer are.)
Then request publishing access from the console. Google has historically quoted around two business days for this review, though that figure comes from their announcement blog post rather than a contractual SLA — plan for it to take longer. Once approved, the watermark drops off your existing passes and anyone can save them.
The Apple comparison, briefly
Apple gates issuing differently: a paid Apple Developer Program membership ($99/year), a Pass Type ID, and a signing certificate that expires annually and must be rotated — let it lapse and you can't sign new passes or push updates until you renew. Google charges nothing and uses a non-expiring service-account key, but adds the human review gate Apple doesn't have. Neither is difficult; both are permanent operational surface. If you support both wallets — and you should, because your customers carry both — you now own two credential regimes with different renewal calendars.
When you shouldn't get your own issuer account
If you're one brand issuing your own passes and you have engineering capacity, getting your own issuer account is the right call, and everything above is the map.
It stops being the right call in two situations. The first is when nobody on the team wants to own wallet infrastructure — the certificates, the service accounts, the push plumbing that keeps passes updating — as a forever-task next to the actual product. The second is when you're a platform: a ticketing system, booking tool, or loyalty engine whose customers each want passes under their own brand. Multiplying the setup in this guide across every brand you serve is exactly the trap we wrote about in white-label wallet passes for platforms.
In both cases the alternative is an issuing layer like PassIssuer: we hold the Google and Apple credentials, you send us records through a dashboard, CSV, or API, and branded passes land in both wallets. Your Google Wallet issuer account becomes a checkbox we handle, not a project you run. If that's the shape of your problem, talk to us.
Frequently asked questions
How much does a Google Wallet issuer account cost?
Nothing. Google charges no signup or per-pass fee for the Wallet API. Apple's equivalent requires a $99/year Apple Developer Program membership.
How long does Google Wallet issuer approval take?
Google has stated publishing-access reviews take up to two business days. Treat that as a typical figure, not a guarantee — complete your business profile early and don't put the review on your launch's critical path.
What is a Google Wallet issuer ID?
A unique numeric identifier Google assigns automatically when your issuer account is created. Every pass class you publish is namespaced under it, in the format issuerId.classId.
Why do my Google Wallet passes say [TEST ONLY]?
Your issuer account is still in demo mode. The watermark is removed from issued passes automatically once Google approves your publishing-access request — you don't need to reissue anything.
Do I need a separate issuer account for each brand?
An issuer account represents one business, and its business profile ties to one payments profile per country. Platforms issuing passes for many customer brands typically use an issuing provider that manages this on their behalf instead of onboarding every brand separately.
Do I need a Google Cloud project to use the Google Wallet API?
Only for API access. You enable the Wallet API in a Cloud project and authorize its service account in the Pay & Wallet Console. If you issue passes exclusively from the console UI, you can skip Cloud entirely.