Digital loyalty card design is different: the real job is deciding what the pass does in Apple Wallet or Google Wallet — how it updates in real time, what notifications it sends, which links or actions it exposes, and how easily it scans and works at checkout. If you manage a loyalty program, market it, or build it, that shift changes what good design means, because the card now has to connect customer experience, point-of-sale behavior, and backend systems in ways that affect engagement and revenue.
This guide looks at that shift from plastic cards to digital passes, including the difference between customer-created and official passes, the functional design choices that matter, recent platform changes, barcode formats, checkout UX, and a practical checklist for designing loyalty cards that work.
The card now sits in Apple Wallet or Google Wallet, so the card lives where customers already look and can access it at checkout without an app download or a long sign-up flow; they can add it in one tap. It updates. It can send a notification. It can carry a button. All of that changes the question.
Not what the card looks like. What it does, how fast it does it with three people waiting behind you, and what has to exist behind it before any of that works.
It has already started without you. Since iOS 27, a customer can digitize your plastic card themselves in about a minute, without asking anyone. The pass they end up with looks exactly like one you issued. It sits in the same stack, next to the same payment cards, which already feels natural for many iPhone users because they pay with Apple Pay, and Apple Pay accounts for 54% of in-store mobile wallet transactions in the U.S. And it earns you nothing.
The feature is called Create a Pass. Tap the plus button in Wallet, point the camera at a physical card, and Visual Intelligence reads the barcode and fills in whatever printed text it can manage. No developer account, no Pass Type ID, no certificate signing (Gadget Hacks, August 2026).
Good feature. Apple built it for customers, and for customers it is a straight win. The cost lands on whoever runs the program, which is why it is worth being precise about what this pass is not.
A pass the customer built is frozen at the moment they built it. Apple has confirmed the creation flow, the templates, the editable fields, and support for the new barcode formats. Apple has not said whether these passes sync across devices, appear on Apple Watch, surface through location relevance, or update at all after creation (Gadget Hacks, August 2026). One reason people do it anyway is simple access: a card on the phone is easier to find and harder to lose than a paper or plastic one. Contactless entry is settled, though. NFC requires a pass signed with an NFC entitlement, and this flow skips signing entirely, so optical scanning is all you get.
What the customer ends up holding is a barcode on a screen. No balance. No tier. No push channel. No location trigger. No analytics. No enrollment record you can act on.
So "plenty of our customers keep our card in their wallet" is now a number that has to be split in two. Cards you issued are a channel. Cards customers made are a photograph of your barcode with better cropping. In a Wallet stack they look identical. To you they are worth completely different amounts.
Google documents the same gap in plainer language. Passes customers add by hand are unlinked from their merchant accounts, and as a developer you cannot update them or engage anyone through them (Google Developers Blog). Google at least built an exit. Merchants who integrate Loyalty Program Enrollment can let customers upgrade a manually added pass into an API-linked one (Google Wallet release notes, April 2025). That upgrade path is the thing to go and build once you accept the split above.
And if your loyalty program has no official wallet pass, customers digitizing your card themselves is the clearest demand signal you will ever get. They have told you they want the card on their phone. They just built the version that cannot earn you anything. That lines up with the broader move to digital wallets, which are projected to reach 5.2 billion users by 2026. So the question has changed. It is no longer whether to put a card in Apple Wallet and Google Wallet. It is whether the card already sitting in your customers' wallets is yours.
Start at the moment a member pays. The card's job there is attachment: getting the transaction onto the right account, with simple mechanics so customers understand immediately how it works and what they get. Miss it and you haven't just failed to scan a barcode. You've created a purchase that earned nothing. The member notices. Not the first time. By the third time points don't show up, they have quietly decided the program is unreliable, and no offer wins that back. Everything else here assumes attachment happened.
Then there is the stretch between visits, which is most of a member's life in your program. The card is where your tier mechanic either exists or does not. A tier nobody sees between emails cannot motivate anyone, so a card showing only a barcode is a tiered program with the motivation taken out. Visible progress toward a benefit helps reward loyalty because people respond strongly to partially completed progress, which is why the Endowed Progress Effect pushes them to finish faster.
And redemption, which almost nobody designs for. Cards get built for earning, because earning happens at a counter with a scanner and somebody thought about it. Spending points gets left to the app, or to staff who have to be trained to explain it. That is backwards.
Earning is a habit. Redeeming is the moment a member decides the program was worth joining.
Artwork serves those three moments. It does not lead them. The best card design blends visual branding with clear motivational cues, not decoration alone. A card that looks excellent and scans badly under fluorescent light at a busy till has already failed the first one, in the most visible place your loyalty program has.
Try this with your next design. Hand it to someone who has never seen it, put three people in line behind them, and watch where the thumb goes.
Create a Pass was not the only thing that landed. Apple Wallet and Google Wallet both spent the year giving the card things to do. Until now it sat there and got scanned.
Apple moved first, at WWDC, with four changes that each buy you something different. Poster Generic is a pass style with room for real imagery. Four new barcode formats (EAN-13, Code 39, Codabar, and ITF) decide whether the scanners already on your counters can read the card at all. Featured Actions put a tappable link on the card itself. Pass Designer and Pass Builder take pass creation off your engineers (PassKit, June 2026; Apple Developer, WWDC26 session 209).
Featured Actions is the one that changes your job. The old pattern was fixed: open the pass, scan it, close Wallet. Anything useful lived on the back, where nobody looked. Now up to two tiles sit under the pass, in priority order, each linking out to a page you control, visible while the phone is already in the customer's hand, and wallet-based cards can be updated instantly after saving so those tiles and the card content can change without a reissue (Apple Developer).
The barcode change carries a trap. A pass using only one of the new formats shows no barcode at all on iOS 26 and earlier, so include a fallback (Gadget Hacks, August 2026).
Google's side is less even than the coverage suggests. Nearby Passes, which turns your store into a trigger for the card, has been live for all regular pass types since October 2025, capped at 10 merchant locations per class and per object (Google Wallet release notes, October 2025). In practice, a lock screen notification can act as a location-based reminder when someone is nearby, and businesses using digital loyalty programs report a 15–30% increase in customer visits. Google said at I/O 2026 that it would lift the cap by inferring locations from Maps (Android Authority, 2026), which is announced rather than shipped. Bounceback, which fixes enrollment by prompting customers to join after they tap to pay, is still a pilot you have to request (Google Wallet release notes, October 2025). Design for Nearby Passes. Treat Bounceback as a maybe.
So you have to decide what goes in those two slots on the front of your digital loyalty card. Two is enough to be useful and few enough that the choice costs you something, and ranking them is part of the choice. Most programs will spend both on "Open app" and "Contact us," which is the same as not choosing. The candidates worth arguing about are the things customers currently have to go and find: the reward they can already claim, the points to the next tier, the offer that expires Sunday. Use push notifications carefully, and let the lock screen carry the timely message when the pass is meant to pull someone back in.
Barcode or QR code is the baseline, and a qr code can also let customers join or add the card to their wallet quickly. It works with nearly any scanner and asks the customer for nothing but screen brightness and a steady hand. The catch is format. The one you pick has to match the scanners already sitting on your counters, which is why four extra formats in iOS 27 matters more than it sounds in a release note (Apple Developer, WWDC26 session 209).
NFC and Smart Tap is faster, and it is the route that unlocks the prompt to join your program after someone taps to pay. The hardware decides whether you can have it: a pass signed with the NFC entitlement, and a terminal that supports it. Many programs also use staff scan workflows to award stamps or validate rewards when a customer presents the card.
Phone number lookup asks nothing of the customer at all. No card to lose, no battery to run flat. It is also the slowest thing you can do at a till, and it is the usual fallback, which is a bad combination.
Most programs run two of these and design properly for neither.
Whatever you choose has to survive the queue. Staff are judged on how fast the line moves, not on sign-ups, so anything that slows them down gets dropped. Quietly, without a decision, without anyone telling you. A loyalty program that becomes a checkout bottleneck is never canceled. It just stops being offered, and the attach rate falls in a way that looks from head office like customers losing interest.
You get a handful of fields. Almost every program spends the best one on the points balance and calls the design finished.
It is the wrong number. "4,250 points" answers a question nobody asked. It doesn't say whether that is a lot, what it buys, or what to do next, so the member has to go and look all of it up. A points balance is a fact about your database. It is not a fact about the member's next visit.
Two things beat it. Distance to the next thing, as in "180 points to your next reward," is the same data with the arithmetic already done, and it hands the member a reason to act rather than a number to interpret, especially when that distance is shown with a clear progress indicator so the next step is obvious. The other is whatever they can use today: a reward already unlocked, an offer closing this week. That can be a digital stamp card that shows when customers receive a reward voucher in the app or by email, a punch card offer tied to a free coffee, or any similarly direct redemption prompt.
This is the tier progress argument in miniature. Current status is a label. The next threshold is a motivation. It applies harder on the card than in the app, because the card is the only part of the program most members see between purchases. The tier loyalty program page covers how the thresholds behave underneath.
One more, less glamorous. Keep the member identifier readable as text somewhere, not only inside the barcode. When a scan fails, that number is what gets the sale attached to the right account, and redemption-focused card design also makes reward use easier to track in analytics.
Every number on the card is a rendering of program state, and digital cards can also feed real-time insight into customer loyalty activity, customer behavior, and customer data. Design decides what to show. Something behind it has to keep that true.
That next-reward number only helps if it is true today, so updates have to push. A balance three days stale is worse than no balance, because now the member has a reason to distrust the card while standing at the counter.
Nearby Passes and the post-payment prompt carry the same dependency one level up: triggers need segmentation. A location notification sent to everyone who walks past is spam, and a spammy pass gets deleted. Deleting the pass removes the channel permanently, which makes one badly targeted notification among the more expensive mistakes available to you.
And those two Featured Actions slots have to resolve to something real. "View your rewards" that opens a generic rewards page is a broken promise with an extra tap in it.
This is the honest reason a card program is not a design project with a vendor attached. The card is the visible end of earning rules, tier state, reward availability, and segmentation. If those are slow or inconsistent, better artwork makes the problem more obvious, not less. The operational side should expose that in a clean dashboard so teams can track program performance without digging through raw systems.
For how that state gets exposed, see the loyalty program API.
Poster Generic gives brands more room for imagery while still carrying the pass information and the barcode (PassKit, June 2026). Genuinely useful. It will also be overspent, because every brand that has lived with a logo and one background color for a decade now has permission. Even if you start from a pre-designed template and can upload your logo, the layout still needs to stay uncluttered and easy to understand.
Remember where this surface gets used. One hand, phone held at an angle, counter, queue, variable lighting, and a person who wants to be finished. Under those conditions three things beat visual ambition: barcode contrast and quiet space that no background art interferes with, text that survives at arm's length rather than at design-review distance, and a card recognizable in a stack of a dozen others, which usually comes down to visual consistency through logo placement and brand colors rather than detail.
One habit worth adopting. Review the card at the size it appears in the Wallet stack, not the size it appears in Figma. Most of what gets added in the second round of design is invisible at that scale anyway, and a minimal aesthetic usually improves recognition and engagement at that size.
Four cases survive, and they are narrower than most brands want them to be, though in the few situations where plastic is justified, tangible, attractive designs can still motivate customers to keep and use it.
The sign-up moment in store, where something to hand over keeps the conversation going and the wallet pass becomes the follow-up rather than the ask; if you keep a physical version, it should still fit standard wallet dimensions for convenience.
Markets and segments where wallet adoption is genuinely low. Check that against your own data rather than assuming, because the gap closes faster than most roadmaps do, whether you run a coffee shop, beauty salons, car washes, or another repeat-visit service.
Gifting, which needs an object.
Status as a physical signal. Metal cards exist because being seen holding one is part of the reward, which is a real mechanic rather than vanity, and it only works at the top tier; when physical status is the point, high-quality materials can communicate value and prestige.
Everything else is inertia, and inertia bills you monthly: production, distribution, replacement, and a second identifier your systems have to reconcile with the digital one.
Before redesigning anything, get two numbers. How many of your transactions attach to a member at the till, split by method, and how often staff skip the loyalty step when the line is long. The first tells you whether the card is doing its job. The second tells you whether it will keep doing it on a Saturday.
If the attach rate is lower than you expect, the fix is rarely the artwork. It is the scanner, the fallback, or a program that costs the cashier eight seconds they don't have. Once the underlying logic is in place, the creative side is not the technical setup: a wallet-ready card can usually be designed and launched in about five minutes. Customers can typically add it to their wallet in about five minutes as well.
Then pick your two Featured Actions, because that one gets decided by default if nobody decides it on purpose. The tier loyalty program page covers how the thresholds behave underneath, and the loyalty program API covers what has to be exposed to keep a wallet pass current.
If you want to pressure-test your own program against any of this, book a demo and bring the attach rate with you. Businesses commonly report a 15–30% increase in customer visits after implementing loyalty programs, which helps turn one time buyers into regulars before you move to a paid plan.
API-first loyalty and gamification engine
Get a weekly dose of actionable tips on how to build and grow gamified successful loyalty programs!
