Mobile wallet and digital IDs

An ID card can live on a phone as well as in a wallet — Apple Wallet on iOS, Google Wallet on Android. It can also live only on a phone, with no plastic printed at all.

This guide covers both: what they are, when to use which, and what changes for the people doing the work.

Off by default. Wallet passes need credentials from Apple and Google that have to be obtained by hand. See Deployment → Mobile wallet passes for that setup. Nothing in this guide happens until FEATURE_WALLET is on and the organisation has opted in under Settings → Mobile wallet.

One credential, one or two forms

The most important idea here, and the one that prevents a lot of confusion:

A card holder has one credential. It may exist as plastic, as a pass on a phone, or as both. Not two cards. One serial number, one verification code, one record. The QR printed on the plastic and the QR in the wallet pass resolve to the same page and show the same status.

That has a practical consequence worth knowing: if someone holds a digital ID and you later print them a plastic card, their pass does not die. The existing credential gains a physical form. Revoke the credential and both stop working together.

Choosing a delivery mode

Settings → Mobile wallet → Delivery. Three choices:

Mode	What happens	Good for
Printed card only	The original flow. Photo → order → print run → card registered. A wallet pass is offered afterwards if passes are enabled.	Organisations where the plastic card is the credential — door access on old readers, visual checks, anywhere a phone is not acceptable.
Digital only	Approving a photo issues the credential immediately. No order, no print job, nothing to collect.	Contractors, visitors, short-term staff, conference delegates. Anyone whose ID would be obsolete before a print run finished.
Both	Digital issued straight away, plastic printed as well through the normal order flow.	The common case for staff and students: usable on day one, plastic follows.

Choosing a digital mode switches wallet passes on automatically. There is no way to hand somebody a credential with no plastic and no pass.

What changes for whoever reviews photos

This is the part to brief people on, because it changes what a routine action means.

Under Printed card only, approving a photo is a step towards a print run. Nothing reaches the card holder.

Under Digital only or Both, approving a photo issues that person’s ID. The credential becomes valid immediately — verifiable at a door — and they are emailed a link to add it to their phone within seconds. There is no second confirmation and no queue to intercept it.

The portal says so in three places, so nobody has to remember:

• A warning above the photo review queue naming the mode and whether an email goes out.
• The confirmation after approving: “Approved. ID OT-000021 issued and emailed to the card holder.” rather than just “Approved”.
• A warning on the settings page when a digital mode is selected.

Bulk approve does exactly the same thing, once per photo. Approving forty photos issues forty credentials and sends forty emails.

If that authority does not belong with your photo reviewers, use Printed card only and issue digital IDs deliberately with the button below.

Issuing one digital ID on its own

On a card holder’s Cards tab there is an Issue digital ID button. It appears only when it would do something: the person has an approved photo, they do not already hold a live credential, and wallet passes are enabled.

Use it for someone whose photo was approved before digital delivery was turned on, or in a print-first organisation for the one person who needs an ID today. It confirms first, and tells you plainly that the credential becomes valid immediately and that an email is going out.

What the card holder sees

If they have a portal login: an Add to your phone card on My card, with Apple and Google buttons.

If they do not — casual staff, contractors, visitors, most people with a card — they get an email with a link to a page carrying the same buttons. This matters: a large share of card holders never sign in to the portal at all, so without the email a digital credential would be unreachable. Enable it under Settings → Mobile wallet.

Digital issuance always emails, whatever that toggle says. With no plastic arriving, the email is the delivery mechanism.

Links expire after WALLET_DOWNLOAD_TOKEN_TTL_DAYS (30 by default), or 24 hours after the first pass is downloaded from them, whichever comes first. A forwarded link is a copy of the credential, so it should not outlive the holder’s own use of it by long.

Keeping passes correct

Passes update themselves. Nobody has to reissue anything.

When this happens	The pass
Photo approved or re-cropped	Rebuilds with the new portrait
Name, department or expiry changed	Rebuilds
Card revoked, or reported lost or stolen	Struck through, immediately
Card reaches its expiry date	Struck through, within the hour
Plastic printed for a digital holder	Keeps working; gains a printed form
Organisation logo or colours changed	Every pass in that organisation rebuilds

Apple devices are pushed to as soon as something changes. Google needs no push — updating the object propagates on its own.

Revocation is never batched or delayed. A revoked card that still looks valid on a phone is the one failure that would make the whole feature untrustworthy.

Checking it is working

Admin → System health → Mobile wallet shows passes issued, how many are on devices, how many are waiting to rebuild, and push failures in the last 24 hours. It also shows the Apple certificate’s expiry date, and warns from 45 days out.

Test APNs connectivity proves Apple push works without needing a device. A healthy result is APNs rejecting a deliberately invalid test token — that means the certificate and topic passed and only the token was wrong.

For one person: their Cards tab shows each pass, when it was last built, how many devices hold it, recent delivery attempts, and a Rebuild & push button. Without that, a stuck push is invisible.

Limits worth knowing

• Google Wallet does not exist on iPhone. Google withdrew the iOS app. Google passes are Android and desktop browser only.
• Apple passes need a real Apple certificate. A self-signed one will not install on any device, including the Simulator.
• NFC door access is not included. Unlocking doors over NFC is a gated Apple/Google partner programme, not something that can be self-served. The schema leaves room for it.
• One barcode per pass, and it belongs to the campus scanners. Apple and Google each render a single native code — carried here as Code 128 of the ID number, because machines cannot adapt and humans can. The verification QR is not lost: “Verify this card” on the back of the pass opens the verification page, which offers Show QR for scanning — a full-screen code the checker scans with their own phone. That direction is the trustworthy one: a status page shown on the holder’s screen can be mocked up, a code scanned into the checker’s own device cannot.
• Google fetches pass images over public HTTPS. The holder’s portrait is reachable by anyone holding an unguessable URL — the same exposure class as the verification code, but worth stating to a customer rather than burying.

When something looks wrong

See Troubleshooting → Mobile wallet.