Orders API - Integration Test Cases

Update Store Status

• To Online

Authenticated user inputs restaurant address on restaurant search in App.

Update Store Status to Online (docs).

→ Partners API reports store is online 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 isRestaurantPosOnline: true

Update Store Status

• To Offline

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. Mobile ordering is not available at this store warning appears.

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 isRestaurantPosOnline: false

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.

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.

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 PLU for 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 plu 123-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 PLU for 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 plu 123-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.

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.

• Consider a cache of up to 1 minute for updates to reflect in FE.

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, builds a cart and navigates to the checkout.

All Cart Structures must be tested in this category:

• Item

• Item w/ modifiers

• Combo

• Combo with items w/ modifiers

• Systemwide Offer Item

• Systemwide Offer Combo

• Systemwide Offer Combo w/ modifiers

• Promo Codes - Amount Discount

• Promo Codes - Percentage Discount

• Reward Item

• Reward Combo

• Reward Combo with modifier

Partner is subscribed to the ORDER_PRICE webhook (docs), which provides details about a new order to be priced.

Partner utilizes the Price Webhook Callback to answer the Price request.

Error Handling to follow the message and code standards:

• Message: include a clear error message, mentioning the PLUs responsible for the failure and the designated store. Do not include unhelpful information like Error occurred while processing request

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

→ /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 successfully pricing and payment, order is injected in the POS.

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

All Cart Structures must be tested in this category:

• Item

• Item w/ modifiers

• Combo

• Combo with items w/ modifiers

• Systemwide Offer Item

• Systemwide Offer Combo

• Systemwide Offer Combo w/ modifiers

• Promo Codes - Amount Discount

• Promo Codes - Percentage Discount

• Reward Item

• Reward Combo

• Reward Combo with modifier

Partner is subscribed to the ORDER_COMMIT webhook (docs), which provides details about a new order to be injected in the POS.

Partner utilizes the Commit Webhook Callback to answer the Commit request.

Error Handling to follow the message and code standards:

• Message: include a clear error message, mentioning the PLUs responsible for the failure and the designated store. Do not include unhelpful information like Error occurred while processing request

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

→ Order is injected in the POS.

(further details included below, as per service mode and payment method)

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.

Place a Dine In / Pickup / Drive-Thru order

• Immediate order (Now)

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

User selects service mode and order time Now.

Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN TAKEOUT DRIVE_THRU) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

• fireOrderInSeconds: 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.

• 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.

Place a Table Service order

• Immediate order (Now)

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

User selects service mode and order time Now.

User inputs the desired table number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.

Partner collects the order number (number) 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 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.

• 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.

Place a Curbside order

• Immediate order (Now)

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

User selects service mode and order time Now.

User inputs the car plate number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (CURBSIDE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

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

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

• 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.

Place a Dine In / Pickup / Drive-Thru order

• Future order (Scheduled)

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.

Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN TAKEOUT DRIVE_THRU) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

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

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

• 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.

Place a Table Service order

• Future order (Scheduled)

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 desired table number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

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

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

→ Order appears in the KDS X seconds after POS order injection.

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

• 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.

Place a Curbside order

• Future order (Scheduled)

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

User selects service mode and order time equivalent to any slot in the future.

User inputs the car plate number.

Partner collects the service mode (serviceMode) from the GET Order endpoint (CURBSIDE) and injects in the POS.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

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

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

→ Order appears in the KDS X seconds after POS order injection.

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

• 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.

Place a Cash or any other Unpaid in-restaurant order

As per above.

Partner collects the payment method from the GET Order endpoint (CASH or UNPAID) and injects in the appropriate POS field.

Typically, POS systems define Tender IDs for this purpose.

→ Order is injected in the POS.

→ Order is not 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 CASH and UNPAID falls under this category.

→ Order is injected in the POS and in KDS.

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 (serviceMode) from the GET Order endpoint (DELIVERY) and injects in the POS.

• fireOrderInSeconds: null indicates the order should not be fired to the kitchen, and instead be injected to the POS in suspended mode.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

→ 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

• Based on driver’s geolocation OR driver’s ETA to the restaurant.

Partner is subscribed to the ORDER_FIRE webhook, which triggers a request to fire an order into the kitchen.

Partner fires the order through a POST call to the Fire Order endpoint.

• Firing is expected to happen when the driver is at a distance / time from the restaurant equal or lower to the preparation time (prep time). The POS vendor is not required to compute any logic, as RBI is responsible for informing the POS vendor when to fire orders.

→ Order appears in the KDS (is fired into the kitchen).

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

• RBI’s order number is expected to substitute the POS order number.

• RBI’s order number is configurable, allowing numerical interval restriction and / or utilization of an alphanumerical prefix.

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.

section

If any section options are available

combo

If combo.plu exists in restaurant pos data for the selected store &&

main item is available &&

All the combo slot are available

combo slot

At least Minimum Amount item under combo slot options is available

item

If item.plu exists in restaurant pos data for the selected store &&

If, for any item option that has inject default selection flag set to true, at least one item option modifier is available under the item option.

item option

If any item option modifier are available for the item option

item option modifier

If modifier multiplier.plu exists in the pos data for the selected store or the plu type is Ignore, and the modifier.plu is in the store pos data

picker

if any picker options are available

picker aspect value

if any picker options that have the picker aspect value mapped are available