Prices calculated on the server: the defense against a manipulated ticket

A hotel controller reviews a shift close and finds something that does not add up: a dish that costs 180 on the menu shows up charged at 90 on a ticket, with no note of a comp or an authorized discount. Nobody confesses. The server says the tablet showed that price. The right question is not who lied: it is where that number was calculated, because that is where the real problem starts.

Two ways to calculate a price, and only one is safe

There are two ways to build the final total of a ticket in a hotel restaurant. The first is that the server’s tablet keeps a copy of the menu, calculates the subtotal, applies tax and discounts, and sends the server the already-computed result: “this ticket costs 540”. The second is that the tablet only sends what was ordered, each item by its identifier, and the server is the one that looks up the current price, applies tax, checks for any valid discount and calculates the total from scratch.

The difference between the two sounds technical, but it has a direct consequence for the security of your hotel restaurant: in the first way, anyone who can tamper with the app, the network traffic or even install a modified version on a device can change the final number before it reaches the server. In the second way, that number never leaves the server: it computes it itself, with its own copy of the menu, and does not care what the tablet claims the total should be.

Why calculating on the tablet opens the door to manipulation

A tablet is a physical device that lives in the restaurant, sometimes unsupervised for hours, especially on night shifts or at remote revenue centers like the pool bar. If the final price is calculated there, several ways to tamper with it exist: intercepting and altering the request before it goes out to the server, running a modified app that changes the numbers before showing them, or simply exploiting an app bug that allows editing a field that should never be editable.

None of these require an expert. It only takes someone who knows the price can be touched and has physical access to the device long enough. And in a hotel restaurant, with staff turnover and shifts that change hands several times a day, that eventual physical access is practically guaranteed.

How server-side calculation works, step by step

1. The tablet sends only what was ordered: each item’s identifier and quantity, never a price.
2. The server looks up the current price for each item in its own catalog, the same one that feeds the digital menu and the one the manager administers.
3. The server checks whether any discount or comp applies, and only accepts ones authorized by someone with the matching permission, verified on the server itself.
4. The server calculates tax according to the property’s fiscal configuration, not according to whatever the tablet assumes.
5. The server builds the final total and sends it back to the tablet already computed, for the server to show the guest.
6. That same server-computed total is what travels to the guest folio when the charge posts to the room, so the restaurant and the front desk always see the same number.

With this design, it does not matter what the tablet says, which app version it runs, or whether someone tried to intercept the network traffic: the price that ends up on the ticket and on the folio is always the one the server calculated from its own catalog, at the moment of the order.

Who can change a price, and how it gets recorded

Calculating price on the server does not mean it can never change: it means it only changes when someone with the right permission authorizes it, and that change is recorded with a name, a time and a reason. A manager applying a comp, a supervisor authorizing a discount for a guest complaint, or a seasonal catalog price adjustment are all legitimate changes, but all of them must go through the same path: an authorized action on the server, never a silent edit on the server’s screen.

The question you should be able to answer at any moment is: who changed this price, when and with what justification? If the answer is “we don’t know, the tablet showed that number”, the system is not calculating the price in the right place.

How a manipulation attempt gets detected

A system that calculates prices on the server can also actively watch for manipulation attempts, because every request coming from the tablet carries information the server can compare against what it itself expected to receive.

• If the tablet sends a total different from what the server calculates with its own catalog, that mismatch gets logged as an alert, even though the server always uses its own number.
• If one device generates many mismatches in a short time, the pattern shows up clearly in the security report instead of hiding in the noise of normal operations.
• If someone tries to apply a discount without the matching permission, the server rejects it and logs the attempt, including who was authenticated at that moment.
• If a dish is submitted with an identifier that does not exist in the current catalog, the server rejects it instead of accepting whatever price the tablet proposes.

An illustrative example of the cost of calculating on the tablet

The figures below are made up to show the calculation; they do not describe any real property. Picture a hotel restaurant with 90 tickets a day where, because the system trusts whatever price the tablet sends, an employee manages to apply an unauthorized discount on one in every thirty tickets.

In the example, 8,100 a month is money the restaurant never collected, and no sales report will ever flag it as missing, because from the system’s point of view every ticket closed at its correct amount. With the price calculated on the server, that same unauthorized discount simply does not exist: the request arrives, the server calculates the real catalog price, and if nobody authorized a discount, the ticket closes at 180, not 90.

The connection to room charge

This problem gets more serious in a hotel restaurant because the ticket is not always paid in cash or by card on the spot: it often posts to the guest folio, and that folio ends up on the statement the front desk hands over at check-out. If the price could be manipulated on the tablet, the error or the fraud does not stay in the restaurant: it travels all the way to the guest folio, and from there into the hotel’s accounting, without anyone noticing until someone runs a manual audit.

What to do this week

1. Ask your current vendor where the final ticket price is calculated: on the tablet or on the server.
2. Ask for a mismatch report between what the tablet sends and what the server calculates, if your system has one.
3. Check with your controller whether the last shift close had tickets with discounts missing the matching authorization record.
4. Verify who on your team has permission to apply discounts and confirm that permission is validated on the server, not only on screen.
5. If your current system cannot explain who changed a price and why, add it to the list of risks your next vendor evaluation needs to resolve.

Inn Restaurant calculates every price on the server from the property’s current catalog, no exceptions, and logs any discount with who authorized it and why. You can check how it works on the security page (Security and control) or watch it live in a 15-minute demo (contact).