Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contents

Table of Contents
minLevel1
maxLevel4
outlinefalse
stylenone
typelist
printabletrue

References

Table of Contents
minLevel5
maxLevel6
outlinefalse
typeflat
separatorpipe
printabletrue

🏪 Restaurant Management

...

Action

...

How to test

...

Vendor Action

...

Expected Result

...

Update store status

  • To Online

...

User inputs restaurant address in the store locator in RBI’s platform.

...

Update store status to online via Update Store Status endpoint.

Info

RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

...

→ Partners API reports store is online through Get Store Status endpoint.

Select button is available and not grayed out.

...

Info

Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: true

...

Update store status

  • To Offline

...

User inputs restaurant address in the store locator in RBI’s platform.

...

Update store status to offline via Update Store Status endpoint.

Info

RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

...

→ Partners API reports store is offline through Get Store Status endpoint.

→ Ordering buttons become grayed out for the store. Mobile ordering is not available at this store warning appears.

...

Info

Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: false

...

🍔 Menu Management

Store Menu Pricing & Availability

Info

For all the cases below, for further debugging you can use the Get Store Menu Diff endpoint to identify the the changes in the store’s menu.

Note

For all the cases below, consider a cache of up to 1 minute for updates to reflect in RBI’s frontend.

...

Action

...

Tests

...

Vendor Action

...

Expected Result

...

Make an item available for a certain store

...

Contents

Table of Contents
minLevel1
maxLevel4
outlinefalse
stylenone
typelist
printabletrue

References

Table of Contents
minLevel5
maxLevel6
outlinefalse
typeflat
separatorpipe
printabletrue

🏪 Restaurant Management

Action

How to test

Vendor Action

Expected Result

Update store status

  • To Online

User inputs restaurant address in the store locator in RBI’s platform.

Update store status to online via Update Store Status endpoint.

Info

RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

→ Partners API reports store is online through Get Store Status endpoint.

Select button is available and not grayed out.

image-20240918-120813.pngImage Added
Info

Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: true

image-20240815-141749.pngImage Added

Update store status

  • To Offline

User inputs restaurant address in the store locator in RBI’s platform.

Update store status to offline via Update Store Status endpoint.

Info

RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

→ Partners API reports store is offline through Get Store Status endpoint.

→ Ordering buttons become grayed out for the store. Mobile ordering is not available at this store warning appears.

image-20240815-142116.pngImage Added
Info

Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: false

image-20240815-141749.pngImage Added

🍔 Menu Management

Availability

Info

For all the cases below, for further debugging you can use the Get Store Menu Diff endpoint to identify the changes to the store’s menu after each request.

Note

For all the cases below, consider a cache of up to 1 minute for updates to reflect in RBI’s frontend.

Only applicable if the POS supports premium comboslots, that is, combo sides which increase the total combo price

Reward available for a certain store

Action

Tests

Vendor Action

Expected Result

Make an item available for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the item.

Make a request with price and availability : true for the respective PLU using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item appears in App Menu section with correct price.

Make an item unavailable for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the item.

Make a request with price and availability : false for the respective PLU using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item disappears from App Menu section.

Make a combo available for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the itemcombo.

Make a request with price and availability : true for the respective PLU(s) using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Item Combo appears in App Menu section with correct price.

Note

Combos availability is not only affected by the Combo PLU, as other menu structures are required. Read about it here.

Combo’s availability depends on its children’s availability as well.

Make an item a combo unavailable for a certain store

Authenticated user User selects ordering for the corresponding store and navigates to the menu section of the itemcombo.

Make a request with price and availability : false for the respective PLU(s) using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Item Combo disappears from App Menu section.

Make a combo modifier multiplier available for a certain store

Authenticated user User selects ordering for the corresponding store and navigates to the menu section of the comboitem containing the modifier multiplier.

Make a request with price and availability : true for the respective PLU (s) using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Combo Modifier Multiplier appears in App Menu section with correct price.

Note

Combos availability is not only affected by the Combo PLU, as other menu structures are required. Read about it here.

Make a combo Make a modifier multiplier unavailable for a certain store

Authenticated user User selects ordering for the corresponding store and navigates to the menu section of the comboitem containing the modifier multiplier.

Make a request with price and availability : false for the respective PLU (s) using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Combo Modifier Multiplier disappears from App Menu section.

Make a modifier multiplier Systemwide Offer available for a certain store

Authenticated user User selects ordering for the corresponding store and navigates to the item containing the modifier multiplieroffers page.

Make a request with price and availability : true for the respective PLU PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Modifier Multiplier Offer appears in App Menu section Offers page and is available for Mobile redemption with correct price.

Make a modifier multiplier unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the item containing the modifier multiplier.

Make a request with price and availability : false for the respective PLU using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Modifier Multiplier disappears from App Menu section.

Make a Systemwide Offer available
Note

Offers availability is not only affected by the offer PLU, as other menu structures are required. Read about it here.

Offer’s availability depends on their benefit’s item availability.

Make a Systemwide Offer unavailable for a certain store

Authenticated user User selects ordering for the corresponding store and navigates to the offers page.

Make a request with price and availability : truefalse for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Offer appears in App Offers page and is available button for Mobile redemption with correct price.

Note

Offers availability is not only affected by the offer PLU, as other menu structures are required. Read about it here.

Make a Systemwide Offer unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the offers pageis grayed out. Offer displays text indicating that it isn't available at the selected location.

Make a premium item (within a comboslot) available as part of a combo

image-20240318-184606.pngImage Added
Info

Only applicable if the POS supports premium comboslots, that is, combo sides which increase the total combo price

User selects ordering for the corresponding store and navigates to the combo containing the premium item.

  • Internal configurations should be applied to serve Composite PLU for the given POS Vendor / market.

Make a request with price and availability : falsetrue for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpointStore Menu PLUs endpoint.

  • The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

Offer button for Mobile redemption is grayed outItem appears inside the Combo with the desired premium price.

Make a premium item (within a comboslot) available unavailable as part of a combo

image-20240318-184606.png
Info

Only applicable if the POS supports premium comboslots, that is, combo sides which increase the total combo price

Authenticated user User selects ordering for the corresponding store and navigates to the combo containing the premium item.

  • Internal configurations should be applied to serve Composite PLU for the given POS Vendor / market.

Make a request with price and availability : truefalse for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

  • The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item appears inside disappears from the Combo with the desired premium price.

Make a premium item (within a comboslot) unavailable as part of a combo

image-20240318-184606.pngImage Removed
Info

Authenticated user selects ordering for the corresponding store and navigates to the combo containing the premium item.

Internal configurations should be applied to serve Composite PLU for the given POS Vendor / market

rewards page.

User must have enough points to redeem applicable reward.

Make a request with price and availability : falsetrue for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. E.g. for the whopper meal medium (

PLU

=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456

(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.→ Item disappears from the Combowith the corresponding price and availability.

→ Reward appears in App Rewards page and is available for Mobile redemption with correct price.

Note

Rewards availability is not only affected by the reward PLU, as other menu structures are required. Read about it here.

Reward’s availability depends on their benefit’s item availability.

Make a Reward available unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards page.

User must have enough points to redeem applicable reward.

Make a request with price and availability : truefalse for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Reward appears in App Rewards page and is available button for Mobile redemption with correct price.

Note

Rewards availability is not only affected by the reward PLU, as other menu structures are required. Read about it here.

Make a Reward unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards pageis grayed out. Rewards displays text indicating that it isn't available at the selected location.

Pricing

Action

Tests

Vendor Action

Expected Result

Change price for an item

User navigates through App Menu.

Make a request with updated price

and availability : false

for the respective PLU

(s) to Partner’s API

using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the

corresponding price and availability.→ Reward button for Mobile redemption is grayed out

corresponding updated price.

→ Item price appears updated in the App Menu section with correct price.

This test should be run for all menu structures described in the previous section.

💰 Checkout

Order Creation

You can learn about the checkout actions in the Partner API here: Order API - Checkout

Action

Tests

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.

image-20240918-141301.pngImage Removed

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

ActionTests

How to test

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 selected cart products.

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

All available 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 ID, service mode, and other details.

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 must follow the message and code standards:

  • Message: include Include a clear and concise 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.

  • . Include information that would lead to the fixing and understanding of the error occurred. (e.g.: Offending PLUs, store status, etc.).
    Do not include redundant information like: Error occurred while processing request.

  • Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

/cart page loads total price of the 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

Info

Requirement for tax information varies from market to market. For example, some markets don't require a separate tax line as tax is included in the menu item price.

→ (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.

After pricing an order, an authenticated user pays, and continues with the placement the order.

All available 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 service mode, order id, total order price and customer details, among other details.

All order information can also be fetched from the GET Order endpoint, at any time.

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

Error Handling must follow the message and code standards:

  • Message: Include a clear and concise error message. Include information that would lead to the fixing and understanding of the error occurred. (e.g.: Offending PLUs, store status, etc.).
    Do not include redundant information like: Error occurred while processing request.

  • Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

→ Order is registered 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 – Initiated by guests or delivery fulfillment providers

Info

Orders might get canceled either by guests or delivery providers.

  • Initiated by guest: for pick up order, guest selects the Cancel Order option.

image-20240920-083841.pngImage Added
  • Initiated by delivery provider: order is canceled by the delivery provider in their Driver Management Portal.

Partner is subscribed to the Order Event webhook. Upon cancelation, the webhook will return an event with status CANCELED.

The POS must acknowledge the cancelation and mark the order as canceled in the POS.

→ Order status is changed to CANCELED. You can check it using the GET Order endpoint.

→ An automatic refund is processed (if applicable).

→ A cancellation email is triggered.

Cancel Order – Initiated by POS

Info

Exceptionally, the POS vendor may cancel an order.

Restaurant team member cancels order in the POS.

Partner send status CANCELED using the Order Event endpoint.

→ Order status is changed to cancel. You can check it using the GET Order endpoint or in the Order Event webhook.

→ An automatic refund is processed (if applicable).

→ A cancellation email is triggered.

Order firing for in-restaurant service modes

Below you can find the how to deal with order firing for paid in-restaurant orders.

Info

In the below cases, 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 – it can contain numbers and/or letters.

Info

KDS = Kitchen Display Screen.

ORB = Order Ready Board, which are the customer-facing screens in the restaurant.

DSS = Dynamic Service System. It consists on a set of operational procedures which improve order accuracy and speed of service. From a POS standpoint it requires the printing of sticky labels.

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

Action

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 Table Service and inputs the desired table number. No time selection appears.

image-20240918-162817.pngImage Removed

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 POSDine In or Pick Up and order time Now.

image-20240918-141301.pngImage Added

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the pricing webhook: service mode (TAKEOUT) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

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

→ Order is injected registered 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 Order Number from RBI.

→ ORB displays Order Number from RBI.

Note

Crew members Guests rely on an easy identification of the table exclusively on this number to identify where this order should be taken totheir online orders.

Place a Curbside order Drive-Thru order

  • Immediate order (Now)

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 Drive Thru. No time selection appears at checkout.

Partner injects order the POS using the corresponding service Mode and number. Partner collects the

The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (serviceMode) from the GET Order endpoint (CURBSIDE) and injects in the POS.Partner collects the order number (number) DRIVE_THRU) , order number, etc.

All order information can also be fetched from the GET Order endpoint and injects in the POS, at any time.

fireOrderInSeconds:

0

null indicates the order should be

fired to the kitchen immediately

held in the POS until the order is released.

→ Order is injected registered 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.but not sent to the kitchen.

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

At that point,

→ 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

Order Number from RBI.

→ ORB displays Order Number from RBI.

Place a Table Service order

  • 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 equivalent to any slot in the future.

image-20240918-162640.pngImage Removed

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

Table Service and inputs the desired table number.

image-20240918-162817.pngImage Added

No time selection appears.

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (TABLE_SERVICE) , order number, etc. The table service is provided under the instructions field.

All order information can also be fetched from the GET Order endpoint, at any time.

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

X seconds after the order is placed

immediately.

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

Order appears in the KDS X seconds after POS order injectionKDS identifies the service mode.

→ KDS identifies the service modetable number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with Order Number from RBI.→ ORB displays Order Number from RBIthe 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

Guests Crew members rely exclusively on this on an easy identification of the table number to identify their online orderswhere this order should be taken to.

Place a Table Service Dine In / Pickup order

  • Future order (Scheduled)

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

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

image-20240918-162640.pngImage Added

Partner injects order the POS using the corresponding service Mode and 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) The Partner has received all relevant information to the order previously via the pricing webhook: service mode (TAKEOUT) , order number, etc.

All order information can also be fetched from the GET Order endpoint and injects in the POS, at any time.

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

→ Order is injected registered 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 Order Number from RBI.

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

Note

Crew members Guests rely on an easy identification of the table exclusively on this number to identify where this order should be taken totheir online orders.

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. No time selection appears.

User inputs the car plate number, places the order 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.is taken to an order confirmation page with an “I’m here” button.

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the pricing webhook: service mode (CURBSIDE) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

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 clicks on I’m here, the order is sent to the kitchen.

Info

When that happens, the the fire webhook will be triggered. Partner should be listening to that webhook to know when to fire the order.

At that point:

→ 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 and car plate should take precedence to , which should be more visible than 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.

...

Expand
titlePayment methods for in-restaurant orders (WIP)

Payment methods for in-restaurant orders

Note

Applicable only to In-Restaurant orders.

Action

...

How to test

Vendor Action

Expected Result

Place a

...

cash (or any other

...

unpaid) in-restaurant order

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

User selects cash in the payment page.

image-20240919-064953.pngImage 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

...

sent to the kitchen.

→ Order is

...

sent to the kitchen after user performs the payment.

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

...

As per above.

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-20240919-065014.pngImage 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

...

sent to the kitchen, following the fireOrderInSeconds logic explained in the table above.

Delivery

...

orders

Action

Tests

Vendor Action

Expected Result

Place a Delivery order

Authenticated user inputs address within covered delivery area on restaurant search locator 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 The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (serviceMode) DELIVERY) , order number, etc.

All order information can also be fetched from the GET Order endpoint (DELIVERY) and injects in the POS, at any time.

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 be held in the POS until the order is released.

→ Order is injected registered 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 fulfillment provider requests to move the order to kitchen

Based

based on the driver’s geolocation

OR

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.

Info

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.

...

Order Events (WIP)

Action

Tests

Vendor Action

Expected Result

Expand
titleCREATED
  • Pre-Conditions:

    • User logged in

    • Restaurant Selected

  • Steps:

    • Navigate to menu

    • Add an Item in the cart

    • Place order (Checkout).

  • AC:

    • Partner API should receive the order with partner status as CREATED.

Expand
titlePRICED
  • Pre-Conditions:

    • User logged in

    • Restaurant Selected

  • Steps:

    • Navigate to menu

    • Add an Item in the cart

    • Place order (Checkout).

  • AC:

    • The order needs to have total and tax applied

    • Partner API should receive the order with partner status as PRICED.

Expand
titleCOMMITED
  • Pre-Conditions:

    • User logged in

    • Restaurant Selected

  • Steps:

    • Navigate to menu

    • Add an Item in the cart

    • Place order (Checkout).

    • Click to Continue

    • Choose the payment method

    • Fill the necessary informations

    • Click to pay

    • Wait the

  • AC:

    • The partner should receive the order payload

    • Partner API should receive the order with partner status as COMMITED

Expand
titlePREPARING
  • Steps:

    • Partner sends an event to update order status

  • AC:

    • Partner API should receive the order with partner status as PREPARING

Expand
titlePREPARED
  • Steps:

    • Partner sends an event to update order status

  • AC:

    • Partner API should receive the order with partner status as PREPARED

Expand
titleERROR
  • The error can happen between all described stages and to cover it properly we need to describe some scenarios:

    • Error on Pricing → I.e.: The price isn’t configured for the Item and store chosen.

    • Error on Payment → I.e.: The information provided for payment is incorrect.

    • Error on Commit → I.e.: Error by sending information to the partner end-point

    • Error on Update → I.e.: Error on payload sent by partner when changing the status to PREPARED

    • Error on Refund → I.e.: Error when trying to refund an order.

...