How to Design a Wallet Pass That Gets Noticed on the Lock Screen

A wallet pass competes for attention on the most contested real estate in digital — the mobile lock screen. A well-designed pass earns a permanent spot in the customer's wallet and surfaces at exactly the right moment. A poorly designed one gets removed within a week. The rules that determine which outcome you get are specific and learnable. This guide covers them in order of impact.

The strip image: your highest-impact design decision

The strip image is the dominant visual element of an Apple Wallet pass. It occupies the full width of the card, sits behind the primary fields and is the first thing a customer sees when they open their wallet. Getting this right matters more than any other design choice.

Apple's specification for the strip image is 1125×432px (375×144pt at 3× resolution for the @3x asset). Use your primary brand colour as the background. Place your logo clearly — centred or left-aligned — and keep additional text to an absolute minimum. The field labels below the strip carry the information; the strip carries the brand.

Google Wallet uses a hero image at 1032×336px. The same principles apply. A clean, colour-blocked strip with a crisp logo outperforms a complex illustration or a photograph with text overlaid on it. Passes are small — detailed imagery loses its meaning at this scale.

Avoid placing text on the strip that duplicates what appears in the field labels below it. Doubling up on “Gold Member” in the strip image and in the primary field is wasted space. Use the strip purely for brand recognition.

Logo: small, clean, recognisable

Apple Wallet places a logo in the top-left of the pass card. The logo slot is 160×50pt. At this size, complexity is the enemy of recognition. A wordmark or a simple icon works; a detailed multi-colour badge does not.

Use a white or transparent background for the logo asset. Apple renders it against the pass background colour, and a logo with a white box behind it looks out of place on a coloured card. Export the logo as a PNG with a transparent background and supply all three resolutions: @1x (160×50px), @2x (320×100px) and @3x (480×150px).

Do not include a tagline in the logo. Taglines are not legible at 50pt height and they make the logo area feel cluttered. Save the tagline for the back of the pass if it matters for your brand context.

Colour: brand identity plus accessibility

Apple Wallet lets you set three colour values in pass.json: backgroundColor(the card background), foregroundColor (the field value text) andlabelColor (the field label text above the values). These three colours work together to create the overall visual impression of the pass.

The most reliable approach is: brand colour for backgroundColor, white or near-white for foregroundColor and a slightly transparent white (or a lighter tint of the brand colour) for labelColor. This gives the field values maximum legibility against the brand background while the labels feel subordinate without disappearing.

Check colour contrast before publishing. The WCAG AA standard requires a contrast ratio of at least 4.5:1 for normal text. A pass that looks fine on your design tool preview may fail in a bright outdoor environment where the screen brightness is reduced. Use a contrast checker on your foreground/background combination.

Google Wallet does not use the same three-field colour model. Instead, it derives the card colour scheme from the hero image using a dominant colour extraction algorithm. To control the look precisely on Google Wallet, ensure your hero image has a strong, consistent dominant colour.

Field layout: what the customer needs at a glance

Apple Wallet's Store Card pass type (the most common type for loyalty cards and membership cards) supports four field regions on the front:

• primaryFields — one large field, displayed prominently below the strip. Use this for the most important single value: points balance, tier name or member ID.
• secondaryFields — up to two medium fields displayed side by side below the primary field. Good for expiry date and membership tier together.
• auxiliaryFields — up to four smaller fields in a row. Use for supplementary information the customer occasionally needs but does not need to read every time.
• headerFields — a small field in the top-right corner of the card, next to the logo. Typically used for a points balance or member number where brevity matters.

The discipline here is restraint. A pass is not a profile page or an account summary. It is a credential the customer shows to staff or scans at a terminal. Fill it only with what is needed for that transaction. If you cannot articulate why a field needs to be on the front of the pass, it belongs on the back.

Keep field labels short — two to three words maximum. “Points Balance” not “Your Current Points Balance as of Today.” The label text is small; long labels either truncate or push values out of position.

Typography: you do not control the font

Apple Wallet uses San Francisco — Apple's system font — for all field text. You cannot specify a custom typeface. This is actually a feature, not a limitation: San Francisco is designed for legibility at small sizes and renders consistently across all devices and brightness levels.

What you do control is the content of the fields. Use sentence case for field values where you have a choice — “Gold member” reads more naturally than “GOLD MEMBER” in a digital context, even though physical cards often use uppercase. Write numbers clearly: “1,240 pts” rather than “1240”.

Barcode placement and format

Apple Wallet places the barcode at the bottom of the pass, below all the field regions. You choose the barcode format in pass.json. The options are QR code, PDF417, Aztec and Code 128.

QR code is the right choice for most use cases. It scans reliably at a greater distance than PDF417, works in low light and copes better with screen glare. Scanners that support QR codes are standard in retail and hospitality environments.

PDF417 has legacy support in some airline and transport systems but should be avoided for new implementations unless your scanner infrastructure specifically requires it.

Do not make the barcode value a human-readable string that a staff member could simply read and type in to bypass scanning. Use an opaque identifier — a UUID or a hashed member ID — that only your system can interpret.

Common design mistakes

Too much text on the front. Every additional field makes the pass harder to scan at a glance. Resist the urge to surface every piece of member information. The back of the pass is designed for reference information.

Low contrast text on a colourful background. A gold field value on a yellow background looks attractive in a mockup and is illegible in sunlight. Prioritise readability over aesthetic matching.

A thumbnail image that is too detailed. Apple uses the logo image as a thumbnail in the pass list view. It renders at approximately 29×29pt. A complex coat of arms or detailed illustration becomes a muddy square at this size. The logo should work at 29px — if it does not, simplify it.

Inconsistency between Apple and Google Wallet versions. When you set the same strip image dimensions for both platforms, the cropping differs. Test your design on both platforms before publishing. The 1032×336 Google Wallet hero is proportionally wider than the Apple strip; a design that looks balanced on one may feel top-heavy on the other.

Quick design checklist

1. Strip image: 1125×432px (Apple), 1032×336px (Google) — brand colour, clean logo, no unnecessary text.
2. Logo: transparent background, all three resolutions supplied, no tagline.
3. Colour contrast: foreground text passes WCAG AA (4.5:1 minimum).
4. Primary field: one value, the most important one the customer needs at the venue.
5. Field labels: two to three words maximum.
6. Barcode format: QR code unless your scanner requires otherwise.
7. Back fields: website, support contact, terms link.
8. Test on a real device before publishing — not just a design tool preview.

Start free and design your first wallet pass with our live preview builder.