Two things, and both are needed. A QR code you show once from your panel, and a four-digit code you hand to the person. The QR without the code gets nobody anywhere, and neither does the code without the QR.
That is deliberately the only moment when somebody needs you. After it, their phone is paired and they scan without asking you for anything, until the day you cut the access.
What happens at pairing
You create the person in your team. At that moment Kanz generates their four-digit code and a pairing QR, and shows you the code once only. It is not stored anywhere in the clear, so nobody, Kanz included, can read it back to you later. If the person loses it, you generate a new one; you do not recover it.
The QR is valid for 24 hours and works once. That is short on purpose: a pairing link left lying in a conversation for three weeks is a link that ends up on a phone you did not choose.
On the phone, the person opens the QR and enters their code. The two are checked together. If it fails, the message is the same in all three cases: unknown QR, QR already used, QR expired. That is not lazy writing. Three different messages would teach anyone trying links at random which ones had existed, and an error that separates "this never existed" from "this has expired" answers a question nobody should have been allowed to ask.
After pairing, the phone is the key
Once the pairing is done, the phone holds a device key of its own. It is rechecked on every scan, not only when the scanner opens: if you cut access mid-service, the next scan is refused, not tomorrow morning's.
The practical consequence fits in one sentence: the device is the identity. Kanz does not ask for the code again at the start of each shift, so a paired phone stays a paired phone.
That gives two counter rules, and they matter more than everything else in this article.
One phone per person. If three people pass the same phone around, your scans all land on the same record, and the question "who validated this reward" has no answer any more. That is not a security problem, it is a bookkeeping problem, and it is the one that gets noticed first.
Cut access on the day somebody leaves, not the week after. A paired phone that walks out with somebody stays paired. The move takes two seconds and there is no reason to put it off.
How you cut it
Two levels, depending on what you want.
You can revoke a phone, which is the right move when a device is lost or replaced and the person stays. They pair again with a new QR.
You can deactivate the person, which cuts every phone they have paired in one go, including the ones you had forgotten about. That is the right move for a departure.
Either way it is immediate in the strict sense: the check happens on the next request, not at the next sign-in and not at the next refresh.
Why the scanner is not simply an account
The question comes up often: why not hand out a username and a password, like everywhere else?
Because it is not the same situation. The scanner is a counter tool, used a hundred times a day, often one-handed, sometimes with somebody waiting in front of you. A login screen at that moment is a login screen people work around: you stay signed in permanently, you write the password down under the till, you share it. The result is a shared account, which is exactly what you were trying to avoid.
A paired device solves it from the other end. Authentication happens once, when there is time to do it properly, and what is left afterwards is revocable by you, one device at a time, without changing anything for anybody else.
And the scanner opens the counter and nothing else: record a visit, look a customer up by number, validate a reward. It does not open your settings, your billing or your full list. A paired person cannot do what you do.
What it comes to day to day
You do not deal with it. That is the point: the only times access asks anything of you are the day somebody arrives and the day they leave.
In between, the one thing to watch is the list of paired phones. If it holds a device you do not recognise, a QR has been used by somebody else, and the answer is the same as for a set of keys: you revoke, and you pair again the ones that should be.
How the scan itself works, and why the card's code is verified without querying a database, is described here.