ProntoMenu

A menu that participates in service

ProntoMenu treats a digital menu as the start of a transaction rather than a PDF behind a QR code. A venue can present a branded menu, accept an order, route it into staff and kitchen workflows, collect payment, and manage the catalogue and service state from an administrative surface.

The platform is multi-tenant, so venue identity and catalogue data stay scoped to the business serving the guest. Optional language, allergen, and other catalogue details depend on the venue confirming the information it supplies.

• Branded QR-accessible menus.
• Ordering and table-service workflows.
• Payment and kitchen hand-off surfaces.
• Venue administration, catalogue, and operational reporting.

The server owns the price

A browser is useful for building a cart, but it is not a trustworthy authority for what should be charged. ProntoMenu rebuilds and validates payable totals on the server from venue-owned catalogue data before creating a payment.

That boundary protects against a stale page, a modified client request, and arithmetic differences between screens. The payment provider receives the total the server accepted, not an amount supplied as truth by the guest browser.

Operational and fiscal boundaries

Payment flows use Stripe. Fiscal receipt integration is isolated behind explicit production and business gates because issuing a legally meaningful receipt is not the same as rendering a success page. The live configuration for a venue must be verified before that path is enabled.

ProntoMenu states that a menu can be prepared and live within a day and that there is no monthly fee. Transaction terms, hardware needs, and the exact operational setup belong to the venue conversation rather than being hidden behind a generic “free” claim.