Wallet Passes PoC

1. Add passes

One passenger becomes a single pass; several become a bundle.

Drop .pkpass or .pkpasses files here or click to choose

or

More options

Name shown on the ticket page Booking reference Google Wallet link (only to test Android) Allow more than 10 passes in one bundle (only to test Apple's limit)

2. Scan with the phone camera

This QR is the pass download link: scanning it on an iPhone opens the Add to Apple Wallet sheet, and on Android opens Google Wallet. See How it works below.

Ticket page link (email link; Open ticket page)
Pass download link (the QR code and the buttons below)

Both buttons open the pass download link, which picks the wallet for the device:

Test tickets

How it works

Three different addresses

Address	What it is	Who uses it
`/` this page	The test console. Creates and withdraws test tickets. Not part of the real design.	You
`/t/{passId}?e=…&k=…&s=…` ticket page link	A web page showing the journey and the Add to Apple Wallet button. It is not the pass: opening it adds nothing to Wallet. This is what Open ticket page and Copy link give you, and what an email would link to.	Passenger
`/v1/{passId}?e=…&k=…&s=…` pass download link	The actual pass file (`.pkpass` for one passenger, `.pkpasses` bundle for several). It sits behind the Add to Apple Wallet button. On an iPhone it opens the Wallet sheet directly.	The QR code and the Add to Apple Wallet button

What the buttons do

Add to Apple Wallet (on the ticket page): opens the pass download link. Shown only on iPhone, iPad and Mac.
Add to Google Wallet (on the ticket page, everywhere except Apple devices): goes straight to Google's own link from the Ticketing API. Google hosts that pass; nothing is downloaded from here. Only shown if you supplied a Google link under More options.
Show QR: the QR code for that ticket again. It holds the pass download link, so scanning it on an iPhone goes straight to the Add to Apple Wallet sheet and on Android to Google Wallet. The Apple and Google buttons beside it open the same link; the Google one only appears when the ticket has a Google link.
Withdraw / Restore: simulates a refund. A withdrawn ticket's links return Ticket not available (410), even though they are still correctly signed.

Why the links look like that

passId identifies the journey's pass without revealing the booking.
e is when the link expires: the ticket's last valid date plus 30 days (30 days from now for tests).
k is the signing key version, so the key can be changed without breaking old links.
s is the signature. Changing any character of the link makes it invalid (403), so links cannot be guessed or edited.
The same e, k and s work for both the ticket page and the download, so the page can hand them on to its button.

What happens by device

iPhone, iPad, Mac: the download link streams the pass with Apple's headers and Wallet opens.
Android: the download link redirects to the Google Wallet link when one was supplied; otherwise it returns the pass file.
Anything else (for example Windows): the ticket page, with the Google Wallet button when a Google link was supplied and a note to open the link on a phone. Nothing is downloaded.

What is real and what is test-only

Real design: the two link types, signing, expiry, withdraw (410), device routing, the response headers and storage in the passes bucket.
Test-only: this page, the admin key, the Google link box, and keeping the ledger as a file beside each pass (the real design uses Firestore).
Use test bookings only: passes carry passenger names.