Integration Signoff checklist - Ordering Integration

Ensure below list of use-cases are tested/verified before you seek integration sign-off from Integration Team

2d99496b4b52d29fd1cc66db7dbaf182

Written By Ops UrbanPiper (Collaborator)

Updated at February 7th, 2020

Action Pointers

Make sure you have consumed the below APIs before requesting integration team for the sign-off -

  1. Order Relay
  2. Order Status Update from POS to UP
  3. Order Status Update from UP to POS
  4. Rider Status Update
  5. Adding/updating the stores
  6. Store Configuration Callback
  7. Stores Actions API
  8. Stores Actions Callback
  9. Manage Catalogue Update
  10. Catalogue Configuration Callback
  11. Items Action API
  12. Webhook API
  13. Satellite SDK Widget

Important points to remember while validating the integration development at POS end.

Non-technical Aspects

  1. These pieces of information should show on POS frontend/screen along with the ordered item details,
    - Order_id of aggregator
    - channel
    - delivery_type
    - payment type
    - instructions 
    - delivery rider contact details
    - current status of the order
    - current status of the delivery rider
    - Merchant Sponsored Discount
  2. 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.
  3. Merchant receivable amount from aggregators = (order_total + total_external_discount). This will give an estimate of what is the total receivable money from the aggregators. This will not include the charges in which aggregators are put for merchants on each order.
  4. Placed and cancelled order status from aggregators should show as a pop-up notification/sound notification on POS screen,
  5. Validate order level, as well as item level taxes and charges, are taken care and the same is visible in the POS screen.
  6. Validate the ordered items with options, quantity, taxes, charges, and discount information is showing correctly on the POS screen.
  7. Check all the mandatory order status update - Acknowledged, Food Ready, Cancelled is being passed from the POS system and the status has been updated in the UP system.
  8. Food Ready - the status update should be passed as soon as the food is prepared in the kitchen.
  9. The POS has to push only the online selling menu to UrbanPiper system. 
  10. Use https://staging.urbanpiper.com as host for staging environment and use https://api.urbanpiper.com as host for production environment while making the request.
  11. Make sure you have made a provision for configuring the different API-keys for different brands.
  12. If you have merchants who are running multiple brands in the same outlet, then make sure you have multi-brand integration with us. That is the same API-keys will be associated with multiple brands and you will pass one more header to insert the biz_id value of the brand under - x-upr-biz-id. The biz_id will be shared by the UrbanPiper team.

Technical Aspects

  1. Check if the requests are being made to UrbanPiper APIs is of https scheme.
  2. 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.
  3. Make sure POS has handled the throttling limit for all the APIs.
  4. Make sure the retry mechanism for a failed response should have max. of 3 times only.
  5. Make sure the Swiggy Cancellation Error Response use case has been tested.
  6. 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.
  7. If POS doesn't have any data for a given optional attribute in the request, allow null values, NOT the empty string.
  8. If POS doesn't have any data for a given optional array in the request, allow empty array or null, NOT the empty string.
  9. While passing the tax information in the Managing Catalogue API, in the ref_id always keep a prefix of POS location ref id. This will help in not overwriting the tax data when you push it location wise.
  10. POS should not have the logic  - same items at 2 different locations having the common item ref id should not have a two different price concept.
  11. The POS Menu catalog IDs for an item should be the same for all the stores for a single brand - Federated Structure.
  12. 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.
  13. Make sure you have simulated all the payloads shared in the Postman collection for Order Relay and Rider Status Update webhook.


If you have any queries to ask, feel free to drop an email to integrations.team@urbanpiper.com.

Was this article helpful?