Guide

Apple Wallet and Google Wallet pass best practices

A pass is looked at for a few seconds, usually at a counter or a door, on a phone held at arm’s length. This guide covers how to make one that reads at a glance, scans first time and stays useful after it’s saved, on both Apple Wallet and Google Wallet.

Sizes and limits below were checked against Apple’s and Google’s official documentation on September 29, 2026. Both platforms change their guidance from time to time, so the sources are linked at the end. Where a number is our own rule of thumb rather than a platform rule, we say so.

Design for a glance

Apple describes the model plainly: a pass contains text, images and a barcode. You choose the pass style, supply the images and set colors and text formatting, and the wallet lays out and presents the pass for you. Google’s pass templates work the same way. You don’t get to arrange the pass freely, which is what keeps every pass readable, and it means the craft is in what you put in each slot.

Three rules cover most of the good decisions:

1. One job per pass. A loyalty card shows progress and a code. A ticket shows the event, the time and a code. If you find yourself adding a fifth field, the pass is doing too much.
2. The most important thing is the most visible thing. On Apple, the primary field is prominent, secondary fields are less so, and auxiliary fields less again. Put the value the person needs at the door in the prominent position.
3. Don’t rely on the pass being current. Updates can be delayed, and the person may have turned them off. The pass is a convenient way to look up a record on your side, not the record itself.

Apple and Google at a glance

The two wallets ask for different things. Keeping this table in mind saves the most common rework: an image sized for one wallet and rejected or cropped badly on the other.

Color and contrast

Both wallets let you set the pass’s background color. Apple also lets you set the text and label colors. The single most common design failure is text that is hard to read against the chosen background, especially under a phone screen at reduced brightness or in sunlight.

• Pick a background first, then a text color with strong contrast against it. As a rule of thumb (ours, not a platform rule), aim for at least the 4.5:1 contrast ratio used in accessibility guidance for body text.
• Avoid very saturated backgrounds. Google’s guidance says to avoid its highly saturated “vibrant” zones, and it publishes a set of recommended background colors, from grays and off-whites to mid-tone reds, greens, blues and purples.
• Check both light and dark logos on your background. A logo that works on white may disappear on a dark card. For its wide logo, Google recommends a very light color on dark backgrounds and a very dark color on light ones.
• Use one flat brand color. The layouts take a single background color, so pick the one that carries your brand.

Logos and icons

Apple Wallet

Apple’s logo image is rectangular and sits in the top left corner of the pass. It can be up to 160 × 50 points, and in practice it is usually narrower than that. Apple also asks for a separate square icon of 29 × 29 points, shown when the pass appears on the lock screen and in apps such as Mail when a pass is attached to an email. Provide the artwork at the original, @2x and @3x sizes so it stays sharp on every screen.

Google Wallet

Google shows a circular logo, masked from a square image. Use a PNG at least 660 × 660 pixels, keep a 15% margin around the artwork so the mask doesn’t cut it off, and don’t mask the image yourself.

Google also supports a wide logo: a transparent PNG, recommended at 1280 × 400 pixels (16:5), with a minimum height of 400 pixels. When set, it appears top left in place of the round logo and logo text.

Rectangle or circle?

Choose by the shape of your mark, not by the wallet. A wordmark such as “Rowan Coffee” in a wide lockup belongs in a rectangular logo, and a badge, monogram or icon belongs in a circle. Apple’s logo is rectangular either way, so a wide logo works there without change. On Google, supply the wide logo so it shows as designed, rather than squeezing a wordmark into a circle where it becomes unreadable.

Hero and strip images

The big image across the front of a pass has different names and different shapes on each wallet. This is where most passes look cropped or blurry.

Apple Wallet: strip, background and thumbnail

Which images Apple shows depends on the pass style. In Apple’s documentation:

• Coupons and store cards support a logo, icon and strip.
• Event tickets support a strip, or a background and thumbnail, but not both.
• Generic passes support a logo, icon and thumbnail, but no strip.

The strip is sized in points, and the size depends on the style:

As with the logo, provide each at original, @2x and @3x. A strip is a wide, short banner, so put the subject in the middle and keep text out of the image: the wallet already overlays fields on top of it.

Google Wallet: the hero image

Google’s current guidance recommends a hero image of 1032 × 812 pixels, an aspect ratio of about 5:4, saved as a PNG. Use a transparent PNG if you want the pass’s background color to show through. The do’s and don’ts are worth following closely:

• Use high-resolution photography or illustration.
• Use an image that is square or almost square.
• Leave about 20 dp of padding at the top and bottom, and don’t let the main content touch them.
• Don’t embed text in the image. Google notes it won’t be localized.
• Don’t use thin, wide rectangular images.

One image for both wallets?

Rarely. Apple’s strip is a wide, short banner and Google’s hero is close to square, so a single crop will be wrong for one of them. Design a wide version for Apple and a squarer version for Google from the same source photo.

Text and fields

Apple Wallet

Apple limits how many fields fit on the front of a pass: up to three header fields, a single primary field, up to four secondary fields and up to four auxiliary fields. Boarding passes allow two primary fields and up to five auxiliary fields. On coupons, store cards and generic passes with a square barcode, the secondary and auxiliary fields share a combined total of four.

Apple gives one instruction worth repeating: don’t include more fields than are displayed on the front. Fields that are hidden today can become visible if layouts change, and you don’t want a previously hidden field to suddenly show up. Long content belongs on the back, which has no limit on the number of fields.

The pass’s description is read out for accessibility. Apple suggests starting with a high-level term such as “Membership card” or “Weekly coupon”, followed by one or two small pieces of information.

Google Wallet

Google’s brand guidelines set these content limits:

For the back of the pass, Google’s guidelines ask you to use up to two text modules, up to four link URIs in total, and up to two info modules. Link prefixes matter: use http: for a website, tel: for a phone number and mailto: for an email address, so each one is tappable.

Writing for both

• Write to Google’s shorter limits. If a field value fits in about 15 characters, it fits everywhere.
• Put labels in plain words. “Points”, “Valid till”, “Member ID”. Avoid abbreviations your customers wouldn’t use.
• Put terms and long notes on the back, not the front. The back is for terms, opening hours, a phone number and a website.
• Include contact details. A phone number or website on the back is what people reach for when something goes wrong.

QR codes and barcodes

The code is the part of the pass that has to work every time, so it deserves the most care.

Which format

Apple Wallet supports four formats: QR, PDF417, Aztec and Code 128. Apple Watch doesn’t support Code 128; if a pass includes one, the watch falls back to another barcode on the pass. Google supports QR and Code 128, among others.

• QR code if people scan with a phone or tablet camera, which is the case for most small businesses. It holds more data, tolerates poor lighting and is read quickly.
• Code 128 if you use a handheld laser or linear-barcode scanner that can’t read QR. It is a one-line barcode and holds a short value.

The value in the code

• Make it unique per pass. If every pass carries the same value, you can’t tell one customer from another or stop a code being reused.
• Keep it plain. Apple notes that scanners typically use ISO 8859-1 or Windows-1252 encoding and that Unicode is poorly supported by most systems. Stick to letters and numbers.
• Show the value as text too. Google lets you set human-readable alternate text for when a barcode can’t be scanned. A cashier can type a short code in seconds.
• Look the code up on your side. Apple’s guidance is to trust your database and use the pass as a quick way to find a record, not to rely on values printed on it.

Personalization

A generic pass with the same name and number on every copy doesn’t earn a place on someone’s phone. Personal details, such as a name, a balance or a seat, are what make people keep it.

• Design one pass, and fill in each person’s values from a data source rather than making one design per person.
• Keep personalized values short, since they are the fields that appear on the front. A long name that fits in a spreadsheet may not fit on the pass.
• Decide what happens when a value is missing, so a blank isn’t shown as an empty or broken field.

Notifications and lock-screen alerts

Notifications are the most powerful and most abused part of a pass. The platforms treat them very differently.

Apple Wallet

Apple doesn’t have a free-text push. Instead, when a field on the pass changes and that field has a change message, the device shows the message. Apple is direct about when to use it: change messages interrupt the user and must be read immediately, so they’re typically appropriate only for time-sensitive information, such as a concert that has been delayed by an hour and moved across town.

Apple also supports relevance, which raises a pass on the lock screen at the right time and place:

• A pass can have up to ten relevant locations.
• You can add up to ten unique beacon UUIDs.
• Coupons and store cards use location only, with a small radius on the order of a hundred meters. Event tickets and boarding passes can use a date and an optional location with a large radius, on the order of a thousand meters. Coupons and store cards don’t support a relevant date.

Google Wallet

Google does have a message API. You may send a maximum of three messages that trigger a push notification in a 24-hour period per pass. More attempts return a quota error, and Google may throttle delivery if it decides you’re spamming people. People must have notifications enabled for their passes to receive them. When someone taps a notification, they see the pass with a callout that leads to the new message on the back.

For generic passes, Google also supports two built-in notifications tied to a time interval: an upcoming notification 24 hours before the interval starts, and an expiry notification 48 hours before it ends.

What good looks like

• Send when there’s news. A delay, a change of venue, an offer that ends tonight, a reward that’s ready.
• Set your own cap, well under Google’s three a day. One or two a week is plenty for most businesses. A person who removes the pass can’t receive anything.
• Lead with the value, in the first few words. Lock screens truncate. Google’s guidance for its own alerts is a title under 29 characters and a body under 40 characters when collapsed.
• Keep links relevant. Google asks that links in messages point to resources directly connected to the pass.

Updating passes

Being able to change a pass after it’s saved is one of the biggest reasons to use a wallet pass rather than a PDF, and the platforms handle it differently.

Apple Wallet

Updating is a cooperative effort between the device, Apple’s servers and yours. After a pass is added, the device registers with your server. When something changes, your server sends a push notification with an empty payload to each registered device. The device then asks your server what changed and fetches the latest version of the pass. Apple’s reasons for the empty payload: push notifications aren’t guaranteed to be delivered, and several from the same source are coalesced into one.

• You update by replacing the pass, not by sending a list of changes. Anything can change except the pass type ID and the serial number.
• Updates aren’t guaranteed. The person may be offline or may have turned updates off for the pass.
• Don’t change the authentication token in an update, because some devices may still hold the old pass.
• Test on a real iPhone. Apple notes the iOS Simulator doesn’t register for push notifications.

Update, or create a new pass?

Apple’s example is a good test. Updating a train ticket for a delayed departure, or a store card to show the current balance, is fine. Replacing a coupon for free breadsticks with a coupon for a free drink will confuse people, because from their side one coupon disappeared and another appeared. In that case, issue a new pass.

Trust your server

Apple’s guidance is worth quoting almost directly: don’t rely on the balance shown on the pass, because values on it may not be up to date. Always read important information from a source you control. The same applies to a stamp count, a points balance or a gift card amount. Treat the pass as a display of your data.

Expiry and lifecycle

• Set an expiry on anything time-limited: tickets, coupons, memberships, gift cards where the law allows. Both wallets can show a pass as expired. On Apple, expired passes move to an expired section.
• Enforce validity on your side. Apple’s advice is not to expire or void a pass by pushing an update. Update your database to mark it invalid and check the database when the pass is redeemed. People forward passes, and devices may not have updated.
• Never delete a customer’s pass without their consent. Apple says apps shouldn’t remove expired passes without the user’s consent.
• Plan for multiple devices. iCloud syncs Apple passes across a person’s devices, and if you email a pass they can forward it. Don’t design redemption around a pass living on exactly one device.

Distributing passes

A great pass still needs people to add it. Where and how you offer it matters.

Use the official buttons

Apple’s Add to Apple Wallet badge is available in 45 locales, as SVG for web and email or EPS for print. Don’t create your own version. Use it on a white or light background, or the outline version on a very dark one, leave a minimum clear space of 0.1X (X being the badge’s height), don’t add shadows or glows, and don’t let it dominate your layout. Place it near the pass it adds. In email or on the web, include instructions for opening it on an iPhone, since people may open the message on another device.

Google’s Add to Google Wallet button comes only in black, has a minimum height of 48 dp and needs 8 dp of clear space on every side. It should be at least as large as other buttons nearby. Use Google’s provided buttons, including its localized versions, and don’t change the font, color, radius or padding.

Write “Google Wallet” with a capital G and a capital W, and never abbreviate it.

Give people a reason and a path

• Tell people what they get: “Save your loyalty card”, “Add your ticket”, rather than a bare button.
• Put a QR code at the counter or on the receipt for in-person sign-ups, so a guest can scan and add in a few taps.
• Show the right button for the device, or show both, and make it obvious which is which.

Testing on real devices

A pass that looks right in a preview can still fail in a wallet. Always test on real phones, and test the way a customer would.

1. Add the pass on a real iPhone and a real Android phone. Check that the logo, icon, strip or hero, colors and every field look right, including long values.
2. Scan the code with the scanner you’ll use. Try low screen brightness, a cracked screen protector and a slightly tilted phone.
3. Look at the lock screen. On Apple, check the icon and how the pass surfaces.
4. Change something and watch the update arrive. Then turn the phone’s network off and on, and confirm it catches up.
5. Send a test notification. Confirm it appears, and that tapping it lands somewhere sensible.
6. Remove the pass and add it again. Check that nothing breaks and that your records stay consistent.
7. Try the pass with the wallet in another language and with a large text size if your customers use them.

Common mistakes

• Text in the hero or strip image. It gets cropped, overlapped by fields and can’t be localized.
• One image for both wallets. Apple’s strip is wide and short, and Google’s hero is nearly square.
• A pre-masked circular logo for Google. Supply a square image with a 15% margin and let Google mask it.
• Low-contrast text on a bright or busy background.
• Too many front fields. Move terms, hours and extras to the back.
• The same value in every pass’s code. Each pass should have a unique, plain value.
• Trusting the balance on the pass. Keep the real number on your server.
• Notifying too often. Google caps push messages at three per pass per day, and people remove passes that nag.
• Replacing one offer with a different one through an update. Issue a new pass instead.
• Never testing on a real device. Especially for push updates, which the iOS Simulator doesn’t exercise.

Pre-launch checklist

• Logo is legible on your background, in both wallets.
• Apple strip (or thumbnail) and Google hero are each cropped for their wallet, with no text in the image.
• Text passes a contrast check, and fields are short.
• Terms, hours and contact details are on the back.
• The code type matches your scanner, and each value is unique.
• Personalized values fit, and missing values are handled.
• Expiry is set where it applies, and enforced on your side.
• You have a notification plan and a cap on how often you send.
• You’ve saved, scanned, updated, notified and removed the pass on a real iPhone and a real Android phone.
• You’re using the official add buttons.

Frequently asked questions

Sources

Last checked on September 29, 2026. Apple’s current developer pages load dynamically, so the Apple numbers above come from its Wallet Developer Guide. If Apple’s current documentation differs, follow Apple.

• Apple: Wallet Developer Guide, Pass Design and Creation
• Apple: Wallet Developer Guide, Wallet Ecosystem Design
• Apple: Wallet Developer Guide, Updating Passes
• Apple: Add to Apple Wallet badge guidelines
• Apple: Human Interface Guidelines, Wallet
• Google: Brand guidelines, Generic pass
• Google: Brand guidelines, Loyalty cards
• Google: Trigger push notifications, Generic pass
• Google: Notifications, Generic pass