A point-of-sale screen needs to feel immediate. That is why it previews prices in the browser. But a preview should never be the authority for what a customer owes.
In OrderRestro, the client mirrors the pricing calculation so the cashier can see a responsive total. When the order is submitted, the server recalculates the amount using trusted menu and order data. Tax, discounts, and rounding are handled on that authoritative path.
This split is useful well beyond POS software: let the interface help the user understand what will happen, then validate again at the boundary that persists money or permissions. If the server accepts a total supplied by the browser, anyone can modify the request and change the amount without changing the UI.
A simple review exercise is to alter the submitted total in a test request. The server should either ignore the client’s total and derive its own, or reject the mismatch. Then test the real edge cases: inclusive tax, flat and percentage discounts, refunds, and currency rounding. Every path should agree on the same amount.
The client-side preview is still valuable. It reduces friction for staff and makes the cart feel fast. It just does not get the final word.
OrderRestro’s pricing and architecture notes are in the public repository. I share more about practical software decisions on RaktimRanjit.com.
Top comments (0)