Orders API - Integration Test Cases

Store: Status

Partner Integration → Partner API

Update Store Status to Online through Partner API

→ Partners API should report store is online through Get Store Status call, immediately.

Store appears online for ordering in App, after X seconds

Partner Integration → Partner API

Update Store Status to Offline through Partner API (register latency to Front End in seconds?)

→ Partners API should report store is offline through Get Store Status call, imediatelly.

Store appears offline for ordering in App, after X seconds

Store: Heartbeat

RBI Heartbeat Webhook → Partner Webhook URL

Request is sent from RBI, per store, every 15 minutes to the provided POS Partner webhook URL.

→ Partner should reply with store status (isOnline).

→ Partners API should report store status through Get Store Status call immediately.

Based on the response from POS, store appears online/offline for ordering in App, after X seconds

Menu: Pricing & Availability

Make an item available:

→ Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

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.

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

Make an item unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

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.

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

Make a combo available:

→ Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

• Including the PLU for the main item of the combo - a combo cannot be made available without its main item is available. (E.g. whopper medium burger is the main item of the whopper meal medium combo)

• Ensure at least one comboslot within the combo has availability : true - a combo cannot be made available before at least one item in its comboslots are available.

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.

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

Make a combo unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ 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

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

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 availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint. Including the modifier PLUs (if applicable).

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

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

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 availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ 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

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

Further context about configuration: Modifier Modifier Multiplier

Make a systemwide offer available:

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

• Ensure an incentive has been correctly defined: https://rbictg.atlassian.net/wiki/spaces/COG/pages/4041670827/Systemwide+Offers#Incentives

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

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

Systemwide offers only appear in the application if they are correctly configured in the CMS (Sanity). For further context about configuration: Systemwide Offers

• Note that there may be additional rules defined for systemwide offers https://rbictg.atlassian.net/wiki/spaces/FEP/pages/3499851975/Incentives+Definitions+Rules

Offer PLU 4017

Make a systemwide offer unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ 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

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

For further context about configuration: Systemwide Offers

Make a premium comboslot item available as part of a combo:

→ Make theIs Premium Item flag enabled (TRUE) in the CMS Sanity for a given comboslot option:

→ 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 availability : true.

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

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

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

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 availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

• Make sure the reward incentive has been correctly defined on Sanity. The incentive is the item or combo that you can apply the reward to. This is the ‘normal’/'regular' item or combo document, not a separate one created like we do for offers. For further context about the configuration: Loyalty Rewards

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

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

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 availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ 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

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

For further context about configuration: Loyalty Rewards

Order Injection: Cart

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

Modifier Multiplier

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.

Modifier Multiplier

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

{
    "identifier": "number",
    "posVendor": {
        "posType": "pos",
        "storeId": "number",
        "terminal": "number",
        "operator": "number",
        "transactionId": "number"
    }
}

Validate: After totalization - We send a confirmation if everything is okay with the order and the guest's updated point balance if the order is payed (It is a dry run of the update)
Endpoint: [stage]-[brand]-loyalty-middleware.rbictg.com/loyalty/transaction/pos/[orderId]

{
    "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"
        }
    ]
 
    }
}

Update: After Payment - We confirm the transaction and update the guest's point balance. We also send loyalty receipt information

{
    "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 - IREQ-1709 - Getting issue details... STATUS ?

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

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:

• The order should be canceled in the POS.

Delivery rejection

→ Delivery Order successfully sent and placed in Partner’s POS.

→ If the delivery partner rejects the order:

• The order should be canceled in the POS.

Order Injection: Time to Kitchen

When an explicit fire order (send to kitchen) event is expected:

1. Place Order in Whitelabel App

→ Order should be triggered to POS with fireOrderInSeconds=null

2. On confirmation page click I'm Here button

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

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.