Building Apple and Google Wallet Passes: Key Lessons

Introduction

Recently, I worked on integrating Apple and Google Wallet Passes into a side project. While the potential for this technology is huge, developer-focused guidance is surprisingly sparse beyond the official docs. This post distills the key technical lessons I learned while working with PassKit (Apple) and Google Wallet APIs, focusing on the core challenges and quirks of each platform.

Pass lifecycle and backend integration

When working with passes, the first thing to understand is the lifecycle workflow of a pass.

Apple Wallet Pass Lifecycle

Apple Wallet passes require your backend to serve the pass data and handle updates via push notifications (APNs). To trigger an update on users’ devices, you must push a notification to their passes via APNs. The pass itself is then re-fetched from your backend.

The workflow looks like this:

Backend generates and signs the .pkpass file
Backend sends a push notification through APNs
Device receives a notification and requests an updated pass
Backend serves the new pass data
Wallet app displays the updated pass

You can find more information in the official documentation.

Google Wallet Pass Lifecycle

For Google Wallet, it is the opposite. Your backend pushes pass updates directly to the Google Wallet API, which immediately propagates changes to users’ devices. The workflow is:

User adds a pass to Google Wallet through a Google Wallet link
Backend sends updated pass data to the Google Wallet API
Updates are handled through Google’s infrastructure
Changes appear on devices automatically

Also, you can find more information in the official documentation.

Here’s a side-by-side comparison of key differences between Apple Wallet and Google Wallet implementations:

Feature/Aspect	Apple Wallet	Google Wallet
Initial Setup	Requires Apple Developer Program ($99/year)	No developer program required
Pass Updates	Via APNs push notifications + backend re-fetch	Direct API updates
Certificate Management	Annual renewal required	No certificates needed
Testing/Debugging	Console app required, silent failures	Web version available, Android emulator support
Pass Stacking	Automatic with same pass identifier	No
Development Mode	Immediate access with developer account	Demo passes only initially
Business Validation	Not required	Required for production access
Push Infrastructure	Must push and configure APNs	Push to Google Wallet API

Key Lessons

Working with Apple Wallet

Apple Developer Program: You must enroll in the Apple Developer Program ($99/year) to create a Wallet Pass Identifier and generate signing certificates. Every .pkpass file must be signed with these certificates. Unsigned passes will silently fail when opened on devices.
Stacking behavior: When you use the same pass identifier and sign the passes with the same certificates, the passes will stack on each other in the Wallet application. There is no official way to automatically do the identifier and certificates generation, you need to do it manually on the Apple Developer Portal’s website.
Debugging is tough: Debugging passes can be hard. If your .pkpass is faulty, your device will silently fail and do nothing.
To debug, you need to use the Console application to get logs. I suggest that you filter the logs by the process name pass viewer.
Certificate expiration: The certificates expire every year. You need to generate new ones and update the pass with the new certificate.

Working with Google Wallet

Easy to start: Working with Google Wallet is easier, you don’t need to be in their developer program. You just need to send your pass object to the Google Wallet API
Demo passes: Initially, you can only generate demo passes. To be in prod mode, you need to validate your business profile and send Google some screenshots of your passes.
Emulator: To test your passes without having an Android device, you can either use the web version of Google Wallet or use Android Studio Emulator.

Conclusion

Integrating Apple and Google Wallet passes was both rewarding and challenging. Given the limited documentation and real-world examples, I ran into several tricky issues. Hopefully, this post will save you some time.
Exploring these APIs also gave me some ideas for my side project, and I’m still surprised this technology isn’t more widely adopted by businesses. From a technical perspective, there’s a lot of potential here and you can really leverage on the native features of the devices.
Even from a business perspective, Wallet passes offer a frictionless user experience. You get onto your clients’ devices without forcing them to install an app. It takes 10 seconds for a customer to add your pass to their Wallet.