Google Wallet tickets for UK events

Covering the 30–45% of your audience on Android takes the same idea as Apple's passes with a different plumbing model — objects managed through Google's Wallet API rather than signed files. Together they mean nearly every fan walks up with a self-surfacing, full-brightness ticket.

How it differs from Apple's model

• Apple: you sign and distribute a file (.pkpass); updates push to the device.
• Google: you create pass classes/objects via API and hand fans an 'Add to Google Wallet' link (a signed JWT) — the pass lives server-side, so edits propagate instantly.
• Practical upshot: Google passes are easier to update en masse, Apple passes are easier to issue without infrastructure.

Issuing options

1. Platform-native support — again, ask specifically; 'mobile tickets' in marketing copy often means a PDF.
2. Pass-platform services covering both wallets from one dashboard.
3. DIY via the Google Wallet API (free issuer registration, REST/JWT integration) — a modest build for a team that already has one.

Rollout that works

• Put both wallet buttons in the confirmation email, above the PDF link.
• Keep design parity (colours, event info) so door staff see one visual language.
• Test the pass on a cheap Android handset — rendering differences are real.
• Keep the QR-in-email fallback for the no-wallet minority.