Digital Membership Cards for Salesforce: The Complete 2026 Guide

By the Kemicard team·4 August 2026·Updated 10 September 2026·15 min read

Salesforce is a unified CRM that holds all customer information in one place. What if you could issue digital membership cards from the same Salesforce record into Apple Wallet and Google Wallet?

The card carries the fields from Salesforce records — name, member ID, tier, renewal date. That is the short explanation of what a digital membership card for Salesforce means. This guide covers how it works in Salesforce and how to build the first card.

What do digital membership cards for Salesforce mean?

A digital membership card is a wallet pass that a member keeps on their phone, held in the Apple Wallet or Google Wallet app. Adding for Salesforce narrows it further. The card is built from a Salesforce record, and the fields printed on a plastic card become fields read from that record.

The membership number on the card is the membership number in the org. The expiry date on the card is the date in the record.

Which Salesforce records hold the data a card needs

Member data is already spread across a few standard objects, plus whatever the org has built for itself.

• Contact. The person — name, email, phone, and the date they joined.
• Custom objects, for example Membership__c. Tier, status, renewal date, and membership number. Orgs that run membership seriously usually have an object for it.
• Campaign and Campaign Member. Where membership drives, cohorts, or event-linked programs are tracked.
• Opportunity. Where the joining payment or the renewal is recorded, which gives a paid-through date.
• Lead. Prospective members, for organizations that issue a trial card before conversion.

A card can read from one of these or several. The mapping between a Salesforce field and a field on the card is what makes it a Salesforce card rather than a card that happens to hold the same information.

The front of the card carries the member name, the membership number, the tier, and the expiry date. A QR code or barcode carries the value that gets scanned at the door. The back holds benefits text, contact details, and links.

Both wallets have their own format. Apple Wallet uses the .pkpass file, signed with a certificate issued by Apple. Google Wallet uses a signed JWT payload, a data format Google checks to confirm the pass came from the organization named on it. Any tool that issues cards from Salesforce produces both.

Two ways organizations set this up

Cards can be issued by an application installed inside the Salesforce org, or by an outside platform that connects to Salesforce through an API and keeps its own copy of the member data. Both produce a card. They differ in where the data goes and in who maintains the connection. That difference is covered further down.

How do digital membership cards work in Salesforce?

The mechanics do not change by industry. A record exists in Salesforce. A card is generated from that record, delivered to the member, then checked when the member arrives.

From member record to issued card

Setup happens once, then the same path runs for every member after that.

• Build the template. Each field on the card is mapped to a Salesforce field — member name to the Contact name, tier to the tier field on the membership object, expiry date to the renewal date. Cards built from Salesforce records work off that mapping for their whole life. See the template builder guide.
• Set the issue rule. Most orgs handle this with a record-triggered Flow, the Salesforce automation that runs when a record is created or updated. Issuing from a record change means a status moving to Active can generate the card without anyone opening the record.
• Generate the card. The pass is produced for that one member, carrying their values and a unique serial number that belongs to that pass alone.
• Send the enrollment link. The link goes out by email or SMS. The member taps it once, and the pass saves into Apple Wallet or Google Wallet.

How a card updates after someone already has it

Field mapping keeps working after the card reaches the phone. When a mapped field changes on the Salesforce record, the issuing system sends a new version of the pass to Apple or Google, and the phone picks it up in the background. A card that behaves this way is a live pass rather than a printed one.

Renewal dates, membership tiers, status, and benefits text all update on that path. There is no second link, and the member reinstalls nothing. Push notifications run on the same trigger, putting a short message on the lock screen when a value changes. Revocation runs the same path in reverse, where a lapsed record pulls the pass out of the wallet.

What happens at the scan

The barcode or QR code on the card carries a value that identifies the pass, normally the serial number or the membership number. It does not carry the member's status. That comes from the lookup.

Staff scan the code with a handheld reader or a phone. Scan-based check-in validates the value against the Salesforce record behind it, so the answer comes from the current record. A membership that expired last week fails the check, even though the card still displays on the phone.

The scan is then logged back as an activity on the record. Visit counts, event attendance, and last-seen dates become reporting data inside Salesforce, in the same org as the rest of the member history.

How to add digital membership cards to Apple Wallet and Google Wallet

The add-to-wallet link is generated against the member record and sent from Salesforce, so no separate mailing tool holds the member list.

Four delivery routes cover most programs.

• Salesforce email template. The link is merged into the welcome or renewal email, sent by a Flow when the membership record becomes Active.
• SMS. The same link goes out through whichever SMS integration the org already runs on.
• Experience Cloud. Members who log in to a portal see the card on their account page and add it there.
• QR code. A code printed on a renewal letter or shown at a desk opens the same add flow when scanned.

Bulk sends work off a Campaign or a list view, which is how an org moves an existing member base onto cards in one operation rather than record by record — see Campaign Manager.

On the member's phone, the step is one tap. iPhone opens the preview in Apple Wallet with an Add button, since passes in Apple Wallet are handled by iOS itself. Android opens Google Wallet with a Save button, documented by Google under saving passes to Google Wallet.

What comes back matters as much as what goes out. The install is recorded against the Contact, so a report can list members who received a link but have no card yet. That list is the follow-up campaign. Distribution and delivery options are configured once in the org and reused for every send after that.

Native app or connected platform — which one fits?

Native apps and connected platforms both issue a working card. The difference is where the member data is stored, and who is responsible for the integration between the card and the Salesforce record.

A native app is installed in the Salesforce org from AppExchange. It runs as a managed package, an application that works inside Salesforce instead of on a separate website with its own login. Pass templates, field mappings, and issue rules are stored as Salesforce records. Kemicard is used this way — the pass is generated from the member record, and the member list is not copied out of the org.

An integrated platform runs outside Salesforce and keeps its own member database. An API integration handles the data transfer between the two systems. Member details are pushed out to the platform, and scan results are sent back into Salesforce. The card is built from the platform's copy of the data.

An integrated platform is helpful for some organizations. Membership data that lives outside Salesforce is one case. Running more than one CRM is another. Venues that buy wallet passes together with point-of-sale hardware from a single supplier usually take the integrated route as well.

More on the in-org approach on how Kemicard works and what it connects to.

How safe is member data on cards issued from Salesforce?

Member data is held in more than one place once a card is issued. The record stays in Salesforce. The pass is on the phone. Apple and Google each handle part of the delivery, and they do it differently.

Security the card inherits from the Salesforce org

An application installed in the org runs on the controls the org already has.

• Field-level security decides which fields can be mapped onto a card at all.
• Permission sets decide who can issue a card, and who can revoke one.
• IP restrictions and session policies apply the same way they apply to any other work in the org.
• Audit data is written back to the record. Issue, update, scan, and revocation are all reportable with standard Salesforce reports.

Salesforce operates a SOC 2 Type II environment, and an in-org application works inside it. Security and compliance for wallet passes is handled at the org level instead of by a second system with its own login and its own controls.

What member data actually goes on the card

A pass carries the fields mapped into the template. Member name, membership number, tier, and expiry date are the usual set. A home address, a giving history, or a date of birth is not needed on a card. Field mapping is the control that keeps that data off the phone. Pass payloads are encrypted during generation, in transit to the device, and at rest.

Protection the card gets from Apple Wallet

Apple's update model keeps pass content with the issuer. The pass file is signed with a certificate, and it carries a web service URL plus an authentication token. The device registers with that web service and supplies a device identifier and a push token. When a value changes, the issuing server sends a push notification with an empty payload, then the device requests the updated pass over HTTPS. Apple sets this out in adding a web service to update passes.

Security the card relies on inside Google Wallet

Google works on a different model. The pass class and object are created through the Google Wallet API and held on Google's side, and the request is signed with the issuer's service account key. Google documents this in its guide to signed JWTs. Because the object is stored by Google, the field list mapped into it is worth reviewing before a program goes live.

Signing certificates the card depends on

Both wallets require signing material. Apple issues a certificate that expires on a yearly cycle. Google uses a service account key that gets rotated. Kemicard manages and rotates both, so no admin holds a private key, and no card stops updating because a certificate lapsed on someone's calendar. Certificate expiry is a common failure point for teams that build pass infrastructure themselves.

Copy and share protection on the card

A static QR code is an image. It can be screenshotted and forwarded, and no wallet prevents that. Validation is the control. The scan checks the live Salesforce record, so a lapsed membership fails even when the picture on the screen looks correct. Each pass also carries a unique serial number, which is what the check runs against. Wallet pass security covers the same ground for tickets and other pass types.

Two further controls sit above that, and they differ by wallet.

• Sharing controls. Apple supports turning the share button off on a pass. Google offers four levels, from fully shareable down to sharing prohibited, and the level locks once the member saves the pass.
• Rotating barcode. The barcode value refreshes at an interval, with the refresh time and the code length both configurable, so a screenshot taken earlier no longer scans. Rotating Barcode is a Google Wallet feature; Apple keeps a standard barcode, so Apple programs rely on validation rather than rotation.

Both controls arrived in Kemicard release 2.29.

Revocation closes the loop. One action on the record pulls the pass from the wallet, and the revocation is logged with a timestamp on the source record. An auditor asking who ended a membership, and when, gets the answer from a Salesforce report.

Final take

Digital membership cards for Salesforce run on data the org already keeps. The member record holds the details — name, membership number, tier, renewal date — and the card shows whatever is mapped from that record. Changes are made on the record, so nothing gets reprinted or mailed again.

The build itself stays small. A template and an issue rule cover most of it. Delivery uses the email or SMS route the org already has in place.

The longer decision is about storage. An app installed in the org reads the member record. An outside platform keeps its own copy, with an integration between the two.

Kemicard is used for the first approach. Passes are issued from Salesforce records, and pass activity like installs and scans is reported with standard Salesforce reports. See membership cards for the use case, the feature set, and pricing.

Frequently asked questions

Is there an app for storing membership cards?

Apple Wallet and Google Wallet are the apps. Both come with the phone, so a member taps the link and the card is stored without any download. The card appears alongside boarding passes, event tickets, and payment cards already saved there.

What is the best app for membership cards?

For the member, the answer is whichever wallet their phone runs. For the organization, the choice is the issuing application, and the questions worth asking are where the member data is stored, which system the issue rules live in, and whether the reporting lands in the CRM. Issuing from Salesforce records is one route. An outside platform with its own database is the other.

How do Apple Wallet membership cards differ from Google Wallet ones?

The card looks similar in both. The handling behind it is not the same. Apple keeps pass content with the issuer and fetches updates from an issuer web service, while Google creates and holds the pass object on its side. Google also supports rotating barcodes and four sharing levels, where Apple offers a standard barcode with a share button that can be switched off. The comparison of Apple Wallet and Google Wallet passes goes through the rest.

Are digital membership cards better than plastic ones?

They do things plastic cannot. A tier change or a renewal date updates on the card already in the member's pocket, and a lapsed membership can be revoked the same day. Plastic still has a place where members ask for a keepsake card, and some organizations issue both — the physical versus digital comparison weighs it up.

What are some examples of digital membership cards in use?

Common ones are museum member cards used at admissions, library cards used at the circulation desk, gym passes scanned at entry, and association or alumni cards that carry a tier. Donor recognition cards and student IDs run on the same setup. Sector examples like museum membership programs show the same fields doing different work.

Do digital membership cards work for nonprofits on Nonprofit Cloud?

Yes. Nonprofit Cloud records feed a card the same way Sales Cloud records do, so donor cards, volunteer IDs, and member passes are all built from existing records. Nonprofit organizations also receive 10 percent off every Kemicard plan.

How long does it take to create a digital membership card in Salesforce?

Three pieces decide the time: the template and its field mapping, the issue rule, and the email or SMS that carries the link. None of it needs code, and the template builder is where most of the work happens.

Can a member add the same card to more than one device?

That depends on the wallet and the setting chosen. Google offers sharing levels that run from fully shareable down to sharing prohibited, and the level locks once the member saves the pass. Apple passes can be shared unless the share button is turned off on the pass.