SnapScan and Zapper payments at a South African till
How a South African shop records SnapScan and Zapper payments at Achekam's till, where they land in the books, and how to check them at day end.
By Achekam · · 4 min read · For Running a business businesses in South Africa
South African shoppers have taken to paying by phone. At a coffee shop in Stellenbosch, a farm stall outside Pretoria or a market stand in Durban, the QR sticker for SnapScan or Zapper sits beside the card machine, and plenty of customers reach for their phone first.
For the shop, those payments are convenient and cheap to accept, but they arrive through a separate app with its own transaction list and its own settlement to your bank. This article explains how to record them at Achekam's till and how to make sure, at the end of each day, that what the till says matches what the apps say.
The till is not connected to either service
Achekam's till has no connection to SnapScan or Zapper. It does not show their QR codes, does not receive their payment notifications and does not know when a customer has paid. The till does not drive any payment hardware at all, from card terminals to receipt printers and cash drawers.
So the sequence is manual on purpose:
- Ring up the sale on the till as normal.
- The customer scans your SnapScan or Zapper code and pays the till's total in their app.
- The cashier checks the payment has arrived, on the merchant app or device your business uses for that service.
- The cashier records the payment at the till, choosing SnapScan or Zapper, with a reference.
Step three is the control. A customer showing a "paid" screen on their own phone has not proved anything to your business. Only your own merchant view of the payment counts.
Recording the payment with its reference
The reference is what ties the till sale to the app's transaction. Use the transaction reference or ID the service shows for the payment on your merchant side, not a name or "paid by phone".
Agree the format with all cashiers and keep it consistent, because you will need to find these references again at day end. If a customer pays part by app and part by card or cash, record each part as its own payment with its own reference. The till receipt, a PDF the server makes from the posted sale, shows every payment on it, so the customer's slip and your records tell the same story.
Card payments work in a similar way: the till is not connected to any card machine, so card payments are recorded by the cashier from the terminal's slip. If your staff already do that well, SnapScan and Zapper follow the same habit. The card side is covered in card slips when the till has no terminal link.
Where these payments land in the ledger
Every till sale that reaches the server posts a balanced journal in the same step: revenue, output VAT, and cost of sales against inventory at the product's cost price. Each payment method goes to its own account. In the standard chart those are cash (1050), card and QR (1060), EFT (1000), and a clearing account for each online gateway.
Keeping app payments out of the cash account is the point. When SnapScan or Zapper settle to your bank, net of their fees, the settlement can be matched against the account the payments were recorded in, and anything that never settled stands out.
A gateway QR pay page as the connected alternative
If you would rather have the till confirm phone payments itself, there is a different route. A customer can pay at the till by scanning a QR code for a pay page of a payment gateway the business has set up, and the payment counts only after the server has confirmed it with the gateway. For a rand till, the gateways on offer are PayFast, Ozow, Peach, Stripe, Paystack and Flutterwave, each available once the business has set it up and switched it on.
That route removes the manual check at step three, because the server does the confirming. The trade-off is that it uses your gateway account rather than SnapScan or Zapper, which some customers prefer. Many shops keep both. The way a front desk handles gateway QR payments is described in QR payments at the front desk.
Checking app payments against the X and Z reports
During the day, a live X report of an open till can be opened as a PDF; at cash-up, the Z report is frozen. These are the reports to check the app payments against.
At day end, for each service:
- export or view the day's transactions in the SnapScan or Zapper merchant view;
- compare that total with the SnapScan or Zapper payments recorded on each till's Z report;
- for any difference, match transaction by transaction using the references the cashiers recorded.
Typical causes of a difference are a payment recorded under the wrong method, a payment recorded twice, or a customer who paid in the app after the sale had already been settled another way. Each one is easier to sort out the same evening than at month end. ACCA's overview of internal controls explains the control environment, the types of control and segregation of duties behind checks like this one.
Closing the business day
A branch's business day is closed by a supervisor or manager who was not a cashier that day. Closing freezes its Z reports, the payments, VAT by rate and any differences.
That separation is what gives the day-end check its value. The person who closes the day should be the one who compares the app totals with the Z reports, and should not close it until every difference is explained. Cash has its own routine, covered in cash-up differences at the till.
Tonight, before the day is closed, pull up the SnapScan and Zapper totals and put them side by side with the Z report. If they agree, you have a routine. If not, you have found the first thing to fix.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
