Why a wallet and not an app
A loyalty scheme lives or dies on whether the customer picks it up at all. For a café or a salon, installing an app is the hurdle many people stop at. In the usual scenario, the card can be added to a supported wallet without installing a separate app. The exact flow depends on the platform and how the card is issued. That is exactly what Walio is built on.
The price is that Apple and Google set the rules. And they are not the same rules: Apple Wallet and Google Wallet look similar to the customer but work differently under the hood. Cards are issued differently, updated differently and notifications follow different conditions. That is why we describe each one separately below.
What a card in the wallet can do
On both platforms a card handles the same basics:
- Carry state: stamps, points, visits remaining. The details can be changed remotely after issue.
- Show a QR or barcode for staff to scan.
- Show the customer a change, such as a new stamp count. Whether and how the change is announced with a notification depends on the platform and the phone’s settings.
- Offer itself at a relevant moment, for example near the venue. The conditions differ between platforms and depend on location and phone settings.
- Carry the brand: colours, logo, field labels.
Apple Wallet: a signed pass and device registration
A .pkpass file signed with a certificate
A card in Apple Wallet is a pass, that is a .pkpass file. It is a bundle containing the card data, images and a signature. Every pass has to be signed with a certificate the issuer obtains through an Apple developer account. Without a valid signature the wallet will not accept the pass. The certificate has a limited validity, so its renewal needs watching.
Updates through device registration
When the customer adds the pass, the phone registers with the issuer’s server. Registration means the server knows which devices to tell about a change. When something changes, the server sends the phone a signal, the phone downloads the new version of the pass and the wallet shows it. So the server has to keep running and responding for as long as cards are in circulation.
Relevant display
A pass can carry information about when or where it is useful, such as the venue’s location. The system may then offer it to the customer. It is an offer from the system, not a guaranteed display: whether and when the pass appears is decided by the phone and its settings, including location permission.
Change messages
A field on the card can have a change text, known as changeMessage. When the field’s value changes, the phone shows the customer a notification, such as “You have 7 of 10 stamps”. Apple recommends using changeMessage for time-sensitive changes and states explicitly that it should not be used for marketing or other non-critical messages. The customer can also turn off notifications for a specific card.
Google Wallet: classes, objects and the API
Class and object
Google Wallet works with two layers. A Class describes the scheme as a whole: name, logo and the details shared by all cards. An Object is one customer’s specific card with its own state and code. One class therefore holds the cards of every customer in the scheme.
Issuer account, service account and JWT
Google uses a different issuing model from Apple. The issuer has an issuer account with Google, and its server signs in to the Google Wallet API through a service account, a technical account meant for server-to-server communication. The card reaches the customer through an “Add to Google Wallet” link or button carrying a signed JWT. That is a short signed token with the card data which Google uses to save the card. So instead of a file signed with a certificate as with Apple, requests and tokens are signed with the service account’s key.
Updating the object
Changing a card’s state means updating the object through the API. The issuer’s server does not send anything directly to the phone; it changes the data at Google and Google updates the card in the wallet. Anything that applies to the whole scheme is changed in the class.
Messages and notification conditions
A message can be added to an object or class and is shown with the card. For the customer to get a notification about it, they must have the relevant notifications enabled. For features tied to being near the venue, the conditions depend on location and phone settings.
What it cannot do, and it surprises people
What can change after issue and what cannot
According to the documentation, the content of an Apple Wallet pass can be updated, while some identifying details stay fixed. The exact limits depend on the pass style and how it is updated. The pass style also decides how many fields fit where. In Google Wallet the specific card’s object changes and the layout is set mainly by the class. We design the layout with room to spare so a later value does not have to push anything out.
Card updates are not marketing messages
Card updates can show the customer a change, such as a new stamp count or an upcoming reward. But they are not marketing push messages. Apple intends them for time-sensitive changes, with Google the user must have notifications enabled, and on both platforms the customer can turn them off. Using the card as an advertising channel risks the customer switching notifications off or deleting the card.
A card is not proof of identity
The code on a card can be photographed and passed on. For points that does not matter. For a ticket or a reward of real value the system has to enforce single use, and that is done on the server, not on the card.
Whoever issues the cards sets the price
A business can have its cards issued through a third-party service that signs Apple Wallet passes and talks to the Google Wallet API on its behalf. Such services usually charge per card issued or per active customer per month. On a scheme with thousands of cards that is a line item which grows precisely when the scheme is going well.
Walio signs the passes on its own infrastructure, not through a third-party service. That keeps issuing cards under our own control, and watching the certificates stays with us too. It is extra work, but predictable work.
The terminal is half the job
The card is only one side. The other is the member of staff with three people queuing. If scanning the code and adding a point takes more than two taps, or waits on a server, staff stop doing it within a week and the scheme dies. The terminal has to work on a weak signal and must not require a till system.
This cannot be sorted out later. Designing the card means designing what the person behind the bar does at the same time. We approach every custom application the same way: start with whoever will work with it daily.
