How to Create an Apple Wallet and Google Wallet Pass for Your Business

By · 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 wantApple Wallet pass styleGoogle Wallet pass type
Loyalty or stamp cardstoreCardLoyalty card
Membership cardgeneric or storeCardLoyalty card or Generic pass
Coupon or offercouponOffer
Event ticketeventTicketEvent ticket
Gift cardstoreCardGift 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:

  1. Start a free trial and open Cards, then Create card.
  2. 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.
  3. Choose the details customers fill in at signup, such as name and email.
  4. 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

  1. 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.
  2. Write a pass.json describing the pass, and add the images.
  3. Create a manifest.json listing a SHA-1 hash of every file, then sign the manifest with your certificate to produce the signature file.
  4. Zip everything into a .pkpass file and serve it with the MIME type application/vnd.apple.pkpass.

Google Wallet

  1. 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).
  2. Create a pass class (the shared design) and a pass object (one customer's pass) through the REST API.
  3. 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?

PlatformAPIBuild it yourself
Needs codeNoYes, a few callsYes, signing and servers
Apple certificatesHandled for youHandled for youYou manage and renew them
Updates and pushesIncludedIncludedYou run the update service
Best forMost small businessesExisting software that needs passesTeams 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.

All guides

Guides + product

Ready to ship your first wallet card?

Set up takes minutes. No credit card required to start a free trial.