Live cards
Cards that update themselves on the phone
A loyalty card is only convincing if the number on it is right. Add a stamp at the counter and the card in your customer's pocket changes — no app to open, no refresh, nothing for them to do.
Seconds, not next time
The card updates while the customer is still at the counter, which is when they will look.
Both platforms, properly
Apple gets a silent push. Google's copy is patched directly. Neither needs the customer to act.
Queued, not fire-and-forget
Updates are queued in the same transaction as the stamp, so an outage can never lose one.
Retried with backoff
A failed update is retried on a widening schedule rather than dropped or hammered.
What happens when a stamp is added
The stamp is written to an immutable ledger, the customer's balance is updated, and an update job is queued — all inside the same database transaction. That ordering matters: if the wallet update fails, the stamp still happened. A system that pushes first and records second can lose a stamp a customer watched being added, which is the one failure customers never forgive.
How Apple Wallet updates work
Apple does not let a server change a pass directly. Instead the pass registers the device, and the server sends a silent push that asks the phone to come and fetch the current version. The pass on the phone then refreshes itself. If Apple reports a device as gone — the customer deleted the card or replaced the phone — that registration is removed rather than pushed into forever.
How Google Wallet updates work
Google works the other way around: the card on the phone mirrors an object held on Google's servers, so there is no push at all. Updating the object updates the card. This is a genuine difference in architecture rather than a detail, and getting it wrong is a common and invisible failure — a card built only into the save link is created at whatever balance was true when the customer tapped save, and then never changes again.
Failure, and what happens to it
Queued jobs are claimed before work starts so two runs cannot process the same one. A failure is retried on a widening schedule so a provider having a bad minute is not hammered, and a job that exhausts its attempts is marked dead rather than retried forever. A card that was issued but never actually added to a wallet is skipped quietly, because that is the ordinary case and not an error.
What the customer sees
Nothing, which is the point. They do not open anything, refresh anything or log into anything. They glance at their phone and the number is right. This is the behaviour people already expect from a bank card, and almost never get from a loyalty app.
Common questions
- How fast does the card update?
- Usually within a few seconds — the queue is drained immediately after a stamp so the change lands while the customer is still at the counter, and again on a schedule to catch anything that failed.
- What if the customer has no signal?
- The update waits. The next time their phone has a connection, Apple delivers the push or Google's copy is read, and the card catches up. Nothing is lost.
- Does the customer get a notification for every stamp?
- The card updates quietly rather than announcing itself. Wallet passes are a poor channel for shouting at customers, and treating them as one is how people end up removing the card.
Keep reading
Apple Wallet loyalty cards
Put your café’s loyalty card in Apple Wallet, next to your customer’s boarding passes and bank cards. No app download, no hardware.
Google Wallet loyalty cards
Give Android customers a loyalty card in Google Wallet. Same QR code, same counter flow, no app to install.
Digital stamp cards for cafés
Replace paper punch cards with a digital stamp card your customers keep on their phone. Buy nine, get the tenth free — without the lost cards.
Put your loyalty card in your customers’ pockets
Publish a branded card in about five minutes. 14-day free trial, cancel any time.