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 | → 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 | Authenticated 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 | Authenticated 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. → Combo appears in App Menu section with correct price.
|
Make a combo 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 | → 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: → Make a request with price and
Note that combos only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about combos' configuration: Combo | → Combo appears in App Menu section, with correct price. → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.
| ||
Make a combo unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response. → Confirm that the combo(s) no longer appear on the Whitelabel App’s menu section
For further context about combos' configuration: Combo | |||
Make a modifier multiplier available: Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich). → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response → Confirm that the modifier multipliers appear on the product detail page of products which the modifiers are configured, with correct price (if defined)
Note that modifier multipliers only appear in the application if they are correctly configured in the CMS (Sanity), and only for products for which modifiers are configured. Further context about configuration: Modifier Modifier Multiplier | |||
Make a modifier multiplier unavailable: Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich). → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response → Confirm that the modifier(s) and/or modifier multipliers no longer appear on the product detail page of products which the modifiers are configured
Further context about configuration: Modifier Modifier Multiplier | |||
Make a systemwide offer available: → Make a request with
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response → Confirm that the systemwide offers appear on the whitelabel application.
Systemwide offers only appear in the application if they are correctly configured in the CMS (Sanity). For further context about configuration: Systemwide Offers
| |||
Make a systemwide offer unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response → Confirm that the systemwide offer(s) no longer appear on the Whitelabel App’s menu section
For further context about configuration: Systemwide Offers | |||
Make a premium comboslot item available as part of a combo: → Make the  → Tweak the Launch Darkly flag https://app.launchdarkly.com/intl-platform/staging-plk/features/enable-premium-combo-slots/targeting to serve Composite PLU for the given PosVendor. → Make a request to Partners-API updateMenuPlus endpoint to define price (if it was 0 previously), and
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response → Confirm that the premium comboslot appear on the product detail page of products for which it has been configured, and the price reflects as well.
Further context about configuration: Combo Slot Detailed scenarious are described below:  | |||
Make a premium comboslot item unavailable: → Same as ‘Making an item unavailable’. | |||
Make a reward available: → Make a request with
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the availability values in the API response → Confirm that the systemwide offers appear on the whitelabel application.
Note that there may be additional rulesets (e.g. only for certain time-between, payment method, etc.) defined for rewards: Mechanics | |||
Make a reward unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response → Confirm that the reward(s) no longer appear on the Whitelabel App
For further context about configuration: Loyalty Rewards |
Order Creation
Service Modes
Alternative Flows
Order ID
Tender ID
Order Modes
Order Events
Potentially unclear points for integrator:
Curbside pickup extra details
Menu: Pricing & Availability | Make an item available: → Make a request with price and Note that items only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about items' configuration: Item | → Item appears in App Menu section with correct price. → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.
| |
Make an item unavailable: → Make a request with For further context about items' configuration: Item | → Item disappears in App Menu section. → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.
| ||
Make a combo available: → Make a request with price and
Note that combos only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about combos' configuration: Combo | → Combo appears in App Menu section, with correct price. → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.
| ||
Make a combo unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response. → Confirm that the combo(s) no longer appear on the Whitelabel App’s menu section
For further context about combos' configuration: Combo | |||
Make a modifier multiplier available: Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich). → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response → Confirm that the modifier multipliers appear on the product detail page of products which the modifiers are configured, with correct price (if defined)
Note that modifier multipliers only appear in the application if they are correctly configured in the CMS (Sanity), and only for products for which modifiers are configured. Further context about configuration: Modifier Modifier Multiplier | |||
Make a modifier multiplier unavailable: Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich). → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response → Confirm that the modifier(s) and/or modifier multipliers no longer appear on the product detail page of products which the modifiers are configured
Further context about configuration: Modifier Modifier Multiplier | |||
Make a systemwide offer available: → Make a request with
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response → Confirm that the systemwide offers appear on the whitelabel application.
Systemwide offers only appear in the application if they are correctly configured in the CMS (Sanity). For further context about configuration: Systemwide Offers
| Offer PLU 4017 | ||
Make a systemwide offer unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response → Confirm that the systemwide offer(s) no longer appear on the Whitelabel App’s menu section
For further context about configuration: Systemwide Offers | |||
Make a premium comboslot item available as part of a combo: → Make the → Tweak the Launch Darkly flag https://app.launchdarkly.com/intl-platform/staging-plk/features/enable-premium-combo-slots/targeting to serve Composite PLU for the given PosVendor. → Make a request to Partners-API updateMenuPlus endpoint to define price (if it was 0 previously), and
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response → Confirm that the premium comboslot appear on the product detail page of products for which it has been configured, and the price reflects as well.
Further context about configuration: Combo Slot Detailed scenarious are described below: | |||
Make a premium comboslot item unavailable: → Same as ‘Making an item unavailable’. | |||
Make a reward available: → Make a request with
→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the availability values in the API response → Confirm that the systemwide offers appear on the whitelabel application.
Note that there may be additional rulesets (e.g. only for certain time-between, payment method, etc.) defined for rewards: Mechanics | |||
Make a reward unavailable: → Make a request with → Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response → Confirm that the reward(s) no longer appear on the Whitelabel App
For further context about configuration: Loyalty Rewards | |||
→ 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) |
| ||
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. |
| ||
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. |
| ||
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. |
| ||
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. |
| ||
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: {
"identifier": "number",
"posVendor": {
"posType": "pos",
"storeId": "number",
"terminal": "number",
"operator": "number",
"transactionId": "number"
}
}
{
"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"
}
]
}
}
{
"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. |
| ||
Order discounts - IREQ-1709 - Getting issue details... STATUS ? | |||
Order Injection: In Store | 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 | ||
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 | |||
Order Injection: Delivery orders (if applicable) | Delivery → Delivery Order successfully sent and placed in Partner’s POS. → The delivery fee should be included in the order information. | ||
Delivery cancelation → Delivery Order successfully sent and placed in Partner’s POS. → If a delivery cancellation is requested:
| |||
Delivery rejection → Delivery Order successfully sent and placed in Partner’s POS. → If the delivery partner rejects the order:
| |||
| When an explicit fire order (send to kitchen) event is expected:
→ Order should be triggered to POS with
→ 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 ( → Order should be injected to POS with → 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 ( → Order should be injected to POS with → After | |||
Order Events | Test cases for all order events and its flow to mParticle → Braze, etc. Need to create tests for each event. | ||
Order Cancellation | After execution call to Partners API with the → 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. |