Contents
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
References
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Store Availability
Action | Tests | Expected Vendor Behavior | Expected Result |
|---|---|---|---|
Update Store Status
| Authenticated user inputs restaurant address on restaurant search in App. | Update Store Status to Online (docs). | → Partners API reports store is offline through Get Store Status call. → Ordering buttons become eligible for the store.  Note: 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
| Authenticated user inputs restaurant address on restaurant search in App. | Update Store Status to Offline (docs). | → Partners API reports store is offline through Get Store Status call. → Ordering buttons become grayed out for the store.  Note: 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  |
Store Menu Pricing & Availability
...
Action
...
Tests
...
Expected Vendor Behavior
...
Expected Result
...
Make an item available for a certain store
...
Authenticated 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(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 appears in App Menu section with correct price.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make an item unavailable for a certain store
...
Authenticated 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(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 App Menu section.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a combo available for a certain store
...
Authenticated user selects ordering for the corresponding store and navigates to the menu section of the combo.
...
Make a request with price and availability : true 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.
→ Combo appears in App Menu section with correct price.
Consider a cache of up to 1 minute for updates to reflect in FE.
| Note |
|---|
Combos availability is not only affected by the Combo PLU, as other menu structures are required. Read about it here. |
...
Make a combo unavailable for a certain store
...
Authenticated user selects ordering for the corresponding store and navigates to the menu section of the combo.
...
Make a request with 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.
→ Combo disappears from App Menu section.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a modifier multiplier available 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 : true 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.
→ Modifier Multiplier appears in App Menu section with correct price.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
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(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 disappears from App Menu section.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a Systemwide Offer available for a certain store
...
Authenticated user selects ordering for the corresponding store and navigates to the offers page.
...
Make a request with price and availability : true 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 for Mobile redemption with correct price.
Consider a cache of up to 1 minute for updates to reflect in FE.
| Note |
|---|
Offers availability is not only affected by the Combo 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 page.
...
Make a request with 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.
→ Offer button for Mobile redemption is grayed out.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a premium item (within a comboslot) available as part of a combo
...
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 PLUfor the given POS Vendor / market.
...
Make a request with price and availability : true 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 plu123-456.
...
→ 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.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a premium item (within a comboslot) unavailable as part of a combo
...
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 PLUfor the given POS Vendor / market.
...
Make a request with price and availability : false 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 plu123-456.
...
→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.
→ Item disappears from the Combo.
Consider a cache of up to 1 minute for updates to reflect in FE.
...
Make a Reward available for a certain store
...
Authenticated user selects ordering for the corresponding store and navigates to the rewards page.
...
Make a request with price and availability : true 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 for Mobile redemption with correct price.
Consider a cache of up to 1 minute for updates to reflect in FE.
| Note |
|---|
Rewards availability is not only affected by the Combo 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 page.
...
Make a request with 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.
...
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. |
Order Creation
Action | Tests |
|---|
Vendor |
|---|
Expected Result
Order Number
Action |
|---|
Tests
Expected Result |
|---|
Place a Dine In order
As per above.
Partner collects the order number (number) from the GET Order endpoint and injects in the POS.
Order is injected in the POS.
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 |
|---|
Guests rely exclusively on this number to identify their online orders. |
Place a Table Service order
Place a Delivery In order
| Note |
|---|
Drivers rely exclusively on this number to identify the order they are supposed to pick up at the restaurant. |
Payment Methods
Action | Tests | Expected Vendor Behavior | Expected Result |
|---|---|---|---|
Place a Cash or any other Unpaid in-restaurant order | As per above. | 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 injected in KDS (Kitchen Display System), i.e. it is not sent to the kitchen. → Order is injected in KDS after user performs the payment. |
Place an online payment (paid) in-restaurant order | As per above. | 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 in KDS. |
In-Restaurant Service Modes
...
Action
...
Tests
...
Expected Vendor Behavior
...
Expected Result
...
Place a Dine In order
...
As per above.
...
Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN) and injects in the POS.
...
→ Order is injected in the POS.
→ KDS identifies the service mode.
→ DSS ticket printed according to the service mode.
...
Place a Table Service order
...
As per above.
...
Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.
...
→ 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.
...
Order Injection: In Store
Service Modes (if applicable)
...
Pickup Order
→ Pickup Order successfully sent and placed in Partner’s POS.
→ Order shows in the POS as already paid
→ Order shows in the POS with RBI’s order number
→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute
→ POS prints the receipt with order number
→ Order shows in the KDS with RBI’s order number
→ Order shows in the ORB with RBI’s order number
| Expand | ||
|---|---|---|
| ||
|
...
Eat in Order
→ Pickup Order successfully sent and placed in Partner’s POS.
→ Order shows in the POS as already paid
→ Order shows in the POS with RBI’s order number
→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute
→ POS prints the receipt with order number
→ Order shows in the KDS with RBI’s order number
→ Order shows in the ORB with RBI’s order number
→ The order should include an additional information “Eat in order”
...
Table Service Order
→ Pickup Order successfully sent and placed in Partner’s POS.
→ Order shows in the POS as already paid
→ Order shows in the POS with RBI’s order number
→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute
→ POS prints the receipt with order number
→ Order shows in the KDS with RBI’s order number
→ Order shows in the ORB with RBI’s order number
→ The order should include an additional information “Table service”
→ The order should include the table number provided by the customer in Cart page
...
Curbside Pickup Order
→ Pickup Order successfully sent and placed in Partner’s POS.
→ Order shows in the POS as already paid
→ Order shows in the POS with RBI’s order number
→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute
→ POS prints the receipt with order number
→ Order shows in the KDS with RBI’s order number
→ Order shows in the ORB with RBI’s order number
→ The order should include an additional information “Curbside”
→ The order should include the car plate provided by the customer in Cart page
Delivery Service Mode
...
Action
...
Tests
...
Expected Vendor Behavior
...
Expected Result
...
Place a Delivery order
...
Partner collects the service mode (serviceMode) from the GET Order endpoint (DELIVERY) and injects in the POS.
fireOrderInSeconds: nullindicates the order should not be fired to the kitchen, and instead be injected to the POS in suspended mode.
...
→ Order is injected in the POS.
→ Order does not appear in the KDS (not fired into the kitchen).
...
Fire a Deliver order into the kitchen
...
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.
...
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.
Order Events
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Potentially unclear points for integrator:
|
→ Place Order in Whitelabel App
Order’s cart contains an Item → Order successfully sent and placed in Partner’s POS.
Order’s cart contains a Combo → Order successfully sent and placed in Partner’s POS.
Order’s cart contains an item, with a Modifier Multiplier without (0)
→ Order payload contains Modifier Multiplied PLU
→ Order successfully sent and placed in Partner’s POS, describing the without modifier.
Order’s cart contains an item, with Modifier Multiplier with (1)
→ Order payload contains Modifier Multiplied PLU
→ Order successfully sent and placed in Partner’s POS, describing the “with” modifier.
Order’s cart contains an item, with Modifier Multiplier extra (2)
→ Order payload contains Modifier Multiplied PLU
→ Order successfully sent and placed in Partner’s POS, describing the “extra(2)” modifier.
Order’s cart contains a combo, with an item that has a Modifier Multiplier without (0)
→ Order payload contains Modifier Multiplied PLU, inside the item, inside the combo.
→ Partner Integration successfully handles a 3 level nested structure in the cart.
→ Order successfully sent and placed in Partner’s POS, describing the without modifier.
Order’s cart contains a Combo with Premium Items
→ Order payload contains a Combo, with it’s children priced at 0, and premium items priced normally.
→ Order successfully sent and placed in Partner’s POS, priced at combo + premium item cost.
Order’s cart contains a System Wide Offer (Item)
→ Offer contains an item
→ Order successfully sent and placed in Partner’s POS, offer is applied successfully. (Burillo, Alejandro)
The offer is added into cart with correct price
Order’s cart contains a System Wide Offer (Combo)
→ Offer contains a Combo
→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.
The Offer is added into cart with correct price
Order’s cart contains a Config Offer (Item)
→ Offer contains an item
→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.
The Offer is added into cart with correct price
Order’s cart contains a Config Offer (Combo)
→ Offer contains a Combo
→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.
The Offer is added into cart with correct price
Order’s cart contains a Config Offer (Percentage Discount)
→ Offer contains a Order level percentage discount(e.g. 10% discount)
→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.
The price of the Order is 90% of the original price
Order’s cart contains a Loyalty Reward (Item)
→ User with enough loyalty points, selects loyalty reward in loyalty page on Whitelabel App.
→ Order is placed in Whitelabel App, with a cart containing a Loyalty rewards item.
→ Order successfully sent and placed in Partner’s POS.
→ Loyalty reward Item is applied successfully.
Order’s cart contains a Loyalty Reward (Combo)
→ Reward contains a Combo
→ Order successfully sent and placed in Partner’s POS.
→ Loyalty reward Combo is applied successfully.
Example calls:
Identify: During the order placement - We send the offers/rewards so the POS may apply them.
Endpoint: [stage]-[brand]-loyalty-middleware.rbictg.com/loyalty/identify
| Code Block |
|---|
{
"identifier": "number",
"posVendor": {
"posType": "pos",
"storeId": "number",
"terminal": "number",
"operator": "number",
"transactionId": "number"
}
} |
Endpoint: [stage]-[brand]-loyalty-middleware.rbictg.com/loyalty/transaction/pos/[orderId]
| Code Block |
|---|
{
"serviceMode": "serviceMode",
"channel": "channel",
"loyaltyId": "LoyaltyId",
"transactionId": "transactionId",
"status": "PENDING",
...
"created": "date",
"transactionDetails": {
"payments": [...],
"posVendor": {...},
"appliedDiscounts": [
{
"details": {
"displayName": "displayName",
"type": "REWARD"
},
"productId": "number",
"referenceId": "referenceId"
}
]
}
} |
| Code Block |
|---|
{
"loyaltyId": "loyaltyId",
"transactionId": "transactionId",
"channel": "RESTAURANT",
"serviceMode": "TAKEOUT",
"status": "PENDING",
"created": "date",
"transactionDetails": {
...
"posVendor": {
...
},
"order": [
{
"referenceId": "referenceId",
"name": "name",
"productId": "productId",
"incentiveId": "incentiveId",
"loyaltyEngineId": "loyaltyEngineId",
"quantity": number,
"price": price,
"productType": "reward"
}
]
}
} |
Order’s cart contains a Loyalty Reward (Percentage Discount)
→ Reward contains a Order level percentage discount(e.g. 10% discount)
→ Reward successfully sent and placed in Partner’s POS, offer is applied successfully.
The price of the Order is 90% of the original price
Order discounts -
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
When an explicit fire order (send to kitchen) event is expected:
Place Order in Whitelabel App
→ Order should be triggered to POS with fireOrderInSeconds=null
On confirmation page click
I'm Herebutton
→ POS receives webhook “Fire Order” (ref: https://eu-bk-partners.rbictg.com/docs/market/#tag/OrderWebhook/operation/webhookOrdersFire )
→ KDS receives the order
When orders are expected to reach the kitchen immediately:
Select Slot Now on checkout page (/cart) and finish process of placing order.
→ Order should be injected to POS with fireOrderInSeconds=0
→ The order should be fired immediately to the Kitchen.
→ KDS receives the order
When pre-ordering is expected, orders to reach the kitchen after a determined delay:
Select Future Slot of pickup on checkout page (/cart) and finish process of placing order.
→ Order should be injected to POS with fireOrderInSeconds={delay} . delay being equal in seconds from now to selected time on the checkout page.
→ After delay seconds have passed, order should be sent to the kitchen, and be displayed in KDS.
Order Events
Test cases for all order events and its flow to mParticle → Braze, etc. Need to create tests for each event.
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.
| ||
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.
| ||
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. 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. → Item appears inside the Combo with the desired premium price. | ||
Make a premium item (within a comboslot) unavailable 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. → 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.
| ||
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. 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 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 | How to test | Vendor Action | Expected Result | ||||
|---|---|---|---|---|---|---|---|
Pricing Order
| Authenticated user selects ordering for the corresponding store, adds items to cart and navigates to 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, 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 must follow the
| → → 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 Dine In or Pick Up and order time  | 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. → 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.
| ||||
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 at checkout. | 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.
| → 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 from the POS. 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 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.
| → Order is 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.
| ||||
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 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. → 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.
| ||||
Place a Curbside order | 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 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 and car plate, which should be more visible than the order number.
|
| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
Payment methods for in-restaurant orders
|
Delivery orders
Action | Tests | Vendor Action | Expected Result | ||||
|---|---|---|---|---|---|---|---|
Place a Delivery order | Authenticated user inputs address within covered delivery area on restaurant 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”. | 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.
| → Order is registered in the POS. → Order does not appear in the KDS (not fired into the kitchen). | ||||
Fire a Delivery order into the kitchen | Delivery fulfillment provider requests to move the order to kitchen based on the driver’s geolocation or 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.
|
Order Events (WIP)
Action | Tests | Vendor Action | Expected Result | |||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| ||||||||
| ||||||||
| ||||||||
| ||||||||
|
|
Error on Commit → I.e.: Error by sending information to the partner end-point
|
|
Order Cancellation
After execution call to Partners API with the CANCELED Order Event
→ 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)
Payment
→ Ensure payments are successfully processed using each payment method
Order cancelation
→ When the order is canceled in the POS the payment should be refunded
|
...
Menu Availability Validation
...