How to Update a Google Wallet Pass After It Has Been Issued

One of the most compelling features of Google Wallet passes is that they are live objects — not static files. When you issue a pass, you are not handing over a PDF that the customer can never change. You are creating a record in Google's infrastructure that you can update at any time. Any change you make propagates to every device that has saved that pass. This guide explains the Google Wallet object model, how to make updates correctly and what the common update scenarios look like in practice.

The Google Wallet object model

Google Wallet organises passes around two entities: Pass Classes andPass Objects.

A Pass Class is the template — it defines the pass type (loyalty, event ticket, generic, and so on), the visual design, the programme name and any fields that are identical across all passes of that type. You create one Pass Class per programme.

A Pass Object is an individual issued pass. It references a Pass Class and contains the customer-specific data: their name, their loyalty points balance, their unique barcode value. When you issue a pass to a new customer, you create a new Pass Object. When you need to update a customer's pass, you update their Pass Object.

This separation means you can update the design or programme name in the Pass Class and the change propagates to all issued passes simultaneously — without touching individual Pass Objects. Conversely, updating a single customer's points balance means patching only their Pass Object.

PATCH vs PUT: always use PATCH

The Google Wallet REST API supports both PATCH and PUT operations on Pass Objects. They behave differently and the choice matters.

PATCH performs a partial update. You send only the fields you want to change, and Google merges them into the existing object. If you send a PATCH with a newloyaltyPoints.balance value, only the points balance changes — everything else stays as it was.

PUT replaces the entire object. You must send the complete Pass Object body. Any field you omit is deleted from the stored object. Using PUT without a full, current copy of the object risks silently losing data.

In practice, PATCH is almost always the correct choice. It is safer, requires less data transfer and reduces the risk of concurrent-write conflicts when multiple processes might update the same pass.

Which field changes trigger a notification

Not every PATCH sends a notification to the customer's device. Google Wallet distinguishes between silent updates and notified updates.

Silent updates happen when you change data fields — points balance, expiry date, barcode value. The pass updates on the device but no notification appears on the lock screen. The customer sees the new data next time they open their wallet.

Notified updates occur in two cases. First, when you change the passstate field — for example from ACTIVE to EXPIRED orINACTIVE. Second, when you include an addMessageRequest body in your PATCH. The addMessageRequest is the recommended way to send an explicit notification alongside a data update.

Changes to validTimeInterval also trigger device sync, though whether a visible notification appears depends on the device and Google Wallet version.

Using addMessageRequest

addMessageRequest lets you attach a message to a Pass Object that appears as a notification on the customer's device. The message has two text fields:header (a short title, similar to a push notification title) and body(one to two sentences of supporting copy).

Include addMessageRequest as a top-level field in your PATCH request body alongside the data fields you are updating. Google will apply the data change and queue the notification simultaneously.

Keep the header under 50 characters and the body under 100. Lock screen notifications truncate on most devices, and a message that gets cut off mid-sentence is worse than a concise one. Example: header “You've reached Gold status” — body “Your benefits have been upgraded. Open your pass to see what's new.”

Common update scenarios

1. Incrementing a loyalty points balance. The most frequent update for loyalty programmes. PATCH the Pass Object with the new loyaltyPoints.balance value. Include an optional addMessageRequest if you want the customer to see a lock screen notification — “You earned 50 points. Total: 1,240.” For high-frequency updates (multiple transactions per day), consider batching updates and sending a single end-of-day notification rather than one per transaction.

2. Extending an expiry date. Renewal events, promotional extensions or correcting an incorrect date. PATCH the validTimeInterval.end field with the new ISO 8601 datetime. No notification is needed unless the change is meaningful to the customer — an automatic renewal extension can be silent; a manually requested extension warrants a confirmation message.

3. Upgrading a tier from Silver to Gold. Update the relevant text fields — secondClassHeader, textModulesData or whichever fields your Pass Class uses for tier display. Include an addMessageRequest here — a tier upgrade is a moment worth celebrating. Optionally update the Pass Class to define Gold-tier colours and images, or use a separate Pass Class per tier and re-issue the pass.

4. Voiding a pass after a refund. Set the Pass Object state field to INACTIVE. The pass displays as inactive in the customer's wallet and the barcode becomes unscannable. If the refund was requested by the customer, add a message confirming the void. If it was triggered by fraud detection, a silent state change is appropriate.

Best practices for live pass management

Log every state change. Maintain a record in your own database of every PATCH you send — what changed, when and why. Google Wallet does not provide a change history for Pass Objects, so your own audit trail is the only way to debug issues or respond to customer queries.

Update your own modifiedDate field. If your Pass Object schema includes a last-modified timestamp in its text modules, update it alongside every PATCH. It gives customers confidence that what they are seeing is current.

Do not over-notify. addMessageRequest messages accumulate on the pass — the customer can scroll back through past messages. Sending too many dilutes the impact of important ones. Reserve notifications for moments that genuinely warrant interruption.

Handle idempotency carefully. If your system retries failed requests, ensure PATCH requests are idempotent or include deduplication logic. A points-increment PATCH that runs twice will double the increment unless you send the absolute new value rather than a delta.

Update the Pass Class for design changes. If you rebrand or update your programme name, update the Pass Class — not every Pass Object individually. Class-level changes propagate to all issued passes automatically.

How Issuepass simplifies Google Wallet updates

Working directly with the Google Wallet REST API requires managing a service account, handling JWT authentication and constructing the correct request bodies for each update type. Issuepass abstracts this entirely.

From the Issuepass dashboard, you can update any pass field for a single pass or a segment of passes without writing any code. From the API, a single PATCH request to the Issuepass endpoint updates both the Google Wallet Pass Object and the Apple Wallet pass simultaneously — you do not need separate logic for each platform.

For programmatic updates, the Issuepass API accepts the same field structure regardless of platform and handles the platform-specific translation internally. This means you write one update and both wallet platforms stay in sync.

Start free and manage your Google Wallet passes without the boilerplate.