Google Wallet Pass Types Explained: Which Class Is Right for Your Business?

Google Wallet organises passes into a class hierarchy: every pass belongs to a class that defines the template and shared properties, and each individual pass is an object that carries the recipient-specific data. There are six pass classes available — LoyaltyClass, EventTicketClass, GenericClass, OfferClass, GiftCardClass, and TransitClass — and the choice of class determines the visual layout, the available fields, and the context in which Google surfaces the pass to the user.

Choosing the right class is a foundational decision. Google Wallet renders each class with a distinct layout. An OfferClass pass looks and behaves differently from a LoyaltyClass pass even if the content were identical. The class also affects how Google surfaces the pass — on the lock screen, in maps, and in search — so using the semantically correct class increases the likelihood that the pass appears at the right moment.

This guide explains each Google Wallet pass class, its visual structure, its real-world use cases, and how to decide which one is appropriate for your business.

How the Class and Object Model Works

Unlike Apple Wallet, where each pass file is self-contained, Google Wallet separates the pass into two layers. The class defines the design, branding, and field structure shared across all passes of that type — the logo, background colour, hero image, and which fields appear. The object contains the data for a specific recipient: their name, barcode, loyalty points balance, or ticket seat number.

This means you create one class (the template) and then create thousands of objects against it. Updating the class — changing the hero image or adding a new field — propagates to all objects issued against that class. This is more efficient than Apple's model when managing large pass programmes, because design changes do not require re-issuing every pass.

All six pass classes are accessible via the Google Wallet API. Platforms like Issuepass abstract this into a template editor, so you work with the visual design rather than the raw API structure.

LoyaltyClass

The LoyaltyClass is Google Wallet's dedicated loyalty card format. It is designed to represent an ongoing membership or rewards relationship between a business and a customer, and its layout reflects that purpose: it prominently displays the member's name, their loyalty points or tier, and a barcode for identification at point of sale.

Visual structure: A hero image fills the top section of the pass. Below it, the loyalty points balance or programme name appears prominently. The member name and card number are displayed in a structured grid. A barcode or QR code sits at the bottom for scanning at the till.

Key fields: loyaltyPoints (balance display with label), secondaryLoyaltyPoints (secondary balance, e.g. stamps), accountName, accountId, and up to six text module rows for additional information.

Use cases: Retail loyalty programmes, coffee shop stamp cards, hotel rewards membership, airline frequent flyer cards (non-boarding), supermarket loyalty cards, pharmacy rewards programmes. Any programme where a customer accrues value over time and identifies themselves at point of sale.

When to choose it: Use LoyaltyClass whenever the pass represents an ongoing reward relationship. The points display is a first-class field, not something you have to hack into a text module. If you are building a points or stamps programme and want the balance to update automatically as customers earn, LoyaltyClass is the correct choice.

EventTicketClass

The EventTicketClass is for passes that grant admission to a specific event. It is the most visually prominent of the six classes — it supports a wide hero image and displays event details (name, venue, date, time) in dedicated structured fields. The layout is immediately recognisable as a ticket.

Visual structure: A hero image at the top, followed by the event name in large text, then structured fields for date/time, venue name, seat/row/section, and gate. The barcode appears below the structured fields. The pass also displays a thumbnail logo in the top left.

Key fields: eventName, venue (with name and address), dateTime (start and end), seatInfo (seat, row, section, gate), ticketHolder, and ticketNumber.

Use cases: Concert tickets, sports event tickets, theatre admissions, conference day passes, museum timed-entry passes, cinema tickets, festival passes. Any event with a defined date, time, location, and specific admission credentials.

When to choose it: Use EventTicketClass for any time-bound, location-specific admission pass. The structured date/time and venue fields are rendered in a standardised way that Google uses to surface the pass contextually — near the venue, around the event time — so using this class rather than GenericClass meaningfully improves the user experience.

GenericClass

The GenericClass is Google Wallet's flexible, catch-all pass type. It is the equivalent of Apple Wallet's generic type: no strong visual convention, no mandatory structured fields specific to a domain, maximum flexibility. It supports a hero image, logo, a card title, and text modules for structured content.

Visual structure: A hero image at the top, the card title below it, then a grid of text modules. The header and subheader fields appear near the top for the most important credential data. The barcode appears at the bottom.

Key fields: header, subheader, cardTitle, and an array of text module rows for any additional structured content. The pass is intentionally open — the fields you choose to populate determine what the pass displays.

Use cases: Membership cards, ID credentials, employee badges, library cards, access passes, student ID cards, digital business cards, subscription passes, healthcare appointment passes. Any pass that does not fit cleanly into the other five classes.

When to choose it: Use GenericClass as your default for credentials and memberships that are not retail-loyalty, event, transit, offer, or gift card specific. It gives you the most control over how the pass reads. Many Issuepass customers building membership programmes, gym passes, and access credentials use GenericClass because its flexibility suits passes that carry identity-type information rather than transactional value.

OfferClass

The OfferClass is for promotional offers, coupons, and discounts. It is the Google Wallet equivalent of Apple Wallet's coupon type. The layout is designed to communicate an offer clearly and quickly: the offer title and redemption value are prominent, and the terms of the offer appear below.

Visual structure: A hero image or logo at the top, followed by the offer title and redemption value in large text. Below that, structured fields for the offer details, valid time window, and any relevant terms. The barcode sits at the bottom for redemption.

Key fields: title (offer headline), titleImage, redemptionChannel (online, instore, both), provider, helpUri, and text modules for terms and conditions. The validTimeInterval field defines the offer's validity window and is used by Google to determine when to surface the pass.

Use cases: Discount vouchers, percentage-off promotions, free item offers, buy-one-get-one passes, trial offers, referral rewards passes, seasonal sale passes. Any offer where the primary value is a discount or promotional benefit.

When to choose it: Use OfferClass for time-limited promotional passes. The validTimeInterval field is important: set it correctly and Google will automatically surface the pass when it becomes valid and suppress it after expiry. Use LoyaltyClass instead if the pass represents an ongoing programme; the OfferClass is for discrete, time-bound promotions.

GiftCardClass

The GiftCardClass represents a prepaid card or gift card with a monetary or credit balance. It is structurally similar to LoyaltyClass but optimised for displaying a balance rather than points, and carries the conventions users expect from a payment card rather than a loyalty card.

Visual structure: A hero image and logo at the top, then the card balance displayed prominently with a currency label. The card number and PIN (where applicable) appear in dedicated fields. The barcode is used for redemption at point of sale.

Key fields: balance (with currency code), balanceUpdateTime, cardNumber, pin, and text modules for additional information such as terms of use and customer service contact details.

Use cases: Retail gift cards, store credit vouchers, prepaid dining credit, promotional credits (e.g. a £10 welcome credit issued when a customer signs up), digital vouchers for online stores. Any pass that carries a specific monetary value that decreases as it is spent.

When to choose it: Use GiftCardClass when the pass holds a specific monetary balance. The balance field is a first-class field in this class — Google renders it with the currency symbol and label in a standardised way. If you want to update the displayed balance as the customer spends, GiftCardClass objects support balance updates via the API. Do not use GenericClass and manually put a balance in a text module; the GiftCardClass renders this information correctly and the user experience is better.

TransitClass

The TransitClass is Google Wallet's transportation pass type, equivalent to Apple Wallet's boardingPass. It is designed for passes that represent a journey: a ticket from one place to another, with an origin, a destination, and a departure time.

Visual structure: Origin and destination displayed prominently, with the transit operator logo and name. Structured fields for departure time, arrival time, fare class, seat or carriage number, and a validation barcode. The transit type (air, rail, bus, ferry, or other) affects the iconography used in the pass layout.

Key fields: origin and destination (with station/airport name and code), departureDateTime, arrivalDateTime, transitOperatorName, transitType, ticketNumber, and fare information fields.

Use cases: Rail tickets, airline boarding passes, bus tickets, ferry passes, underground/metro tickets, shuttle bookings, intercity coach tickets. Any pass that represents a journey between two defined points.

When to choose it: Use TransitClass for any transportation pass. Google surfaces transit passes contextually based on departure time and station/airport location — functionality that only works correctly when you use TransitClass rather than a generic pass with manually entered location information. If you are building a rail or airline integration, this is the correct class.

How Google Surfaces Passes Contextually

One of Google Wallet's strongest features is contextual pass surfacing. Google uses the structured data in each pass class to determine when and where to present the pass to the user — without the user needing to open the Google Wallet app.

An EventTicketClass pass surfaces on the home screen and lock screen as the user approaches the event venue, timed around the event start. A TransitClass pass surfaces at the relevant departure station or airport around departure time. An OfferClass pass can surface when the user is near a merchant location included in the offer.

This contextual surfacing only works correctly when you use the semantically appropriate pass class. A generic pass with an event date stored in a text module will not trigger the same contextual behaviour as an EventTicketClass pass with the correct dateTime field populated. Choosing the right class is not just cosmetic — it determines the quality of the user experience at the moment the pass is most needed.

Choosing Between Classes: A Practical Decision Tree

Does the pass represent a journey with a departure and arrival point? Use TransitClass.

Does the pass grant admission to a specific event on a defined date? Use EventTicketClass.

Does the pass represent a loyalty points or stamps programme? Use LoyaltyClass.

Does the pass represent a discount or promotional offer with an expiry? Use OfferClass.

Does the pass hold a specific monetary balance? Use GiftCardClass.

Does the pass represent a credential, membership, or identity card? Use GenericClass.

When in doubt, GenericClass is the safe default. It will not trigger contextual surfacing as reliably as a class with structured time or location data, but it produces a clean, professional pass for almost any use case.

How Issuepass Handles Google Wallet Pass Classes

Issuepass supports all six Google Wallet pass classes. When you create a template, you choose the class as part of the setup. The template editor surfaces the correct fields and image slots for that class, and you can preview how the pass will render before issuing.

The class-and-object model means that pass design updates are efficient: update the class template in Issuepass and the change propagates to all issued passes without needing to re-push every object. Loyalty point balances and gift card balances can be updated via the API or via CSV import.

Issuepass handles both Apple Wallet and Google Wallet from a single template, so you design once and issue passes that work for customers on either platform. The pass type mapping — from your chosen category to the correct Apple and Google class — is handled automatically.

Ready to issue Google Wallet passes for your business? Start free and create your first Google Wallet template today.