Make sure you have consumed the below APIs before requesting integration team for the sign-off -
- Order Relay
- Order Status Update from POS to UP
- Order Status Update from UP to POS
- Rider Status Update
- Adding/updating the stores
- Store Configuration Callback
- Stores Actions API
- Stores Actions Callback
- Manage Catalogue Update
- Catalogue Configuration Callback
- Items Action API
- Webhook API
Important points to remember while validating the integration development at POS end.
- These pieces of information should show on POS frontend/screen - Order_id of aggregator, channel, delivery_type, payment type, instructions, delivery rider contact details, the current status of the order, the current status of the delivery rider.
- Merchant Sponsored Discount = (discount - total_external_discount). Make sure this logic is handled at the POS end for the merchant to show how much merchant sponsored discount has been applied for an order. Also, show the same on the POS screen and bill.
- Merchant receivable amount from aggregators = (order_total + total_external_discount)
- New orders and cancelled order status from aggregators should show as a pop-notification on POS screen,
- Validate order level, as well as item level taxes and charges, are taken care and the same is visible in the POS screen.
- Validate the ordered items and quantity is showing correctly on the POS screen.
- Check all the mandatory order status update is being passed from the POS system and the status has been updated in UP system.
Food Ready - the status update should be passed as soon as the food is prepared in the kitchen.
- Check if the requests are being made from https scheme.
- Check the time taken to show the orders in the POS screen and time taken for status update happening from POS to the UP system. The changes should reflect within 10 seconds.
- Make sure POS has handled the throttling limit for all the APIs.
- Make sure the retry mechanism for a failed response should have max. of 3 times only.
- The request call to our APIs should always happen as a bulk request. The objects should be sent in bulk while making a request to our system.
- Check if the requests for Items Actions API and Store Actions API are being made from https://integrations.urbanpiper.com.
- If POS doesn't have any data for a given optional attribute in the request, allow null values, NOT the empty string.
- If POS doesn't have any data for a given optional array in the request, allow empty array or null, NOT the empty string.
- POS should not have the logic - same items at 2 different locations having the common item ref id should not have a two different prices concept.
- The POS Menu catalog IDs for an item should be the same for all the stores for a single brand.
- The same item should not have different prices for different aggregators for the same location. Basically, we don't support the differential pricing for aggregators.