An app for membership cards is a wallet pass wearing a database.
"Membership card" means different things depending on who's asking: a gym wants someone scanned in at the door in under a second, a professional association wants proof that dues are current, a co-op just wants a member number a cashier can read at checkout. Whatever the org, an app for membership cards has the same real job underneath: hold a small set of facts about one person, an ID, a tier, a join or expiry date, and make them scannable somewhere a phone already lives.
That's mostly what Apple Wallet and Google Wallet already do, which is why so much of a membership cards app amounts to plugging into a wallet pass format instead of building a new app people have to install. It sits next to the wider category of community and organisation apps, since a membership list, a directory, and a chapter's private feed are usually pieces of the same build.
Compare Apple Wallet and Google WalletThe short version
A pass, plus a database.
Apple Wallet has a Store Card pass built for this. Google Wallet has a Generic Pass that lists membership cards by name. Both are one-tap-to-add and live on a phone people already carry, so the interesting part of a membership card app isn't the card at all, it's the backend behind it: who's current, who lapsed, and how an update reaches a card that was issued months ago. The rest of this page walks through both wallet formats, what issuing either one actually takes, and where a plain scanned barcode is genuinely enough.
The actual requirements
What a membership cards app actually needs to hold.
Strip away branding and the field list is short, and nearly identical across a gym, a union, an alumni group, and a members-only store:
- A member ID or number, unique per person
- A tier or status (active, lapsed, gold, alumni, and so on)
- A join date and, if it applies, an expiry or renewal date
- Something a door or counter can scan: a barcode, QR code, or NFC chip
- A name and, usually, a photo or logo for a quick human check
Who this is for
Who actually needs a membership cards app.
The format barely changes, a name, a tier, a scan point, but what "membership" means shifts a lot by organization.
Gyms & fitness studios
Fast door scans, and a status that flips between active and paused constantly.
Alumni & school networks
Decades of members, and a status that's more of a spectrum than a toggle.
Professional & trade associations
Proof of active dues, checked rarely but scrutinized closely.
Co-ops & buying clubs
A card scanned at checkout, right next to the register's own barcode reader.
Faith & community groups
Check-in at the door, often alongside a household or family record.
Clubs & hobbyist groups
A simple roster where the card mostly just proves you belong.
| Organization | Typical status model | Where it gets scanned | Wallet fit |
|---|---|---|---|
| Gym / fitness studio | Active, paused, cancelled | Front desk or turnstile, daily | Both wallets, needs live updates |
| Alumni network | Active, lifetime, lapsed | Rarely scanned, mostly directory access | Either wallet, low update frequency |
| Professional association | Active by dues year, lapsed | Rarely scanned, proof of status | Either wallet, annual updates |
| Co-op / buying club | Active shareholder | POS checkout, every visit | Both wallets, needs barcode compatibility |
| Faith / community group | Active, visitor | Check-in kiosk, weekly | Either wallet, simple is often enough |
Before the setup steps
Which wallet do you actually need?
Most organizations don't need to read both walkthroughs below in full. This narrows it down first.
Try it
What do your members actually carry?
Pick what your members show up with. Apple and Google Wallet credentials don't share anything, so this decides how much setup you actually need.
What you need to set up
Select one or both above to see what to set up.
Apple Wallet
How an Apple Wallet membership pass gets issued.
Apple's Wallet Passes framework has a dedicated Store Card style for membership, loyalty, and gift cards. Getting one onto a member's phone means five real steps, not just a design.
- 1
Register a Pass Type ID
In the Apple Developer portal's Certificates, Identifiers & Profiles section, create a reverse-DNS identifier for the group, something like com.yourclub.passes.membership. Every pass in that group shares this ID; a serial number on top of it identifies one specific member's card.
- 2
Generate a signing certificate
Signing a pass needs a certificate tied to that Pass Type ID. You start with a certificate signing request, upload it in the developer portal, and download the resulting certificate to whatever machine or server will do the signing.
- 3
Write the pass as a Store Card
Apple Wallet has a dedicated pass style for this, Pass.StoreCard, meant for membership, loyalty, and gift cards. A pass.json file sets the member's name, tier, barcode value, colors, and logo inside that Store Card structure.
- 4
Hash the files and sign the manifest
Every file in the pass, the JSON, the images, gets a SHA-1 hash, written into a manifest.json. That manifest is then signed with a PKCS #7 detached signature using the certificate's private key, and the signature is saved alongside it.
- 5
Zip it, rename it, hand it over
The signed folder gets zipped and the extension changed from .zip to .pkpass. From there, a link, an email attachment, or a QR code is enough: tapping it adds the card to Wallet in one step.
None of that covers updates. If a member's tier or expiry date changes after the pass is issued, keeping the card on their phone current means running a small web service that registers the device's push token, and pushes a re-signed pass when something changes. See Apple's Wallet Passes documentation.
$99/yr
Apple Developer Program
The account a Pass Type ID and its signing certificate live under.
SHA-1 + PKCS#7
Every .pkpass signature
The hash and signature format Apple requires over the pass manifest.
.pkpass
The file Wallet accepts
A signed zip archive, renamed from .zip once the manifest is signed.
Google Wallet
How a Google Wallet membership pass gets issued.
Google's Generic Pass type names membership cards directly as a supported use case, next to library cards and parking passes. The setup looks different from Apple's, but the shape is similar: a shared template, then one record per member.
- 1
Sign up for a Wallet API Issuer account
This happens in the Google Pay & Wallet console: sign in with the account that should hold the Admin role, give the issuer a public business name, and agree to the Wallet API terms. This account is what actually issues passes, separate from any single app.
- 2
Enable the Wallet API in Google Cloud
Non-Android integrations, a website, an email link, an SMS, need the Google Wallet API turned on inside a Google Cloud project. Android apps issuing passes natively can use the Wallet Android SDK instead.
- 3
Define a Class for the membership tier
A Class is the shared template: your organization's logo, colors, and the fields every member of that tier sees, gold member versus standard member, for instance. Google's Generic Pass type lists membership cards by name as a supported use.
- 4
Create an Object for each member
The Object is the actual card: one specific person's ID, status, and expiry date, linked to the Class that supplies the shared design. A REST call or a signed JWT creates it.
- 5
Hand the member a Save to Google Wallet link
That link (or the equivalent Android SDK button) is what a member taps to add the card. New issuer accounts start in demo mode, so until Google grants publishing access, only admin, developer, or added test accounts can actually save one.
Updating a Google Wallet pass is simpler than Apple's: a REST call that patches the Object propagates to the member's phone directly, no separate push-registration service required. See Google's issuer account setup.
Class + Object
Google's pass model
One shared Class per tier or branding, one Object per member.
Demo mode
Every new Issuer account
Passes reach only admin, developer, or test accounts until Google grants publishing access.
JWT or REST
Two ways to issue
Sign a JWT for a Save-to-Wallet link, or call the REST API directly.
Side by side
Apple Wallet vs. Google Wallet, requirement by requirement.
Neither set of credentials transfers to the other platform, so an organization issuing membership cards on both ends up maintaining two unrelated setups.
| Requirement | Apple Wallet | Google Wallet |
|---|---|---|
| Account needed | Apple Developer Program, $99/yr | Google Wallet API Issuer account |
| Extra platform account | None | Google Cloud project, Wallet API enabled |
| Shared template unit | Pass Type ID | Class |
| Per-member unit | Serial number in pass.json | Object |
| Signing mechanism | SHA-1 manifest + PKCS #7 signature | Signed JWT, or a direct REST call |
| What the member gets | A .pkpass file | A Save to Google Wallet link |
| Gate before it's public | None once the cert exists | Demo mode until publishing access is granted |
| Live updates | A web service tracking device push tokens | A REST call that updates the Object directly |
Check your setup
How close are you to issuing a pass?
Most of what stands between an idea and a real membership card is a handful of accounts and one small database.
Try it
What do you already have?
Check off what your organization already has in place. This isn't scored, it's a way to see what's actually left before either wallet can issue a pass.
Where you stand
Check a few boxes above to see what's actually left.
Before you build anything
Is a QR code enough for a membership card?
For a lot of small organizations, genuinely yes. A QR code tied to a lookup in your own database, checked at the door against a spreadsheet or a simple app, covers the core job: prove this person is a current member. What it doesn't give you is a live card in Wallet, a screenshot can be shared with someone who isn't a member, there's no push notification when dues lapse, and nothing updates itself when a tier changes; you're re-issuing the code by hand.
If the plan is tap-to-enter at a turnstile or a locked door instead of a code someone reads, that's a different piece of engineering entirely, reading a chip rather than a screen. This page is about the card itself, not how a phone talks to a reader; for that half of the problem, see NFC in mobile apps.
Not quite the same card
Membership cards vs. loyalty cards.
Both live in the same Wallet formats, an Apple Store Card or a Google pass doesn't care which one you're building, but the data they hold answers different questions. A loyalty card tracks points, stamps, or a balance that moves with nearly every visit; a membership card tracks status, active or lapsed, a tier, a renewal date, and mostly gets scanned to prove that status rather than to add to it. If points and redemption are actually the problem you're solving, see loyalty card apps for how that side works.
After the card is issued
A membership management app is the part that lasts.
The pass itself is a one-time build. What keeps running for years is the membership management app behind it: who joined when, whose dues are due, who gets bumped to a new tier, and who needs a reminder before their card quietly stops scanning as valid. An alumni group is a clean example of how long that tail gets, decades of members, addresses and emails that change, and a status that's really a spectrum, active, lapsed, lifetime, rather than a single yes or no; see alumni app for how that plays out end to end.
Picking an approach
What actually gets you a working card.
None of the common options are wrong exactly, they just fail at different points as an organization grows past a spreadsheet.
| Approach | Live updates | Both wallets | Scannable at the door | Who maintains it |
|---|---|---|---|---|
| Printed or plastic card | No | n/a | No | reissue by hand |
| Shared PDF or QR screenshot | No | n/a | Yes | whoever emails it |
| Generic loyalty-app template | depends | No | Yes | the vendor |
| Dedicated membership software | Yes | Yes | Yes | the vendor |
| Custom-built membership card app | Yes | Yes | Yes | you |
When to build your own
Building an app for membership around your own rules.
Generic membership software is built around somebody else's tier structure and somebody else's renewal flow. If yours doesn't match, a family plan that shares one card, a tier that expires on a fiscal year instead of an anniversary, a status that depends on volunteer hours, you end up bending the organization to fit the tool. That gap is what Newly is for: describe how membership actually works for your organization, and it builds a real native app around your rules, with the wallet passes and the database behind them wired together instead of bolted on.
Get the tiers, the renewal rule, and who's allowed to scan a card right on paper first, that's the cheap part to change. Wiring up two separate wallet integrations and a database that survives years of renewals is the harder half, and worth scoping before you start.
Sources
Where the specifics came from.
Four things on this page come from Apple's and Google's own documentation rather than general consensus:
FAQ
An app for membership cards, answered.
There isn't one universal best app, because “membership card” covers different jobs: a gym checking someone in at the door needs fast scanning, a professional association needs to prove active-dues status, and a co-op just needs a member number a cashier can read. The fields that matter across almost all of them are a member ID, a tier or status, a join or expiry date, and something scannable at a counter or door. Apple Wallet and Google Wallet both support membership-style passes natively, so for many organizations the best membership card app is really the pass format plus a backend that keeps it updated, not a separate app someone has to download.
Know your tiers? Build the card around them.
Get the membership rules right on paper, then describe them to Newly and build an app for membership cards that actually matches how your organization runs.