Contents
References
🏪 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. 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. → 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 |
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. 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. 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 |
🍔 Menu Management
Store Menu Pricing & Availability
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.
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 combo. | Make a request with price and | → Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability. → Combo appears in App Menu section with correct price. 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 a combo unavailable for a certain store | User selects ordering for the corresponding store and navigates to the menu section of the combo. | Make a request with price and | → Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability. → Combo disappears from App Menu section. |
Make a modifier multiplier available for a certain store | 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 appears in App Menu section with correct price. |
Make a modifier multiplier unavailable for a certain store | 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 for a certain store | 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 for Mobile redemption with correct price. 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 | 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 button for Mobile redemption is grayed out. |
Make a premium item (within a comboslot) available as part of a combo 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.
| 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 the Combo with the desired premium price. |
Make a premium item (within a comboslot) unavailable as part of a combo 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.
| 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 the Combo. |
Make a Reward available 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 for Mobile redemption with correct price. 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 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 button for Mobile redemption is grayed out. |
💰 Checkout
Order Creation
You can learn about the checkout actions in the Partner API here: Order API - Checkout
Action | How to test | Vendor Action | Expected Result |
---|---|---|---|
Pricing Order 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 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 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
| → /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 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 available 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. Committing and order does not mean that the order should be prepared immediately. In the Commit Order webhook payload we include the This will vary by service mode and payment method – see tables below. |
Cancel Order – Initiated by guests or delivery fulfillment providers Orders might get canceled either by guests or delivery 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 cancel. 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 Exceptionally, the POS vendor may cancel an order. | 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
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.
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 Dine In or Pick Up and order time | Partner injects order the POS using the corresponding service Mode and number. The Partner would’ve 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.
| → 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. 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 injects order the POS using the corresponding service Mode and number. The Partner would’ve 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.
| → 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 injects order the POS using the corresponding service Mode and number. The Partner would’ve 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.
| → 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. 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 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. → 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. 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
| 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 (
| → 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. Guests rely exclusively on this number to identify their online orders. |
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 order time equivalent to any slot in the future. User inputs the desired table 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. → 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. 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 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. → 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. 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
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. | Partner collects the payment method from the GET Order endpoint ( 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 | 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. | 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 | → Order is injected in the POS and sent to the kitchen, following the |
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 (
Partner collects the order number ( | → 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
| 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.
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:
|
Payment Methods do not interfere with order firing for Delivery orders.
Order Events
Action | Tests | Vendor Action | Expected Result |
---|---|---|---|
Menu Availability Validation
Object | Available |
---|---|
section | If any |
combo | If
All the |
combo slot | At least |
item | If If, for any Warning:
|
item option | If any Example: If all item option modifiers are unavailable for a specific item option, i.e. lettuce, the entire item option is not displayed on the FE |
item option modifier | If Warning: Empty PLU type is treated as unavailable. If an Item Option modifier was configured to Empty type, the item would appear as unavailable. If that item was the only item in the combo slot, the combo slot and combo would then appear as unavailable. |
picker | if any |
picker aspect value | if any |
Offer Availability Validation
Pass all the Rules validation set in
Mechanics-Rules
, the important rules can be Service Mode, Valid Time Span, Authentication Required and so on, the full list can be found in Rulesets for Offers, Rewards and Promotions.Ensure the benefit set in
Mechanics-Benefits
is available, the availability validation follows the same logic in the /wiki/spaces/~834441867/pages/4822433853 section. Because the benefit can be item, combo and picker, so the important is to check accordingly.