Three taps while the queue moves — the change conversation, the tap, the SMS. Here is the whole flow, including what happens offline and how cash-up balances at the end of the shift.
The ask is the default path — a scripted line on the till screen, not a policy your cashiers have to remember.
The card and QR are identifiers only — the value lives safely in the ledger, never on the plastic.
Sent under your shop’s name, with a link to their credit. Works when data is down; queued tills send themselves.
A worked example: on a $1.50 bill paid with a $10 note, the till puts $3.50 on the customer’s card and hands back a $5 note. Everyone’s square.
The till screen shows the exact line — “Shall I put your 70 cents on your store credit?” — with the amount pre-filled from the sale. Cashiers say yes-or-no questions, not policies. Declining is one tap and the change is given in cash as normal.
A new customer is a phone number on a big keypad — that is all. They get an SMS with their credit and a link to see it. No forms, no sign-up desk, no queue held up.
A phone number is enough to RECEIVE change — you can’t steal by giving. SPENDING credit needs the customer’s card tapped or the rotating code on their phone scanned. This asymmetry is the whole security model, and your staff never have to think about it.
When data drops, the till carries on: transactions queue on the device and send themselves when the signal returns. The customer’s pay code is generated on their own phone, so it works with no network on either side.
Credit given stays in the drawer, so the drawer must be over by exactly change-loaded minus credit-redeemed. Your dashboard shows that expected overage per till, per shift, per device — and every redemption prints an R-code checked against the POS discount total.