See the Mobile Wallet channel guide.
|Pass Type||Apple Wallet||Google Pay|
1Loyalty, gift card, and member card passes for Apple Wallet are based on Apple's Store Card pass style.
2Coupon passes for Google Pay are based on Google's Offer pass style.
|Pass Type||Available Triggers||Location Radius||Date Window||Apple Wallet||Google Pay|
|Gift card||Location||Small (100m)||✓||✓|
|Member card||Date and Location1||Small (100m)||✓||✓|
|Event ticket||Date and Location2||Large (1,000m)||✓||✓||✓|
|Boarding pass||Date and Location3||Large (1,000m)||✓||✓||✓|
|Generic||Date and Location1||Small (100m)||✓||✓|
1 Location can be used alone, but Date cannot be used without Location.
2 Date can be used alone, but Location cannot be used without Date.
3 You can specify a Date, a Location, or both.
- Available Triggers
- The triggers that will cause pass-related text to appear on the lock screen.
- Location Radius
- The minimum required proximity to a defined location trigger for Relevant Location
text to appear on the lock screen.
Location Radius is for Apple Wallet only. The proximity requirement for Google Pay is 150 meters for all pass types.
- Date Window
- The window of time before and after a defined date and time trigger when Relevant Date text will appear on the lock screen.
For Apple Wallet passes, also see Relevance Information Displays Passes on the Lock Screen, including Table 4-2, in Apple Wallet Developer Guide: Pass Design and Creation.
In addition to the layout information provided here, please also refer to Apple and Google developer documentation for the position of fields, images, and other design elements for each pass type.
Most passes can have up to three header fields, a single primary field, up to four secondary fields and up to four auxiliary fields.
Boarding passes use two primary fields to show origination and destination. They also can have up to five auxiliary fields.
Coupons and Member Cards combine secondary and auxiliary fields onto a single line, for up to four fields total.
Event Tickets with a background image and Generic passes with a square bar code (QR code or Aztec) will not use auxiliary fields.
The number of fields on a pass also depends on the text in each field. If there is too much text in a field, some fields will not be displayed.
Pass type also determines the types of images that will appear on the pass. Event Ticket passes have two different layouts, determined by the type of images and/or barcode types that are selected.
|Loyalty||Icon1, Logo, Strip, Hero2|
|Coupon||Icon1, Logo, Strip, Hero2|
|Gift Card||Icon1, Logo, Strip, Hero2|
|Member Card||Icon1, Logo, Thumbnail|
|Event Ticket (Layout 1)||Icon1, Logo, Background, Thumbnail|
|Event Ticket (Layout 2)||Icon1, Logo, Strip|
|Boarding Pass||Icon1, Logo, Strip, Hero2, Footer|
|Generic||Icon1, Logo, Thumbnail|
1 Icon images are available on iOS only.
2 Hero images are available on Android only.
For Apple Wallet, each image type should adhere to the specifications below.
|Image Type||Width||Height||Maximum File Size|
For Google Pay, specifications for each image type may change. The currently supported specs for Google Pay images can be found in the Google API Brand guidelines.
Images that are too large are automatically resized, which may reduce quality or change the expected proportions of the image. Always send and install a test pass, and verify the pass's appearance prior to distribution to end users.
Image file size limits are enforced when uploading via the dashboard or the API.
The images below indicate where each field appears on the pass. In some cases, field placement is determined by the images selected.
|Pass Type||Apple Wallet||Google Pay|
|Event ticket (Layout 1)|
|Event ticket (Layout 2)|
|Type||Display||API Associated Strings||Apple Wallet||Google Pay|
By default, templates allow pass sharing across users and devices. You can change the sharing policy for templates from the Templates menu for a wallet pass project.
Apple Wallet and Google Pay support slightly different sharing settings.
|Multiple users and devices (Default)||✓||✓|
|One user on multiple devices||✓|
|One user on one device||✓||✓1|
1 Intended for use in limited circumstances. Contact Airship Support for additional information.
Airship Mobile Wallet does not support RC4 ciphers and some other discretionary ciphers that are considered weak. The full list of supported ciphers is as follows:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
We strongly advise using TLSv1.2 if possible. SSLv3 and TLSv1.1 are not available at this time.
In an effort to make Wallet projects as secure as possible, we've removed support for several legacy platforms:
- Devices on Android Gingerbread or lower
- Devices on iOS 5.0.1 or lower
- Java 6 or lower
- Java 7 and 8 without Unlimited Strength cipher libraries enabled
- Windows XP, Server 2003, and Internet Explorer 9 (or lower)
Apple vs Google URL Differences
From the user’s perspective, the pass installation experience is similar on either iOS or Android — the pass is ultimately downloaded directly to either the Apple Wallet or Google Pay app. However, there are differences between the pass URLs:
Apple Wallet: Pass URLs generated from Apple Wallet templates point to a stored .pkpass file. A .pkpass file can be considered similar to a PDF or any other document that you might link to.
Google Pay: Pass URLs generated from Google Pay templates provide a deep link from Google into the Google Pay app so that the pass can be downloaded directly without requiring a browser window to facilitate the request.
For additional detail about the
publicUrl object and pass deep linking, see:
Single- vs Multi-Use Public URL
When generating a pass via the
API, you have the option to
create a publicly accessible URL for the pass, hosted at
https://wallet-api.urbanairship.com. The Public URL can be either a single
or multiple (multi-use) pass type, referring to the number of times the pass
can be be downloaded.
Use the Single option if you are creating a unique pass. A Single Public URL can only be downloaded once, but the user can share the pass from the Apple Wallet directly.
Use the Multiple option if the pass is non-unique and can be downloaded by multiple devices and shared many times.
A public URL is required for Android and optional for iOS.
The URLs returned by the CSV Batch Importer are multi-use passes — they can be downloaded by multiple devices.
Adaptive Link Expiration
By default, adaptive links expire after 6 months if they are unused. After you or a member of your audience uses an adaptive link to generate a pass, the link persists forever.
If you generate passes for an entire audience from a single adaptive link, then generating a test pass will cause the link to persist forever. If you distribute personalized adaptive links to your whole audience, then it's likely that some adaptive links will expire after six months, as not all users will click or tap their personalized link.
Passes generated from an adaptive link expire based on pass type or values set at the template or pass level.
Troubleshooting Apple Wallet Passes
In rare instances, some passes created in Airship Wallet projects will not load in Apple Wallet. Here are some probable causes:
- We've found inconsistent support of PNG image bit-depths by Apple Wallet and OS X PassViewer. 8-bit .png images are not currently supported by Apple Wallet. We recommend that you re-create your PNG at 24-bits (in Photoshop use Save for Web, and choose PNG-24), then re-upload your image in Airship Wallet.
- Corrupt graphics will sometimes cause an image to not appear on the pass. Regenerate your graphics using your favorite graphics editor (you can use Apple’s Preview.app if you prefer) as 24-bit PNGs and re-upload them to your Airship Wallet project.
Pass Design Elements
Pass appearance is dependent on the template design, but all passes have the same primary elements:
- Background color
- Data fields
- Barcode (optional)
For Apple Wallet passes, you can also set:
- Text color
- Icon image: This is displayed on the lock screen along with any notifications. It is also displayed when a pass is provided by an app, e.g., a mail attachment.
- Data fields on the back of the pass
See Pass Reference: Layouts for more information. These are iOS examples of a boarding pass, a coupon, and a loyalty card.