Loyalty Card Templates: Format, Fields & a Worked Example

By the Kemicard team·4 August 2026·4 min read

A loyalty program lives or dies by its card. This guide covers loyalty card template design: which wallet format to use, what earns a place on the front, which fields every card needs, and a worked loyalty card example from data to wallet.

Choosing the loyalty card format

Both wallets give a loyalty card the same basic structure: a logo, a strip or hero image, a few fields on the front, a barcode, and space on the back. The formats differ underneath.

• Apple Wallet: loyalty uses the store card style.
• Google Wallet: uses a loyalty card made of a class (the design every member shares) and an object (one member's card). See how classes and objects work.

A template that renders both from the same data spares you designing twice.

Front versus back: the decision that matters most

Apple arranges a pass in fixed areas: header, primary, secondary and auxiliary fields on the front, and back fields behind (see the Pass reference). Google's layout is similar in spirit.

The rule is the same in both: the front carries what someone checks in two seconds. For a loyalty card that is the points balance, the tier and who the card belongs to. Everything else goes on the back.

The fields that matter

• Points balance. The number members actually look at, so keep it primary and keep it live. Read it from the record that holds the balance: a points field on the member, or Loyalty Management's balance if you run it (how that works).
• Tier. Status is the emotional hook. Give each tier its own colours or card art, so an upgrade is visible the moment it happens.
• Member name and ID. The name reassures the holder, and the ID is what staff key in when a barcode won't scan.
• Barcode. QR scans most reliably across both wallets, and PDF417 is there if your existing scanners expect it. Encode a member ID, never personal details. The scanner looks the rest up from the record.
• Expiry. Only if membership lapses. A card that never expires shouldn't show a date.
• Back of the card. Current rewards, progress to the next tier, terms, a link to the member portal, and how to get help. Apple supports tappable links in back fields.

Design rules both wallets reward

• Short labels. Fields truncate on small screens, and Google's list view shows even less. "Points", not "Your current points balance".
• Contrast first. Text on the strip and background has to stay legible in sunlight. The WCAG contrast guidance is a sensible floor.
• Logos supplied large. Google's brand guidelines set minimum image sizes, so export above display size and let the wallet scale down.
• A barcode quiet zone. Leave clear space around the code. Crowding it is the commonest reason a card fails at the till.

Apple's Wallet design guidelines cover the rest. Our Google Wallet pass design guide goes deeper on Android.

A worked loyalty card example

Take a grocery loyalty card for a fictional store, Lakeside Market. It's the demo card shown on our analytics page.

When the till writes a purchase to Salesforce and the points field changes, the card on the phone updates. A customer engagement notification can say what happened, for example "You earned 40 points on today's visit". When the member crosses into Platinum, the tier field changes and so does the card's design.

Building it in Kemicard Studio

Our loyalty template walkthrough builds this screen by screen. It runs in four parts:

1. Name the template and point it at your data. Choose the object it reads from, such as Contact, and the welcome email it sends.
2. Brand the card. Set the primary colour as a hex value, upload the logo and strip images, and turn on the back side. The preview renders live.
3. Add the barcode. Choose the format and the field it encodes.
4. Map the fields. Bind each front and back field to static text or a Salesforce field, then preview on both wallets before you issue.

Mistakes to avoid

• Too many fields on the front. Three is plenty, and every extra one shrinks the others.
• A barcode that encodes an email address or a name, which then appears in every scan log.
• One design for every tier, which wastes the card's best motivator.
• Terms and support details left off the back, so members email you instead.

For the strategy side, see digital loyalty cards and tiered loyalty programs.

Sources: Apple's Creating a Store Card Pass, Pass reference and Wallet design guidelines; Google's Loyalty cards documentation and brand guidelines; W3C's Understanding Contrast (Minimum).