The whole redemption is four taps
Find the customer's card, read the reward counter, tap Redeem reward, hand over the item. That is the entire flow, and it runs on a phone your cashier already owns. It takes about ten seconds, and the customer installs nothing to make it work.
There are two ways to find the card. Either the customer opens their pass in Apple Wallet or Google Wallet and you scan its QR code from the dashboard, or you type their mobile number: the field is a fixed 05 prefix plus the remaining 8 digits, so it's 8 taps and no keyboard hunting. If that number has cards on two of your programs, you pick the right card before anything else happens.
Waya has no POS integration and no hardware, and that shapes the moment. Your cashier rings up the sale on the till exactly as before, and the redemption is a separate ten-second action beside it. The upside of not being wired into the till is that a card reader outage never blocks a reward.
Confirming the reward before you give anything away
A reward is redeemable only when the card's reward counter reads at least 1. Below that, the Redeem reward button is disabled, and if you push it anyway you get "Customer has not reached the reward yet." Eligibility is never the cashier's judgment call, which is the point.
The counter fills on its own. On a card set to 10 stamps, the eleventh stamp does not overflow into nothing: the reward counter goes up by 1 and the stamp count resets to the remainder. Fourteen stamps in one busy week leaves 1 reward waiting and 4 stamps carried into the next cycle. Points cards behave the same way against the points threshold you set.
This is why the reward count and the stamp count are two separate numbers on the card. A customer can keep collecting while an unclaimed reward sits there, and the scan screen tells you plainly how many are waiting: "2 rewards ready to redeem". Nobody has to remember whether last Thursday's free coffee was already taken.
The double-redeem guard, and what it does not cover
Three things stop one reward from being spent twice. The buttons on the scan screen go inert while a request is in flight, so the classic panicked double-tap can't fire two requests. That handles the most common case, at the counter, before the network is even involved.
The second layer is the request ID. Every redemption carries a unique ID, and the activity log holds a uniqueness constraint on it per shop. If the same instruction reaches the server twice — a flaky mall Wi-Fi connection where the write landed but the response was lost — the server replies with the earlier result instead of spending a second reward.
The third layer is a compare-and-set write. The server only sets the counter from 1 to 0 if the counter is still 1 at the moment of writing. Picture two cashiers on two phones scanning the same card in the same second: one sees "Reward redeemed", the other gets refused with "No rewards to redeem", and only one free coffee leaves the shop. If the value moved for an unrelated reason, the server re-reads and retries up to three times before giving up.
What none of this covers is a cashier who taps Redeem twice on purpose, seconds apart, on a card holding 2 rewards. That spends both, because it is two real instructions rather than one instruction delivered twice. Deliberate over-giving is a staffing question, and the per-branch numbers in your dashboard are where you'd catch it.
Settling a disputed balance while the customer watches
Most disputes are a missed stamp, not a stolen one. The scan screen shows the current count, the reward count, and the last visit timestamp down to the minute, so "I came in on Tuesday" is checkable in front of the customer. The customer profile adds total visits and a strip of recent visits if you need more than that.
If a stamp really is missing, add it. Plus Stamp adds one stamp per tap, and each tap writes its own log row with a timestamp and the branch it happened at. That log is what settles the same argument the next time it comes up.
If a redemption fires by mistake, there is no undo button. Being straight about it: the repair is to re-earn the reward, so on a 10-stamp card you add 10 stamps and the reward comes back with the carried-over remainder untouched. Ten taps is tedious, and it is the honest state of the product today.
Taking things away is deliberately awkward. The minus button arms on the first tap and needs a second tap within 4 seconds, and deducting sits behind a separate staff permission from adding. So you can give a new cashier the ability to stamp and to redeem without the ability to wipe a regular's balance.
What the customer sees on their pass afterwards
The pass updates itself, with no app to open and nothing to refresh. The wallet update is queued in the same request that records the redemption, and the queue worker is kicked immediately rather than waiting for the next scheduled tick, so the numbers usually change while the customer is still standing at the counter.
On an Apple Wallet stamp pass, the header field labeled BALANCE is the reward count, and it drops from 1 to 0. If you turned on the numeric stamp counter, a STAMPS 7/10 field sits beside it. The reward line carries your own wording, and it shows a quantity prefix like "2 ×" when one completed card grants two units.
On a Google Wallet pass, the label reads STAMPS 4/10 above a row of filled and empty stamp marks, with a REWARDS count underneath. The progress line flips from the reward-is-ready message back to something like "You are 6 stamps away from your Free Coffee". Both wallets show your card design, in Arabic or English, whichever you built.
Those silent counter refreshes cost nothing against your message allowance. A lock-screen confirmation message is a separate, optional thing: it sends only if you wrote the message text for that trigger, it is capped by a 4-hour per-customer cooldown, and it counts against your monthly wallet-message allowance — 100 a month on the free plan, 5,000 on Growth at 85 SAR a month. No SMS is involved, and no phone number is handed to a third-party messaging app.
What the redemption leaves behind in your reports
Every redemption records which branch it happened at. A staff member locked to one branch stamps that branch automatically, while an owner picks the branch on the scan screen. One card can span multiple branches, and all the scans roll into one dashboard.
From there the dashboard counts redemptions per day and per day of the week, next to stamps, and breaks them down by branch and by card. Two things worth watching: which hours produce redemptions, so you don't put your slowest cashier on that shift, and any branch redeeming far more than it stamps.
A worked example, with the assumptions invented so you can replace them. Say 40 enrolled customers average one visit a week: that's roughly 160 stamps a month, so a 10-stamp card produces about 16 rewards a month if every card gets used. If your reward costs you 6 SAR in ingredients, that's about 96 SAR of reward cost against 0 SAR of software cost, since the free plan runs to 100 customers with no credit card. Put your own visit count and reward cost in before you decide anything.
Frequently asked questions
Can a customer redeem the same reward twice?
No. A redemption only goes through if the card's reward counter is at least 1, and the server decrements it with a compare-and-set write, so two devices scanning the same card in the same second produce exactly one redemption. The second device is refused with "No rewards to redeem". Retried network requests are also deduplicated by a request ID, so a lost response never costs you a second reward.
What if the cashier taps Redeem by mistake?
There is no undo button for a redemption today, so you restore it by re-earning it. On a card set to 10 stamps, tap Plus Stamp 10 times and the reward counter goes back up by 1 with the carried-over stamps intact, because earning works on the remainder. On a points card, add the reward threshold instead.
Do I need a POS integration or a scanner to redeem rewards?
No. Waya has no POS integration and needs no hardware: your cashier scans the customer's wallet pass with an ordinary phone, using the web dashboard or the Waya merchant iOS app. The till keeps working exactly as it does now, and Waya sits beside it rather than inside it.
How does the customer know the reward was used?
Their wallet pass updates itself within seconds of the redemption, with the reward count dropping and the progress line switching back to how many stamps remain until the next reward. That refresh is silent and free. A lock-screen text message is optional, only fires if you wrote the message for that trigger, and counts against your monthly wallet-message allowance.
Can a cashier redeem rewards without being able to remove points?
Yes. Adding stamps and redeeming rewards sit behind one staff permission, and deducting sits behind a separate one, so you can grant the first without the second. Deductions also require a second confirming tap within 4 seconds, which makes an accidental removal hard to trigger. Staff accounts are available from the Growth plan at 85 SAR a month.