NFC or QR for your card? Tapping is about two seconds faster when it works, but a code works on every phone without exception and without setup. Always start with the code, because it covers a hundred per cent of your customers, and add tapping later as an accelerator rather than a replacement.
The question is not which is newer
Tapping feels sophisticated and a code feels old-fashioned, and that impression drives most decisions here. But the test at the counter is not modernity; it is one thing only: for what share of your customers does the attempt succeed first time? On that measure the code wins, and not narrowly.
Phone cameras have read codes natively on iOS and Android for years, with no app and no setup. Tapping depends on an enabled chip, correct settings, and compatibility between handset and reader — and each of those conditions removes a slice of your customers from the equation without your ever knowing who they were.
The comparison at the counter
Works for everybody
- Every phone with a camera reads it, without a single exception.
- Needs no hardware from you — a printed sheet is enough to enrol people.
- Works both ways: the customer scans your sign, or staff scan their phone.
- Slows a little in poor light or against a cracked screen.
Cost: a few riyals of printing, once.
Faster when it works
- About two seconds quicker, with no camera to aim.
- Unaffected by lighting or the state of the screen.
- Needs a reader on your side and a compatible handset on theirs.
- Sometimes fails silently, and silent failure is worse than slowness.
Cost: a reader at every payment point, plus setup.
Two seconds: are they worth it?
Calculate it rather than estimate it. A shop serving two hundred customers a day saves roughly seven minutes with two seconds each. That is a real figure, but a small one against the cost of a reader per till — and far smaller than the cost of one customer for whom the tap failed and who left without enrolling.
| Step | With a code | With a tap |
|---|---|---|
| Getting the phone out | 3 seconds | 3 seconds |
| Opening the wallet and the card | 4 seconds | 4 seconds |
| The action itself | 3 seconds | 1 second |
| Retrying after a failure | Rare | Not unusual |
The table exposes the fact that gets lost in the argument: most of the time does not go into scanning at all, but into getting the phone out and opening the wallet. Improving the third step alone improves a fraction of an experience that takes ten seconds either way.
If you want a real saving, work on the first two steps: a card the customer recognises by colour so they open it faster, and a code positioned where they see it while waiting so the phone is ready before they reach the till. That saves more than changing the technology does.
When tapping genuinely earns its place
Add tapping if…
- Your queue is consistently long and seconds really are counted.
- Your payment terminal already supports it.
- Your customers are daily regulars fully used to the card.
- You can keep the code working alongside it, without exception.
Do not if…
- You would be replacing the code rather than adding to it.
- It requires buying hardware for every payment point you have.
- Your programme is under six months old and has not settled.
- Your staff still get the card offer wrong in the first place.
The first entry on the right is the fundamental error. Tapping instead of a code means every customer with an incompatible handset or a disabled setting stands helpless at your counter. The code is the baseline that must never disappear, whatever you add on top of it.
The practical conclusion
Start with the code alone, and put what you would have spent on a reader into the code position, the number of copies, and what your staff say next to it. Those three factors move enrolment numbers by multiples of what two seconds at execution ever will.
Then, when the business grows and the queue becomes a genuine problem, add tapping on top of the code rather than in place of it. By that stage you know your numbers and can work out whether seven minutes a day justifies the hardware.
Common questions
Does the customer need special setup to use tapping?
They need an enabled NFC chip, the card added to their wallet, and settings that permit use at a reader — and all of those vary between handsets and system versions. The critical difference is that these conditions fail silently: the customer holds the phone near, nothing happens, and nobody knows why.
Is a QR code secure?
Security comes from what sits behind the code rather than from the code type. A static code pointing at an enrolment page is entirely safe because it carries no balance. Codes used to award stamps should be rotating or tied to a staff account — a requirement that applies equally to tapping.
What about a customer with no smartphone?
They fall outside both options, and that is a small and shrinking group that nonetheless exists. The simplest answer is for staff to look them up by phone number in the dashboard and award the stamp manually. Do not build your whole system around this case, but do not leave staff without an answer when it happens.