How to Create an Apple Wallet and Google Wallet Pass for Your Business
By Michael Chora · Published · Last updated
You can create an Apple Wallet pass and a Google Wallet pass for your business in three ways: use a wallet pass platform with a visual builder (the fastest, no code), call a pass API from your own system, or build and sign each pass yourself with Apple's and Google's developer tools. Whichever you pick, the steps are the same: choose the pass type, design it, issue one pass per customer, give customers a way to add it, and test on real phones. This guide walks through each step and shows where the three routes differ.
Step 1: Pick the pass type
Both wallets organise passes into types. Choose the one that matches what the customer is holding.
| What you want | Apple Wallet pass style | Google Wallet pass type |
|---|---|---|
| Loyalty or stamp card | storeCard | Loyalty card |
| Membership card | generic or storeCard | Loyalty card or Generic pass |
| Coupon or offer | coupon | Offer |
| Event ticket | eventTicket | Event ticket |
| Gift card | storeCard | Gift card |
Apple defines five styles in the pass format: boardingPass, coupon, eventTicket, generic and storeCard (Apple: Creating the source for a pass). Google publishes a separate set of pass types and a flexible Generic type (Google Wallet developer docs). A platform hides this mapping: you pick "stamp card" or "membership card" and it produces the right style for each wallet. See the loyalty card, stamp card and membership card pages for examples.
Step 2: Decide what goes on the pass
Keep it short. A pass is read in a second at a counter. Decide on:
- Branding: a logo and one or two brand colours. Apple requires an
icon.png; a logo and strip image are optional. - The one thing the customer needs to see: stamps collected, points balance, tier, expiry date or event time.
- A barcode or QR code that staff scan. Apple supports QR, PDF417, Aztec and Code 128 barcodes.
- What can change later: a balance, a status, a message. Changeable fields are the main reason to use a pass instead of a PDF. See how pass updates and push notifications work.
Step 3: Choose how you will build it
Route A: a wallet pass platform (no code)
With a platform you design once and get passes for both wallets. On Shakewell Wallet the flow is:
- Start a free trial and open Cards, then Create card.
- In the four-step builder (Basics, Brand and design, Pass content, Review), choose the card type, name it, upload your logo and set colours. A live preview shows the card as you go.
- Choose the details customers fill in at signup, such as name and email.
- Review, then Publish card.
You do not need an Apple Developer account for this: Shakewell signs Apple passes with its own certificate (Apple Wallet setup), and Google Wallet passes are issued through Shakewell's integration (Google Wallet setup). If you want a head start on the design, the free template gallery has starting points.
Route B: a pass API
If your customers already live in your own system (a booking tool, an e-commerce store, a membership database), issue passes from code instead. With the Shakewell REST API, one call creates a pass that works in both wallets and returns an install link. The quickstart has cURL, Node, PHP and Python examples. The REST API is on Growth plans and above; see pricing for what each plan includes.
Route C: build each pass yourself
You can skip platforms entirely. The cost is that you take on certificates, signing and update servers. In outline:
Apple Wallet
- Join the Apple Developer Program, register a Pass Type ID and create a certificate for it (Apple: Building a pass). The next guide, Apple Wallet pass certificates explained, covers this in detail.
- Write a
pass.jsondescribing the pass, and add the images. - Create a
manifest.jsonlisting a SHA-1 hash of every file, then sign the manifest with your certificate to produce thesignaturefile. - Zip everything into a
.pkpassfile and serve it with the MIME typeapplication/vnd.apple.pkpass.
Google Wallet
- Create an issuer account in the Google Pay and Wallet Console and a Google Cloud service account with access to the Wallet API (Google: prerequisites).
- Create a pass class (the shared design) and a pass object (one customer's pass) through the REST API.
- Sign a JWT with the service account key and give the customer the resulting "Add to Google Wallet" link (Google: JWT).
For a worked, runnable version of the Google side, read the Laravel tutorial for issuing a Google Wallet pass.
Which route should you pick?
| Platform | API | Build it yourself | |
|---|---|---|---|
| Needs code | No | Yes, a few calls | Yes, signing and servers |
| Apple certificates | Handled for you | Handled for you | You manage and renew them |
| Updates and pushes | Included | Included | You run the update service |
| Best for | Most small businesses | Existing software that needs passes | Teams that want full control |
For most businesses, Route A is the right answer. Reach for Route B when passes must be created automatically by another system, and Route C only if wallet infrastructure is part of your product.
Step 4: Give customers a way to add the pass
A pass is useless until it is on a phone. The common routes:
- A signup link or QR code on the counter, receipt, menu or poster. On Shakewell, every card can have a hosted signup form; the customer fills it in and taps to add the card (how customers get their pass).
- An install link sent after a purchase or booking, by email or SMS, if you issue passes through an API.
- An embedded form on your website.
Opened on an iPhone, an install link offers Apple Wallet. On Android it offers Google Wallet. Customers do not install an app.
Step 5: Test on real phones
Do not trust the preview. Add the pass to at least one iPhone and one Android phone and check:
- The pass adds without an error.
- Colours and text are readable, including in dark mode and at low brightness.
- The barcode scans from the lock screen at your actual counter.
- An update (change a balance or message) arrives on the device.
If you build Apple passes yourself, run the file through the free pkpass validator first. It checks the file structure, manifest hashes and required keys in your browser, but it cannot verify the signature, so a device test is still essential.
Step 6: Plan for what happens after launch
Passes are live objects. Plan the first month:
- Who updates balances and statuses, and how (staff scanning, a till integration, or the API)?
- When will you send a push message, and what will it say? Keep messages rare and useful.
- How will you retire a pass (voided or expired) when a membership ends?
Common questions
Do customers need an app? No. The pass lives in the wallet already on their phone.
Do I need to make two separate passes? Not with a platform or API that issues both. If you build by hand, yes: Apple and Google use different formats and signing.
How long does it take? With a platform, designing and publishing a first card can be done in a sitting. Building by hand takes longer, mostly because of certificate setup and testing on devices.
Can I try it first? Yes. Shakewell Wallet has a free trial with no credit card to start; see pricing for the terms.