The till renders a total. It does not choose one
A point of sale that trusts the total its screen sends is fine until a discount means money owed to somebody else. Our till now asks for a sale to exist, and the server says what it costs — the rule the web checkout has always followed.
· 3 min read

Web checkouts learned a long time ago not to trust the browser. A shopper’s basket arrives at the server as a list of products, and the server looks up what they cost. A price that arrives from the page is a suggestion at best, because anybody can change what a page sends.
Points of sale often never learned it, because the till is "ours": it runs in the shop, operated by staff. Rutba’s was one of them. The totals on a sale were whatever the till’s screen sent — and that total decided whether the stock was marked sold, whether the sale completed, and what reached the revenue account.
Tolerable, until a discount costs somebody else money
While a discount only cost the shop its own margin, a till that chose its own totals was a risk the shop carried itself. It stops being tolerable the moment a discount also creates money owed to somebody outside the business — which is exactly what a promoter’s code does in an affiliate programme. A total a screen can choose is then a payable a screen can create.
So this changed before a single coupon was designed around it. The web path already had it right; the till now has the same thing, in the same vocabulary, so a discount means one thing on a receipt and on a web invoice.
You may ask for a sale to exist. You may not say what it costs.
Three layers, from hardest to get round
- The money fields cannot be written by the till. Subtotal, discount, tax, total and every line’s price are removed from anything the screen sends. They are stripped rather than rejected, so every existing screen kept working on the day it shipped — it simply stopped being the authority.
- The server prices the sale from its own records. The till says which offer applies and what discount was asked for, and why. It never sends an amount.
- Checkout prices again before taking money, so a sale that was never priced cannot settle on a stale figure.
The price of the unit, not the product
One detail is particular to a till. A line on a till receipt is a set of specific units — the actual items scanned — and two units of the same product can carry different prices, because they came in on different deliveries. So the price is read from each unit, which is only possible because one system owns the stock record the till scans against.
A pay-later sale is priced once, and then left alone
When a customer takes goods on account, the sale is priced at the moment it is locked, because that is when the price stops being negotiable. After that it is never re-priced. Moving the amount of a debt after the goods have left the shop would be indefensible, whatever changed in the price list meanwhile.
Rutba Commerce
One catalogue behind the storefront and the till, with stock deducted live.
See the productIn this post
- Rutba CommerceSell online and over the counter, from one catalog
- Inside Point of SaleThe counter till — scan, sell, take payment, and print, with stock deducted live. — part of Rutba Commerce
- Inside StorefrontYour online shop — product pages, cart, and checkout, driven by the shared catalog. — part of Rutba Commerce


