Why ProntoMenu prices the cart on the server

A QR menu becomes financial software quickly

A static menu is mostly a publishing problem. The moment a guest can choose a modifier, send an order, or pay, the same screen becomes part of a financial system. The visible total matters, but it cannot be the authority just because the arithmetic happened in the browser.

In ProntoMenu, the client is allowed to describe intent: these items, these quantities, these options. The server reloads the venue-owned catalogue, validates that the selections are available, applies the pricing rules, and produces the payable amount. The payment provider receives that server-approved total.

Never accept your own total back as truth

It is tempting to calculate a polished cart total in the browser and post that number to checkout. But a request can be changed, a page can remain open after a price update, and two implementations can round a value differently. None of those cases should decide what a venue charges.

The browser total is a preview for the guest. The server total is the decision. If the two disagree, the product should stop, explain that something changed, and let the guest review the corrected cart instead of silently charging either version.

• The request carries product and option identifiers, not trusted prices.
• Every identifier is resolved inside the active venue tenant.
• The server validates availability and permitted combinations.
• Money stays in integer minor units through the calculation.
• The accepted total is the one passed to the payment provider.

Tenant boundaries are part of pricing

ProntoMenu serves multiple hospitality businesses. An item identifier without a venue boundary is therefore incomplete. A valid item from venue A must not become purchasable in venue B because someone combined values from two browser sessions.

The pricing query is scoped to the venue that owns the ordering session. The same rule applies to menus, tables, staff views, kitchen state, and reporting: an authenticated or public identifier is only meaningful inside its tenant.

This is not glamorous work, but it is what makes a platform different from a collection of good-looking menu pages.

Payment success is not the receipt boundary

A payment-provider redirect can tell the browser that a checkout flow returned successfully. It is not, by itself, enough evidence to fulfil an order or issue a fiscal document. Server-to-server payment events, idempotent order state, and explicit business configuration have to agree.

ProntoMenu keeps fiscal integration behind production and venue gates. The code can support that path without pretending every demo tenant is legally configured to issue receipts. A receipt number is not decorative copy; it has accounting consequences and belongs behind an auditable state transition.

The general rule I kept

Put responsive previews in the browser and business truth on the server. Let the menu feel immediate, but recompute the consequential state at the boundary that owns the catalogue, tenant, payment credentials, and order lifecycle.

That approach costs an extra validation step. It also means a stale tab or edited request becomes an ordinary error to handle rather than a way to change a price.