The event pass, in Apple Wallet
An event67 Wallet pass is the attendee's event pass held in Apple Wallet, next to their boarding card. The backend refreshes it while the event runs, so it is a live object rather than a screenshot, and it is what your door team scans at check-in.
What this looks like in the product
Wallet is where an attendee already looks for the thing that gets them through a door.
- Apple Wallet pass
- An event pass added to Wallet, alongside boarding cards and coffee cards.
- Backend refresh
- The pass is updated by the backend while the event runs rather than being a static image.
- Live Activity on iOS
- A live event surface on the lock screen, driven by the same dispatcher as push.
- Door scanning
- The pass is what your team scans at check-in, so it works when the phone is nearly flat.
- Certificate-gated
- Wallet passes need a signing certificate configured; the feature is off when one is not.
The pass
- Your name and the event
- The dates and venue
- A scannable code
- Refreshed by the backend
- Lives beside the boarding card
Why a Wallet pass and not just the app
The argument for Wallet is a queue at eight-thirty in the morning, and it has three parts.
Attendees already know where it is. Wallet is where a boarding card lives, and it is a muscle memory that does not have to be taught at the door. A person who has forgotten your app's name has not forgotten how to double-press for Wallet.
It survives a dead battery better than an app does, because it is the last thing available on a phone with four percent and no interest in loading anything.
And it is one action rather than three. Unlock, open app, find the pass screen is a sequence somebody will fumble with a coffee in one hand. The pass is faster, and at eight-thirty in the morning speed at the door is the entire operational question.
The pass is also live. It is refreshed by the backend during the event rather than being a fixed image, which is why it is worth having a pass at all instead of emailing a PNG.
How the pass gets onto a phone
You configure the signing certificate
Apple requires a Pass Type certificate to sign passes. Without one configured, the feature is simply off — this is the setup step, and it is the reason to treat Wallet as available rather than always on.
The attendee claims their invite
Claiming is what creates the person's identity for the event, and it is also what the billing meter counts.
They add the pass
Into Apple Wallet, where it stays for the event.
The backend keeps it current
Updates are pushed to the pass while the event runs. On iOS the same dispatcher drives the Live Activity surface.
The honest boundary
- Apple Wallet only. There is no Google Wallet pass, so Android attendees use the app for their pass.
- Certificate required. No certificate configured means no passes; this is a genuine prerequisite rather than a toggle.
- It is an access pass, not a credential. It is not an Open Badge, it is not verifiable by a third party, and it proves nothing after the event ends.
- No ticketing. The pass does not represent a purchase, cannot be transferred as a ticket, and has no resale or refund concept attached to it.
- Not a substitute for the app. The live features, the schedule and the connections are in the app; the pass is a door credential and a lock-screen presence.
The Android gap is the one to plan around. If a majority of your audience is on Android, build the door process around the in-app pass and treat Wallet as a convenience for the iPhone half rather than the primary route.
- signing certificate required before any pass can be issued
- 1signing certificate required before any pass can be issued
- the only platform with a Wallet pass; Android uses the in-app pass
- iOSthe only platform with a Wallet pass; Android uses the in-app pass
- tickets, transfers or resales — a pass is an access credential
- 0tickets, transfers or resales — a pass is an access credential
The certificate, and what it means for your timeline
Wallet passes are the one feature in event67 with a genuine prerequisite, and it is worth understanding before you promise passes to anybody.
Apple requires every pass to be cryptographically signed with a Pass Type ID certificate issued from an Apple Developer account. Without one configured, event67 simply does not issue passes; the feature is off rather than degraded. That is why we describe Wallet as available rather than always on.
The practical consequence is a lead time. The certificate is created in an Apple Developer account, which means somebody in your organisation with access to that account has to do a short piece of work, and in most companies the hard part is finding out who that person is rather than the task itself. Plan it alongside the store listing rather than in the week of the event.
- If you already have an Apple Developer account, this is a short setup task.
- If you do not, the account itself has to be created first, and that has its own approval process.
- If your branded app is being published under our developer account, ask us about passes at the same time rather than separately.
- If the certificate is not in place, plan the door around the in-app pass, which needs nothing configured.
Where a Wallet pass is worth the setup
Large events with a compressed arrival window, where the door is the operational risk and seconds per attendee is a real number. Multi-day events, where the pass being permanently to hand beats reopening an app four times. Executive and hospitality audiences, where the app install rate is lower and the Wallet pass reaches people who never opened anything else.
It is not worth the certificate setup for a fifty-person internal meeting where the door is a person with a printed list who already knows everybody.
Last updated
What it costs
- Free up to 50
- activated attendees, on one live event
- $5
- per activated attendee beyond 50
- $4,750
- the most one event can ever cost, whatever happens past 1,000
Activated means the person claimed their invite and opened the app. Not when you import them, not when the invite is delivered, and not if they register and stay home.
Questions people actually ask
Do you support Google Wallet?
No. Passes are Apple Wallet only today. Android attendees carry their pass in the app instead, which works at the door in exactly the same way, so nobody is locked out — but if most of your audience is on Android, plan the door around the in-app pass.
Does the pass update if the event changes?
Yes. The backend refreshes the pass while the event runs, which is the reason to use a pass rather than emailing a static image. On iOS the same dispatcher also drives a Live Activity surface during the event.
What do we need to configure before passes work?
An Apple Pass Type signing certificate. Passes cannot be issued without one, and the feature stays off until it is configured. Treat this as a setup task with a lead time, not a switch you flip on the morning of the event.
Is the Wallet pass a ticket?
No. event67 does not sell tickets, so the pass represents attendance rather than a purchase. It cannot be transferred, resold or refunded, because none of those concepts exist here.
Can attendees use the pass to prove they attended afterwards?
Not in any verifiable sense. It is an access pass, not a credential: there is no Open Badge, no certificate and no continuing-education record anywhere in event67. If your programme needs verifiable attendance, that is a genuine gap.
Keep reading
Features at the door
Event types that lean on this
See it in your own event
Your first 50 attendees are free on every event, so the smallest version of this costs nothing to try.