Ordering and fulfillment rules

Open Settings → Orders and Fulfillment. These rules affect customer eligibility, beyond the visual Website editor.

Separate POS contacts from delivery eligibility

POS methods under Settings → Fulfillment → Point of sale may ask for optional name/phone details for the whole check. They collect no address, create no account and do not relax online delivery requirements. Per-item labels describe preparation exceptions. All saved orders remain available on POS and Admin, subject to access and filters; there is no per-method tracking switch. See method settings. Mode selection and any customer prompt precede items in a new onsite sale. The table/check is chosen only at Send/Continue; cancellation preserves the source. See whole-check fulfillment. Private guest context is staff-only, never a public checkout answer or notification variable.

Separate cash eligibility from cash collection

Order-channel or fulfillment settings may allow a customer to choose cash or pay later, but that choice does not prove payment and does not add money to the POS cash drawer. A staff member records a cash sale only after collecting the money on an enrolled POS with an open drawer session. Review the order's payment status separately from fulfillment; the Verifone card batch is not part of this drawer.

Review the by-weight authorization ceiling

For online by-weight orders, open Settings → Payments & VAT with settings.edit. Set Weight hold buffer % from 0 to 100 and save; the default for new restaurants is 20. A failed save keeps the draft. Zero still authorizes the estimate. Only the weight-priced subtotal gets a margin: 100 weighted + 50 fixed at 20% authorizes 170; delivery has no extra margin. Checkout shows the estimate, temporary ceiling and Confirm and authorize, in the restaurant theme. A changed ceiling requires customer review and another confirmation before payment; unknown policy blocks authorization. Existing reviewed checkouts and holds keep their ceiling. Staff confirm measured weights before capture and progression; excess beyond the hold is flagged for a separate payment, never automatically charged. Cash/pay-later makes no hold promise. Requires a configured authorize/capture provider, with partial capture, release and expiry validated before production. This neither changes the catering deposit/balance policy nor enables new-card saving with a CST weighted hold.

Choose ordering channels

Review enabled pickup, delivery and table modes and their minimums, fees and preparation settings. Change one rule at a time and inspect its customer-facing explanation. Public ordering can be paused independently of restaurant opening hours.

Set scheduling limits

Review immediate versus scheduled ordering, lead time, booking horizon and time-slot settings. Batch preorder cutoffs and delivery-tour dates have separate configuration. Verify that an offered slot satisfies all applicable rules. For ordinary delivery with a zone calendar, set hours in the Delivery tab and slot duration here; the zone supplies only covered weekdays, booking mode and fee. Basket preparation, its clock and closures filter these slots. Legacy zone hours no longer apply to new bookings; saved orders retain their promise. With compatible versions, delivery same-day days, transport and time confirmation are configured inside each zone. Restaurant hours and product preparation remain mandatory. Scheduled orders can include today. Staff can test saved basket/address calendars in Orders & availability → Simulate an order; this creates no order or message.

Use temporary test access carefully

Temporary test access requires a specific public IP and expiry within seven days. Activation pauses public ordering. Tests create real orders and notifications; use development for test data. Expiry or revocation leaves ordering paused: resume explicitly when ready. Never publish an allowed IP list in a guide or message.

Choose a stage attachment

In Admin, open Settings → Restaurant → Order workflow and the required pickup or delivery stage. With Notify customer enabled, choose the message type, an approved Meta photo/PDF model and its attachment: a fixed file, or that order’s receipt for a PDF. Choose the sending time and save the workflow. Manual stage entry or its configured event uses this binding. Selecting a file changes neither progression, payment rules nor delivery eligibility. Correct an incompatible or missing model/file before relying on delivery. The model library and creation controls are in Settings → Communications → WhatsApp.

Follow an assigned delivery’s departure

When the assigned courier starts their route in Admin, unfinished accepted, preparing and ready delivery orders change together to Out for delivery. Staff screens receive the updated statuses through their usual order refresh. This confirms actual departure; assigning a courier or choosing a fulfillment mode alone does not start a route. Held kitchen courses and unsettled weight orders must be resolved first. If starting fails, the previous statuses remain. The route action does not reopen finished or cancelled orders.

Make a one-order combo exception

For a one-order combo exception, an authorized Admin user opens the combo step and selects Choose another item. The replacement is included without a surcharge and is saved on that order only. Fulfillment, scheduling and delivery rules remain unchanged. Review the selected dish and portion in the order details. Guest and POS combo pickers retain the configured composition; arrange an exception through the internal Admin order editor. See the combo guide for quantities, eligibility and recovery.

Wait for counter card payment before kitchen preparation

For a new counter pickup order paid by card, choose Pay, then Pay by card. Wait for terminal approval and for Foody to record the payment before preparation and the kitchen ticket start. During collection the payment remains pending and is excluded from the live order board. After a refusal or cancellation, keep the same checkout and retry there; do not send it to the kitchen to bypass payment. If approval succeeded but synchronization failed, reconcile the existing payment before starting another charge. Orders deliberately sent for table service before collection keep their existing send-then-pay flow.

Move a reservation between series

Predefined item stocks now have a journal under Items & menus → Stock history and on each product. A rotating carte can prepare initial allowances per series and publish them without restoring already committed units. Previous remaining counts are not carried forward. Order changes and pre-production releases use the original frozen pool; a produced item remains consumed. Ingredient/preparation quantities and recipe costs remain separate. See Availability for initial imports, corrections and history filters.

Access the new controls

The entry sign-in invitation is now a published website order-journey preference. Order without an account remains available; this setting does not replace mandatory phone verification or payment/delivery validation. Google/Geoapify consumption and limits are separately available in Usage and quotas.

Staff contact details and courier destination

Staff contact details are managed in Admin → Staff → employee → Edit contact details. The restaurant-scoped name and phone are used for courier assignment and upcoming delivery reminders; the sign-in email remains read-only. Couriers can save a default final destination or link it to their home address. New routes propose that destination and allow an explicit override or removal. It is the courier’s end-of-route destination, separate from the customer’s delivery address. Existing populated routes and completed delivery snapshots keep their saved data. See staff profiles for saving, permissions and recovery.

POS code at staff activation

Staff activation checks the permissions assigned in this restaurant, including custom roles: orders.manage or payments.manage requires a private POS code. Read-only couriers and kitchen-only roles do not need one. Existing unused invitation links apply the same current rule. Changing a role label, courier address or route destination does not grant POS permissions. See activation and recovery.

Recover a delivery after a test departure

Starting courier mode marks assigned orders Out for delivery. If this was a test departure, a user with order-management permission can open Orders → Deliveries, select the date and choose Undo departure while no arrival, delivery or skipped stop has been recorded. Out for delivery orders return to In preparation; the route returns to draft and can be unassigned and reallocated. This is a delivery correction, not a new order, refund or reprint. Payments and previously sent messages are preserved. See the dispatch procedure.

Check conditional item choices

An item configured with repeated positions requires one separate choice per position according to the selected format. For example, a two-character Number Cake accepts 11, AB or A7. The format price replaces the base price; modifiers add only their configured surcharges. Reducing the position count removes newly hidden choices. Positions remain distinct in the cart, orders and kitchen ticket; review them before confirming. These customizations do not change delivery, availability, recipe, discount or cancellation rules. Configuration requires compatible versions and menu editing permission. See Variants and sizes for setup and recovery after a rejected selection.

Synchronize the POS mode policy

Fulfillment methods belong to the restaurant; prompt timing and enabled modules follow the effective policy of the device’s assigned mode. The updated POS refreshes it automatically and waits for safe completion of an active payment, send or item edit before applying it. Refresh never repeats an operation. In Admin, a conflict retains the draft but requires reloading saved settings before a new edit. When the method prompt is disabled and Onsite is the default, a new sale stays onsite; Send asks for its table or permitted named check rather than converting it to Takeaway. Delivery, availability and payment settings retain their own validation. See settings and recovery.

Check POS customer-screen compatibility

Show customer information screen still controls whether details are offered immediately after a fulfillment method is selected. Its internal guest identifier and note also require an API supporting private guest details. A compatibility rejection confirms neither a kitchen send nor a payment: retain the current sale and have the API updated before resuming. Enabling the screen does not change available methods, their order, table selection at Send, delivery rules or printer profiles.

Open the current weekly batch automatically

For a restaurant configured for weekly batches, open Home or Orders using the Série date basis. The current batch is selected by default even without orders; its totals then stay at zero. It advances after the previous batch’s final fulfillment day in the restaurant timezone, without waiting for the first order or for ordering to open. An open page follows this change on the next automatic refresh (about one minute) or when you return to the tab.

You can select an older service in the calendar; that selection stays in place while the page is open. An order for a later week does not replace the current batch as the default. A payment-attention link keeps its explicit period. If the date looks incorrect, check the configured fulfillment days and restaurant timezone, then reload. Rollover does not create an order or publish a menu.

Control weekly ordering manually

In Admin → Settings → Ordering & delivery → Orders & availability → Weekly batch, use settings.edit to choose Manual opening or According to a calendar, then Save changes. Manual opening keeps the current pause state; it never opens ordering merely by selecting the mode. Use Pause online orders → No to open, or Yes to pause. There is no automatic opening, cutoff or scheduled reopening in manual mode. Delivery/collection days and windows, preparation rules, stock and existing orders remain unchanged. New orders target the current delivery series even after the previous calendar cutoff, until its final service day ends in the restaurant timezone. Check the offered delivery date before confirming. Returning to calendar mode restores the retained hours. If saving fails, keep the draft and reload the confirmed status before retrying. Disable active Temporary test access before reopening publicly; expiry or disabling it alone leaves orders paused. Deploy the compatible API before enabling this choice; an older API leaves it unavailable.

Separate current settings from recorded progress

Mode and workflow settings determine the actions available for new operations; they do not reconstruct an old order’s history. Review preparation, handoff and payment separately. Unknown information is neither confirmed handoff nor proof that payment is due. Retry an unavailable read before starting another financial operation. See check, payment, preparation and handoff.

Prepared Sumit checkout integration

For a compatible internal Sumit basket link, the recipient’s delivery address is checked against the restaurant’s current zone, fee and minimum. The chosen service date is retained and must fit any matched zone calendar. The final total is reviewed before payment. See Sumit checkout.

Use cash with an optional card guarantee

In Admin → Settings → Payments, with settings.edit permission, select Allow other methods to accept cash. For a compatible provider, Cash payments offers Accept cash from all customers: Yes allows every customer regardless of trust status; No disables cash for everyone. Require a card guarantee for cash remains independent: enable it only when you want to reserve 100% of the total on the card, then save and verify the values. The guarantee is off by default. It is currently available for configured Stancer in EUR; other integrations use the same presentation when their cash-guarantee flow is supported. Unsupported providers retain their existing cash settings without this guarantee. A previous trusted-customer-only policy is preserved until you explicitly choose Yes or No; changing VAT or tips does not replace it. Online-payment-only always excludes cash. Before real use of the guarantee, verify cancellation of an authorized sandbox reservation, release timing and fees with your Stancer account.

Acceptance and recovery: cash card guarantees. Review the optional Same-day delivery block in Delivery zones separately from the standard slot/batch settings. It limits only new bookings for today in the restaurant timezone; future bookings keep their zone rules. Today’s restaurant-confirmed estimate adds transport to product readiness inside delivery hours, and does not replace weekly-batch windows. Custom slot hours still override service hours. Never disable every delivery zone to pause ordering: use the service or pause control.

Review independent confirmations

POS fulfillment methods provide separate preparation and handoff tracking. Save the method’s policy in the global catalog. It applies to new sales and remains frozen with them; later changes do not rewrite history. Shared device-mode modules remain distinct from this global policy. See tracking settings.

Test when an order is placed

In Orders & availability → Simulate an order, select Order date and time in the displayed timezone, then the receiving date and basket. Now reloads the server time. Preparation and same-day rules are evaluated at this reference using current saved settings and ready stock. A past date does not reconstruct history; this test neither reserves a courier nor creates an order. Customer orders retain the real server clock. See the simulation procedure.