An outside app opens a table's order, and the till takes the payment
The customer asks: Our reservations app seats a table and opens its order; guests order from a QR menu or a kiosk onto that order, and the till takes the payment
- Verdict: Ready, with limits (7)
- Door: Open check · area: Integrations, payments and hardware › Online shops and order systems
- Recipe: Open a table's order from your app (open check)
- Sample: none yet
- Checked: run by the product 2026-10-26 to 2026-10-28 (the door's first layer, through the API, 2026-10-26: an outside app's integration user opened a tab by its label and added to it, was refused a move and a close in the right's words, and read the check with no staff identity and no register; and POS train T19's walks on phone, counter and tablet: tables opened, two rounds added from two tills, the check claimed at Checkout and paid by card and cash, one line paid on each of two tills, Back giving the lines to the table, a pre-order tab paid, the close listing the open checks); not run by a kit sample
What you build
An app that calls the open check door (open_check/1, POS version 2.1.0.667 and later) through ivendnext_mpos.api.v1: floor_status reads the store's tables, check_open opens a table's check (or a tab or pre-order by its label), check_add_lines adds what the guest ordered, and check_preview shows the shop's price of the open lines. The check holds what was ordered, never a price: the till prices it and takes the payment when the table pays. Every write carries a fresh random key; a retry sends the same key and the same request. The calls, rights and refusals are on the open check page (contracts/pages/open_check.md).
Limits
- The retailer switches on Table Service on the POS Profile, sets up the floor (Floor Sections and Floor Places) in iVendNext Desk, and gives your app's user the store and one register there, first.
- Your app never pays, claims or prints a check: those calls are a till's only and refuse your app whatever it is granted.
- Ask only for open a check, add to a check and see the checks: sending to the kitchen, moving, merging, closing, voiding and comping are a person's decisions at the till.
- A line never carries a price, a discount or a server's note.
- Online only: a check needs a connection.
- A weighed line on an open check is refused at Pay until a later POS version.
- Which guest may see which check is your app's job: give each app its own user.
Tell the customer
Your guests' orders reach the table's check on every till at once; staff send each round to the kitchen from a till, and the cashier takes the payment as for any sale, with every promotion and tax.
What next
- Tell the customer the 7 limits above, and write them into the proposal.
- Follow the recipe: Open a table's order from your app (open check).
- Build and test it on your sandbox (request one if you have none; what is on it).
- Run the checks: your own tests, the kit's checks and the money kit's release gate (testing and release).
- Release through the customer's own release gate (14. Testing and release); an app other shops install goes through the App library.
Send every write twice with the same key: it is written once. Send that key again with other lines: it is refused.
Related needs
- Orders from our own web store come in; stock and prices go out — Ready, with limits (2)
- Click and collect — the store sees which web orders to pick and which customers are coming to collect — Ready, with limits (7)
- Our call centre takes orders by phone; each order should go to the store that serves the customer's district — Ready, with limits (7)
- Our order-management or warehouse system linked to the stores — Ready, with limits (2)
Start a project shortlist with this need · Put it in your blueprint · Every need