A class ID identifies a Google Wallet class: the shared template that defines a program's passes on the Google side. The class carries what every member's pass has in common, layout, branding, program name, the program-level configuration, and each individual pass is an object that references the class and adds the member's own data on top.
The ID itself is two parts joined by a dot: the issuer ID of the account that owns the class, then a suffix the issuer chooses. That prefix is not cosmetic; it is what roots the class in an account and makes ownership of a program's Google Wallet presence concrete and checkable.
The split between class and object is where the model earns its keep. Fix a logo or reword a program detail on the class, and every pass built on it updates, no per-member writes required. Change a member's balance, and only their object is touched. It is the same division of labor as a template and its passes elsewhere, made explicit in the API. One caveat worth knowing: a class edit updates existing passes, but what a member sees can lag until their wallet refreshes.
Functionally, the class sits where Apple's pass type identifier plus the pass template sit on the other platform, one more place where the two wallets do the same job with different vocabulary. A member never sees a class ID; they meet the class only as the pass a save link puts in their wallet.