Page Comparison

Contents

Table of Contents

minLevel	1
maxLevel	4
outline	false
style	none
type	list
printable	true

...

Action

Tests

Vendor Action

Expected Result

Pricing Order

Info
Orders are priced at the checkout to confirm how much a user will be charged. Regardless of the pricing and availability information cached at the application level, the POS is queried one last time to provide the final answer for Pricing and Availability of the different cart products.

Authenticated user selects ordering for the corresponding store, adds items to cart and navigates to the checkout.

All Cart Structures must be tested:

Item
Item with modifiers
Combo
Combo with items with modifiers
Systemwide Offer Item
Systemwide Offer Combo
Systemwide Offer Combo with modifiers
Reward Item
Reward Combo
Reward Combo with modifiers
Promo Codes - Amount Discount
Promo Codes - Percentage Discount

Partner is subscribed to the Price Order webhook. The payload of the webhook includes the order contents for the selected store id and service mode.

Partner must return the price and availability for each item in the order, the total price and any errors using the Price Webhook Callback endpoint.

Error Handling to follow the message and code standards:

Message: include a clear error message, mentioning the PLUs responsible for the failure and the designated store. Do not include unhelpful information like Error occurred while processing request
Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

→ /cart page loads total price of the user cart, corresponding to the sum of all products within.

→ Loading time does not exceed 3 seconds for p99.

→ Tax, Subtotal, and Total are visible at checkout (as applicable according to local regulation).

→ [OPTIONAL] Fees, such as “Bag Fee”, are visible in the /cart page, separately from total cart amount.

Commit Order

Info
After a successful pricing and payment, the order needs to be acknowledge by and registered in the POS.

Authenticated user selects ordering for the corresponding store, builds a cart, navigates to the checkout and places (pays for) an order.

All Cart Structures must be tested in this category:

Item
Item w/ modifiers
Combo
Combo with items w/ modifiers
Systemwide Offer Item
Systemwide Offer Combo
Systemwide Offer Combo w/ modifiers
Promo Codes - Amount Discount
Promo Codes - Percentage Discount
Reward Item
Reward Combo
Reward Combo with modifier

Partner is subscribed to the Commit Order webhook. The payload of the webhook includes the order id, total order price and customer details.

The POS must respond to the webhook request by using the Commit Webhook callback endpoint.

Error Handling to follow the message and code standards:

Message: include a clear error message, mentioning the PLUs responsible for the failure and the designated store. Do not include unhelpful information like Error occurred while processing request
Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

→ Order is injected in the POS.

Note

Committing and order does not mean that the order should be prepared immediately.

In the Commit Order webhook payload we include the fireOrderInSeconds field which indicates when the order should be sent (or 'fired') to the kitchen for preparation. In some case the fire webhook will be needed to determine when the order should be fired.

This will vary by service mode and payment method – see tables below.

Cancel Order

→ Check whether the status has been changed to cancel

→ Check whether the automatic refund has been processed (if applicable)

→ Check whether the cancellation email was triggered

→ Check whether delivery has been cancelled (if applicable)

→ When the order is canceled in the POS the payment should be refunded.

Order firing for in-Restaurant Service Modes

Info

When we reference the Order Number from RBI, the following is expected:

RBI’s order number should substitute the POS order number in the receipt.
RBI’s order number is configurable, allowing numerical interval restriction and / or utilization of an alphanumerical prefix.

Info
You can find more details about the order firing mechanism here: https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5003083791/Order+API+-+Checkout#Fire-webhook-%26-endpoint

ActionTests

How to test

Vendor Action

Expected Result

Place a Dine In / Pickup

Immediate order (Now)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Dine In or Pick Up and order time Now.

Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN TAKEOUT ) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: 0 indicates the order should be fired to the kitchen immediately.

→ Order is injected in the POS.

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Note
Guests rely exclusively on this number to identify their online orders.

Place a Drive-Thru order

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Drive Thru. No time selection appears.

Partner collects the service mode (serviceMode) from the GET Order endpoint (DRIVE_THRU) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: null indicates the order should be held in the POS until the order is released.

→ Order is registered in the POS but not sent to the kitchen.

→ When the guest arrives at the restaurant, a team member manually fires the order to the kitchen.

At that point,

→ DSS ticket printed.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Place a Table Service order

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Table Service and inputs the desired table number. No time selection appears.

Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: 0 indicates the order should be fired to the kitchen immediately.

→ Order is injected in the POS with reference to the table number.

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the table number.

→ Receipt printed with order number from RBI, though at a less relevant place, since table number should take precedence to the order number.

Note
Crew members rely on an easy identification of the table number to identify where this order should be taken to.

Place a Curbside order

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects service mode and order time Now.

User inputs the car plate number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (CURBSIDE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: 0 indicates the order should be fired to the kitchen immediately.

→ Order is injected in the POS with reference to the table number.

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the car plate.

→ Receipt printed with order number from RBI, though at a less relevant place, since car plate should take precedence to the order number.

Note
Crew members rely on an easy identification of the car plate number to identify where this order should be taken to.

Place a Dine In / Pickup order

Future order (Scheduled)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Dine In or Pick Up and order time equivalent to any slot in the future.

Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN TAKEOUT DRIVE_THRU) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: X indicates the order should be fired to the kitchen X seconds after the order is placed.

→ Order is injected in the POS.

→ Order appears in the KDS X seconds after POS order injection.

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Note
Guests rely exclusively on this number to identify their online orders.

Place a Table Service order

Future order (Scheduled)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects table service and order time equivalent to any slot in the future.

User inputs the desired table number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: X indicates the order should be fired to the kitchen X seconds after the order is placed.

→ Order is injected in the POS with reference to the table number.

→ Order appears in the KDS X seconds after POS order injection.

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the table number.

→ Receipt printed with order number from RBI, though at a less relevant place, since table number should take precedence to the order number.

Note
Crew members rely on an easy identification of the table number to identify where this order should be taken to.

Place a Curbside order

Future order (Scheduled)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects service mode and order time equivalent to any slot in the future.

User inputs the car plate number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (CURBSIDE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

fireOrderInSeconds: X indicates the order should be fired to the kitchen X seconds after the order is placed.

→ Order is injected in the POS with reference to the table number.

→ Order appears in the KDS X seconds after POS order injection.

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the car plate.

→ Receipt printed with order number from RBI, though at a less relevant place, since car plate should take precedence to the order number.

Note
Crew members rely on an easy identification of the car plate number to identify where this order should be taken to.

Payment Methods for in-restaurant orders

Note
Applicable only to In-Restaurant orders.

ActionTests

How to test

Vendor Action

Expected Result

Place a Cash cash (or any other Unpaid unpaid) in-restaurant order

As per above.

Same process described in previous table for any service mode (Dine In, Pick Up, Table Service…).

User selects cash in the payment page.

Image Added

Partner collects the payment method from the GET Order endpoint (CASH or UNPAID) and injects in the appropriate POS field.

Typically, POS systems define Tender IDs for this purpose.

→ Order is injected in the POS.

→ Order is not injected in KDS (Kitchen Display System), i.e. it is not sent to the kitchen.

→ Order is injected in KDS sent to the kitchen after user performs the payment.

Place an online payment (paid) in-restaurant order

As per above.

E.g. guest places a Pick Up order for 5:30pm and pays with cash. Guest arrives at the restaurant and pays for order at front counter, team member sendd order to the kitchen.

Place an online payment (paid) in-restaurant order

Same process described in previous table for any service mode (Dine In, Pick Up, Table Service…).

In the payment page, user selects credit card or any other alternative payment method that leaves the order paid.

Image Added

Partner collects the payment method from the GET Order endpoint and injects in the appropriate POS field.

Typically, POS systems define Tender IDs for this purpose.

Any payment method besides CASH and UNPAID falls under this category.

→ Order is injected in the POS and in KDSsent to the kitchen, following the fireOrderInSeconds logic explained in the table above.

Delivery

...

Action
Tests
Vendor Action
Expected Result
Place a Delivery order
Authenticated user inputs address within delivery area on restaurant search in App, builds a cart and navigates to checkout.
Authenticated user clicks on “Continue” on the checkout page, and confirms selecting any payment method by clicking “Place Secure Order”.
Partner collects the service mode (`serviceMode`) from the GET Order endpoint (`DELIVERY`) and injects in the POS.
`fireOrderInSeconds: null` indicates the order should not be fired to the kitchen, and instead be injected to the POS in suspended mode.
Partner collects the order number (`number`) from the GET Order endpoint and injects in the POS.
→ Order is injected in the POS.
→ Order does not appear in the KDS (not fired into the kitchen).
Fire a Delivery order into the kitchen
Delivery vendor request to move the order to kitchen
Based on driver’s geolocation OR driver’s ETA to the restaurant.
Partner is subscribed to the `ORDER_FIRE` webhook, which triggers a request to fire an order into the kitchen.
Partner fires the order through a POST call to the Fire Order endpoint.
Firing is expected to happen when the driver is at a distance / time from the restaurant equal or lower to the preparation time (prep time). The POS vendor is not required to compute any logic, as RBI is responsible for informing the POS vendor when to fire orders.
→ Order appears in the KDS (is fired into the kitchen).
→ KDS identifies the service mode.
→ DSS ticket printed according to the service mode.
→ Receipt printed with Order Number from RBI.
RBI’s order number is expected to substitute the POS order number.
RBI’s order number is configurable, allowing numerical interval restriction and / or utilization of an alphanumerical prefix.
Note
Drivers rely exclusively on this number to identify the order they are supposed to pick up at the restaurant.
Cancel a Delivery order
Delivery cancelation
→ Delivery Order successfully sent and placed in Partner’s POS.
→ If a delivery cancellation is requested:
The order should be canceled in the POS.
Info
Payment Methods do not interfere with order firing for Delivery orders.
...

Versions Compared

Old Version 24

New Version 25

Key

Order firing for in-Restaurant Service Modes

Payment Methods for in-restaurant orders

Delivery