Ordering Flow

Pre-requisite: Store is selected as part of store selection flow specific to order type (Dine in, Pre-order or Takeaway, Delivery, Foodspot

Pre-requisite: Menu specific to store and order type is loaded (MenuQL Guidelines)

The ordering flow starts once the Order Type, Store and Menu have been selected and fetched.

Changing the order type

The customer can still change their order type after the Store and Menu have already been selected.

If the order type is changed, another menu specific to the order type selected should be fetched.

If the order type is not supported by the store selected and there is no menu associated with the order type - the store selection process should be restarted.

Step 1: Order Type specific setup

Delivery Order

To fetch the available delivery times, the Delivery Times endpoint is called. The request should contain the delivery location latitude and longitude and the singular point id (which can be found in venues call, areas object)

POST api/delivery/delivery-times

API Spec: [Delivery Times]

The endpoint returns a collection of delivery times in the following format: "YYYY-MM-dd hh:mm:ss"

Once the customer changes their delivery time or location a store search should be initiated to identify stores delivering to the new location and matching the delivery hours [Delivery Store Selection]

For Dispatch integrated stores

If the customer changes their delivery time or delivery address, an additipnal call is made to [Delivery Quote] to check the deliverability to the selected location and the Estimated Delivery Time.

Takeout

To fetch the available pickup times, the Pikcup Times endpoint is called. The request should contain the singular point id (which can be found in venues call, areas object)

POST api/orders/pickup-times

API Spec: [Pickup Times]

The endpoint returns a collection of pickup times in the following format: "YYYY-MM-dd hh:mm:ss"

Curbside

Curbside Order pickup is specific for the customer vehicle.

To populate vehicle details:

POST api/customer-accounts/{customer-accounts-id}/vehicles API Spec: Add Vehicle

To fetch previously used vehicles:

GET api/customer-accounts/{customer-accounts-id}/vehicles API Spec: Fetch Vehicles

To remove the vehicle:

DELETE api/customer-accounts/{customer-accounts-id}/vehicles/{vehicle-id} API Spec: Remove vehicle

Step 2: Adding and modifying items in cart

The cart in Menu Ordering APIs is an abstract concept, and is being stored on frontend side up until the order creation.

Every card modification, including adding, removing or editting items, modifiers, combos, and also any discount modifications is a subject to recalculate the current card:

POST /api/orders/calculate

API Spec: [Calculate]

It is recommended to call the endpoint with the "calculate_accurate_tax": true only for the final calculation before checkout to avoid the POS system overload. For all the other calls "calculate_accurate_tax": false can be used

---

Every card modification also modifies the Cross Selling items. The cross-selling items can be fetched based on the current cart state:

POST /api/venues/{venue_id}/menus/{menu_id}/cross-sellings

API Spec: [Cross Sellings]

Related Article: How to setup Cross-selling?

Step 3: Check Items Availability

If the ordering process takes time, it's important to check that the items are still available for ordering.

POST /api/orders/check-item-availability

API Spec: [Item Availability]

The request should contain the singular point id, order type and the array or menu item ids.

The response contains the array of unavailable menu items.

Once the response is received the cart can be updated to display the items that have become unavailable to the customer.

Step 4: Payment Flow

Once the customer is ready to checkout they are redirected to payment flow. The implementation is specific to the Payment processor. The full payment flow can be found in the [Payment section].