Google Wallet supports several pass types, and the Generic Pass is one of the most useful for membership cards. It is flexible enough for member IDs, club cards, library cards, insurance cards, reservation confirmations, and other credentials that do not fit neatly into a ticket or loyalty-card template.
For membership organisations, this matters because a membership card is often a custom credential: it may need a member ID, tier, expiry, QR code, chapter, status, and organisation-specific fields.
This guide explains how Google Wallet Generic Passes fit membership cards, what they can display, and when to use a managed platform instead of building directly on the Google Wallet API.
What is a Google Wallet Generic Pass?
A Google Wallet Generic Pass is a flexible pass type for use cases that do not have a more specific Wallet template. Google lists membership cards as one of the use cases for Generic Passes.
For a membership card, a Generic Pass can hold:
- Member name
- Member ID
- Membership tier
- Expiry date
- QR code or barcode
- Organisation branding
- Custom labels and values
- Links or additional details
The member saves the pass to Google Wallet and opens it when they need to prove membership. Staff scan the code to verify status, just as they would with an Apple Wallet pass.
Class vs object, in plain English
Google Wallet passes are built around two ideas: a class and an object.
The class is the template. It defines the shared structure for a group of passes: organisation name, general branding, layout, and pass type.
The object is the individual member's pass. It contains member-specific data: name, member ID, tier, expiry, QR code, and any custom fields.
For example:
- Class: "Memberlytic Gym Membership Card"
- Object: "Alex Tan, Member ID GYM-1042, Unlimited Plan, Expires 31 Dec 2026"
This split is useful because you design the pass structure once, then issue many individual objects.
Why Generic Pass works for membership cards
Membership cards vary more than gift cards or boarding passes. A gym card, golf club card, alumni card, and association card all need different fields.
Generic Pass gives enough structure without forcing the card into the wrong model.
Common membership fields include:
- Name
- Member ID
- Tier
- Expiry
- Status
- Branch
- Chapter
- Handicap
- Benefits
- QR code
- Support link
The key is to keep the pass face readable. Put high-frequency fields on the visible card and move secondary information to details or links.
QR codes and verification
Google Wallet passes can include a barcode or QR code. For membership verification, the code should usually identify the member record rather than store personal information directly.
The scan flow:
- Member opens the Google Wallet pass.
- Staff scan the QR code.
- The verification page checks the member record.
- Staff see active, expired, suspended, frozen, or unknown.
This makes the Google Wallet pass useful even after the visible fields become outdated. The scan should always be the source of truth.
For a full scan workflow, read QR code membership card verification.
Updating Google Wallet membership cards
Membership data changes. A good Google Wallet card setup should support updates after issue.
Fields that may need updates:
- Expiry date
- Tier
- Renewal status
- Points or visit count
- Branch access
- Benefits
- Member category
- Suspension or freeze status
If you build directly on the Google Wallet API, your system needs to update pass objects when member data changes. If you use a managed platform, the platform should handle the update flow for you.
Standalone cards can update from CSV re-import or API sync. Full membership management software can update the card when renewals, payments, or profile changes occur.
Google Wallet is not the whole rollout
Do not treat Google Wallet support as the only requirement. A serious membership card rollout also needs:
- Apple Wallet support
- A web fallback
- Member data import or sync
- Email or SMS delivery
- QR verification page
- Staff training
- Re-download process
- Renewal update process
Google Wallet is the Android wallet layer. It is not your full membership operations workflow.
For no-app rollout options, see digital membership cards without an app.
DIY Google Wallet vs managed platform
Building directly on Google Wallet is possible, but it is a software project.
You need:
- Google Wallet API issuer setup
- Pass class and object creation
- JWT or REST API implementation
- Branding and template setup
- Member data mapping
- Update handling
- Error handling
- Verification logic
- Apple Wallet support separately
For a developer team, that may be reasonable. For a membership manager, it is usually a distraction.
A managed card platform lets you focus on member data, card fields, and rollout. The infrastructure behind Google Wallet and Apple Wallet stays out of your team's daily work.
Design considerations for Google Wallet cards
Google Wallet passes have their own layout rules. Do not assume the exact Apple Wallet design will render identically on Android.
Check:
- Logo readability
- Field labels
- Long tier names
- QR code scan size
- Contrast
- Details page content
- How the pass looks on common Android screen sizes
Design for recognition and scanning, not decoration.
When Generic Pass is the right fit
Use Generic Pass for membership cards when:
- The card does not fit a standard ticket or offer model
- You need custom membership fields
- You need a QR code or barcode
- You need updates after issue
- You want the card in Google Wallet without a custom app
If your use case is more like a points programme, a loyalty pass model may also be relevant. But for member IDs, club cards, association cards, and access credentials, Generic Pass is often the natural fit.
Frequently Asked Questions
Can Google Wallet store membership cards?
Yes. Google Wallet supports passes suitable for membership-card use cases, including Generic Passes for custom credentials.
What is the difference between a pass class and pass object?
The class is the shared template. The object is an individual member's pass with that member's specific fields.
Can Google Wallet membership cards update after renewal?
Yes, if your issuing system updates the pass object when renewal data changes. A managed platform or API sync can handle this.
Do we still need Apple Wallet?
Yes. Google Wallet covers Android members. iPhone members need Apple Wallet. A complete rollout supports both.
Should we build directly on the Google Wallet API?
Only if you have the developer capacity to maintain pass issuance, updates, verification, and Apple Wallet support. Most clubs and associations should use a managed digital membership card platform.