> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/configure/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account.md).
# Google Wallet Account
Set up Google Pay & Wallet Console access and Google Wallet API credentials so The Wallet Crew can issue passes under the brand's own identity.
Configure the Google Wallet integration using either delegated access (recommended for faster setup) or self-managed configuration. This guide covers account creation, API enablement, and credential management for deploying digital wallet passes through The Wallet Crew platform.
## Overview
To distribute digital passes through Google Wallet, the organization must get a Google Pay & Wallet Console issuer account approved and configure a Google Cloud project for API access. Google approves issuers manually, so plan **3–5 business days** for approval, plus **15–60 minutes** for the technical setup.
**Main things to configure**
* A Google Pay & Wallet Console issuer account (approval required)
* A Google Cloud project with Google Wallet API access
The core Google services are created under the brand (Google Cloud project + Google Pay & Wallet Console approval). The remaining configuration can then be delegated to The Wallet Crew, or completed internally, with the required values pasted into The Wallet Crew.
Want the “why” before the “how”? Start with [Apple & Google wallet](/configure/advanced-configuration/wallet/apple-and-google-wallet.md).
#### Prerequisites
* Google Workspace or Gmail account with admin privileges
* Company information for Google Pay merchant verification
* Authority to create service accounts in Google Cloud
## Google Cloud project configuration
Navigate to the Google Cloud Console and sign in with the company Google account.
Create a new project using the naming convention `thewalletcrew-` where `` matches the organization or brand identifier. For example: `thewalletcrew-acmecorp` or `thewalletcrew-retailstore`. This naming helps identify the project's purpose at a glance.
### Account delegation
This approach allows The Wallet Crew team to handle the technical configuration while the brand retains ownership of all accounts and credentials. Temporary access is granted, and we configure everything according to best practices.
In the IAM & Admin section, select **IAM** from the left navigation menu. Click the **Grant Access** button and add `contact@neostore.cloud` as a project owner. This permission level allows The Wallet Crew team to create service accounts, enable APIs, and configure all necessary resources. This access can be revoked after initial setup is complete.
Google Cloud IAM: grant project access
This way, the Google Wallet passes are issued under the organization's identity, not The Wallet Crew's. The project created here establishes that organizational identity in Google's systems.
### Configuration on your own
The full setup is managed within the brand's own Google Cloud and Google Pay accounts.
To access the Google Pay & Wallet Console, [sign up](https://support.google.com/pay/merchants/contact/instore_merchants) first. After the form is submitted, the support team makes contact to validate the use case and enable the issuer account.
{% stepper %}
{% step %}
**Create a service account**
1. Go to the Credentials page.
2. Ensure the current project is `thewalletcrew-`
3. Click **Create credentials → Service account**.
Create a new service account
4. Fill the form:
* Service account name: `TheWalletCrew`
* Service account id: keep the autogenerated value
Service account name and ID
5. Click **Done** to complete the service account creation.
Note the email address generated for the service account. Example: `thewalletcrew@thewalletcrew-123456.iam.gserviceaccount.com`. It is needed later in the Google Pay & Wallet Console.
{% endstep %}
{% step %}
**Create and download a JSON key**
1. Open the service account just created. Then go to the **Keys** tab.
Open the Keys tab
Create a new key
2. Click **Add key → Create new key**.
Start creating a JSON key
3. Choose **JSON** and click **Create**.
Select JSON key type
4. Save the generated file to a secure location. It is uploaded later in The Wallet Crew admin console.
{% hint style="warning" %}
Treat this JSON file like a password.
{% endhint %}
{% endstep %}
{% step %}
**Enable the Google Wallet API**
Go to the Google Wallet API page and enable API access.
{% endstep %}
{% endstepper %}
## Google Pay & Wallet Console configuration
Navigate to the Google Pay & Wallet Console and sign in with the company Google account.
### Account delegation
Navigate to the Users section. Add `contact@neostore.cloud` with **Administrator** permission. This allows The Wallet Crew team to configure the issuer settings and complete the integration.
Add a user with Administrator access
The Wallet Crew team will receive a notification of the access grant and will proceed with service account creation, API enablement, and credential configuration. We notify the brand when the setup is complete and provide the credentials for safekeeping.
### Configuration on your own
{% stepper %}
{% step %}
**Invite the service account**
1. Navigate to the Users section.
Open the Users section
2. Click **Invite a user**.
Fill the form with the following information:
* Email address: the one noted at step 1.4
* Access level: **Developer**
Invite the service account email
Choose the Developer role
Then click **Invite**.
Send the invitation
{% endstep %}
{% step %}
**Complete establishment information**
1. Click **Establishment details** and verify that all the information is filled and approved.
Confirm establishment details are approved
2. Click **Google Wallet API**.
Copy the issuerId
Note the `issuerId`. It is needed in The Wallet Crew admin console.
{% endstep %}
{% endstepper %}
## Configure The Wallet Crew
For a self-managed setup, go back to The Wallet Crew admin console and open Wallet > Configuration > Google.
Fill the form with:
* the service account JSON key downloaded earlier
* the `issuerId` from the Google Pay & Wallet Console
Paste issuerId and upload the JSON key
#### Request public access (only if needed)
If testing with a Google pass produces the following error:
Error when public access is required
Go back to Google Wallet API:
Request public access from Google
Then ask for public access. One of these templates can be used.
Email template — loyalty card usage
> Hello,
>
> We'd like to use the Google Wallet API to generate loyalty cards in-store. The customer can scan a QR code (example: xxxx), then create or retrieve their account and add a loyalty card to their wallet.
>
> We work with The Wallet Crew for this.
>
> Regards,
Email template — event usage
> Hello,
>
> We'd like to use the Google Wallet API to generate event tickets. The customer will receive an email with a download link and add their tickets to their wallet. We will also display an “Add to Wallet” button on our website after purchasing tickets.
>
> We work with The Wallet Crew for this.
>
> Regards,
## FAQ
How long does Google approval take?
Google approves issuer access manually. Plan **3–5 business days** for approval. Then plan **15–60 minutes** for the technical setup (service account, API enablement, and issuer configuration).
What do we need to configure in The Wallet Crew administration console?
Two things are needed: a **service account JSON key** from Google Cloud (service account → **Keys**) and the **`issuerId`** from the **Google Pay & Wallet Console** (Google Wallet API section). Once these are pasted or uploaded in Wallet > Configuration > Google, The Wallet Crew can authenticate and issue passes under the brand's issuer.
Do we need a dedicated Google Cloud project?
Yes. A dedicated project keeps wallet configuration isolated from other cloud workloads. It also makes access review, billing, and auditing much easier.
What is the “service account” used for?
The service account is the machine identity used to call Google Wallet APIs server-to-server. It is not a human user. The Wallet Crew uses the service account JSON key to authenticate those API calls.
How should we store the service account JSON key?
Treat the JSON key like a password. Upload it to The Wallet Crew over the admin console, then store it only in a secret manager (or delete it if no copy is needed). Avoid sharing it over chat or email, and rotate it immediately if exposed.
Why do we need to invite a user/service account in Google Pay & Wallet Console ?
Google Pay & Wallet Console controls who can manage the issuer. If the service account is not invited, Google Wallet API calls will fail even if the Cloud project is correctly configured. In self-managed setup, invite the **service account** as a user with the **Developer** role.
What does “Enable the Google Wallet API” actually do?
It enables the Google Wallet API endpoint (`walletobjects.googleapis.com`) in the Cloud project. Without this, requests will fail with authorization errors such as “API not enabled”.
We get an error asking for “public access”. What does it mean?
Some issuers need an extra approval step from Google before they can distribute passes broadly. This often shows up when moving from testing to real-world distribution. Use the email templates in this guide to request public access from Google.
Can we revoke delegated access after go-live?
**Yes**. Once issuance and pass updates are validated end-to-end, revoke delegated access in both places: remove The Wallet Crew from the **Google Cloud** project IAM, and remove the user from the **Google Pay & Wallet Console** Users list. Do this only after real saves and at least one successful update have run, so production is not accidentally broken.
Should we renew the configuration yearly?
Usually **no**. This setup is not something to “renew” on a schedule.
Only redo the configuration in The Wallet Crew if something changed on the Google side, for example:
* The service account JSON key was **rotated or replaced**.
* The key was **revoked/disabled**, or it is suspected to have been exposed.
* The setup switched to a **different Cloud project** or **issuerId**.
* IAM / Console permissions were changed and issuance stopped working.
If nothing changed and passes still issue/update correctly, leave it as-is.
We already have existing passes. How do we migrate to The Wallet Crew?
This is a **migration** of live passes, not a normal “reconfigure”.
On Google, passes are tied to a **Google Pay & Wallet Console issuer account**. Live passes cannot be transferred to a different issuer. Plan to keep the same issuer and move the operational setup (credentials + pass data) to The Wallet Crew.
Follow the dedicated guide: [Move passes to The Wallet Crew](/configure/advanced-configuration/wallet/import-and-export/pass-migration/move-passes-to-the-wallet-crew.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.thewalletcrew.io/configure/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
