A Google Wallet pass is built from a **class** and an **object**, not a single signed file like an Apple Wallet `.pkpass`. The class holds the shared template — branding and program-level details that apply to every pass issued under it. The object holds the per-holder instance — the data specific to one user, linked back to its class by a class ID. PassFast dual-issues Apple and Google from one generate call, so you skip standing up both signing stacks yourself.
Class: the reusable template for a pass type. It's where you define issuer-level and program-level presentation — things like branding and shared layout — once, and every object issued under that class inherits it.
Object: one pass instance issued to one holder. It references its class and carries the holder-specific data and state for that pass — the parts that differ from person to person or change over time.
This split is different from Apple Wallet, where each .pkpass is a self-contained signed bundle with no separate shared template resource. If you're coming from Apple pass.json and comparing the two models, that's the core structural difference to keep in mind — see Anatomy of an Apple Wallet pass for the Apple side.
Google Wallet defines a set of typed class/object pairs for common use cases — for example loyalty, offer, gift card, event ticket, flight (boarding pass), and transit passes, plus a generic type for cases that don't fit a specialized type. Each typed pair follows the same class/object split described above, with fields scoped to what that pass type needs. For the authoritative, current list of types and their fields, check Google's Wallet API documentation rather than treating any third-party summary — including this one — as exhaustive.
PassFast issues Apple and Google Wallet passes from a single generate call, rather than requiring you to build and maintain two separate signing pipelines. Apple and Google outputs from that one generate count as a single active unit — you don't pay for or manage them as two separate passes.
That means you don't need to learn the full class/object model yourself to ship a Google Wallet pass, or maintain a second signing stack alongside Apple's — PassFast handles issuing both sides from the data you send once.
Same outline in markdown: passfa.st/blog/anatomy-of-a-google-wallet-pass.md