Contents
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
References
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
🏪 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 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
References
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
🏪 Restaurant Management
Action | How to test | Vendor Action | Expected Result | ||||
---|---|---|---|---|---|---|---|
Update store status
| User inputs restaurant address in the store locator in RBI’s platform. | Update store status to online via Update Store Status endpoint.
| → Partners API reports store is online through Get Store Status endpoint. →
→ RBI admins have access to the Store Diagnostics and can verify that | ||||
Update store status
| User inputs restaurant address in the store locator in RBI’s platform. | Update store status to offline via Update Store Status endpoint.
| → Partners API reports store is offline through Get Store Status endpoint. → Ordering buttons become grayed out for the store.
→ RBI admins have access to the Store Diagnostics and can verify that |
🍔 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. |
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 | → 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 | → 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 | → 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.
| ||||
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 | → 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 | → 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.
| ||||
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 | → 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 | → 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 | → 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
| |||||||
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 | → 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.
| 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
| User selects ordering for the corresponding store and navigates to the combo containing the premium item.
| Make a request with price and
| → 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
| Authenticated user User selects ordering for the corresponding store and navigates to the combo containing the premium item.
| Make a request with price and
| → 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 Info | Reward available for a certain store | Authenticated user selects ordering for the corresponding store and navigates to the combo containing the premium item. Internal configurations should be applied to serveComposite PLU for the given POS Vendor / marketrewards page. User must have enough points to redeem applicable reward. | Make a request with price and 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 plu123-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.
| |||
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 | → 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.
| 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 |
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 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
.
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 orderActionTests | How to test | Vendor Action | Expected Result | ||||
---|---|---|---|---|---|---|---|
Pricing Order
| Authenticated user selects ordering for the corresponding store, adds items to cart and navigates to the checkout. All available Cart Structures must be tested:
| 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
→ /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
| 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:
| 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
| → Order is injected in the POS.
| 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:
|
| → → Loading time does not exceed 3 seconds for p99. → Tax, Subtotal, and Total are visible at checkout
→ (OPTIONAL) Fees, such as “Bag Fee”, are visible in the | ||||||
Commit Order
| 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:
| 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
| → Order is registered in the POS.
| ||||
Cancel Order – Initiated by guests or delivery fulfillment providers
|
| Partner is subscribed to the Order Event webhook. Upon cancelation, the webhook will return an event with status The POS must acknowledge the cancelation and mark the order as canceled in the POS. | → Order status is changed to → An automatic refund is processed (if applicable). → A cancellation email is triggered. | ||||
Cancel Order – Initiated by POS
| Restaurant team member cancels order in the POS. | Partner send status | → 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:
|
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
| 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 ( Partner collects the order number ( | 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 ( All order information can also be fetched from the GET Order endpoint, at any time.
| → 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.
| ||||||
Place a Curbside order Drive-Thru order
| Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout. User selects service mode and order time | 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 ( All order information can also be fetched from the GET Order endpoint and injects in the POS, at any time.
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.
Place a Dine In / Pickup order Future order (ScheduledOrder 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 Dine In or Pick Up and order time equivalent to any slot in the future. Partner collects the service mode ( Partner collects the order number ( fireOrderInSeconds: X Table Service and inputs the desired table number. 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 ( All order information can also be fetched from the GET Order endpoint, at any time.
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.
| ||||||
Place a Table Service Dine In / Pickup order
| 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 | Partner injects order the POS using the corresponding service Mode and number. Partner collects the service mode ( Partner collects the order number ( All order information can also be fetched from the GET Order endpoint and injects in the POS, at any time.
| → 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.
| ||||||
Place a Curbside order Futureorder (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 ( Partner collects the order number (
| → 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 ( All order information can also be fetched from the GET Order endpoint, at any time.
| → 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.
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.
|
...
Expand | |||
---|---|---|---|
| |||
Payment methods for in-restaurant orders
|
...
|
...
|
...
|
...
|
...
|
...
As per 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 ( All order information can also be fetched from the GET Order endpoint (
Partner collects the order number ( | → 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 Basedbased on the driver’s geolocation ORor driver’s ETA to the restaurant. | Partner is subscribed to the Partner fires the order through a POST call to the Fire Order endpoint.
| → 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.
Cancel a Delivery order Delivery cancelation → Delivery Order successfully sent and placed in Partner’s POS
|
Info |
---|
Payment Methods do not interfere with order firing for Delivery orders. |
...
Order Events (WIP)
Action | Tests | Vendor Action | Expected Result | |||||
---|---|---|---|---|---|---|---|---|
| ||||||||
| ||||||||
| ||||||||
| ||||||||
| ||||||||
|
...