EMT (BAP) | OYO (BPP) - [TRV13] - compliance checks

[sandeepshahi]

BAP - EMT | BPP - OYO

• logs must be submitted as per the test case scenarios:
  • Happy scenario (Order to Confirm to Status marked as Complete)
  • Cancellation Flow
  • Modification of details
• "null" values should not be provided; schema should be followed as per the dev guide, eg: "images" should be an array
• above point is applicable for all the attributes and APIs
• context.message_id should be unique for every message pair or unsolicited call
• all the timestamps (context, created_at, updated_at etc.) should be in RFC3339 UTC format; "Z" is missing with no offset

/search

• placeholder link of static terms should not be provided

/on_search

• hotel location is not captured correctly; gps, city code, state and area_code should be mapped correctly
• for above point, the hotel location should be the same for which search request was initiated
• "categories" must be defined in ; items are mapped to invalid "category_ids"
• unicode literals (sycb as "\n" etc.) and html tags (

  etc.) should not be provided in the payload

• ack is not a valid attribute in /message; check for other APIs as well

/select

• The city code should remain the same as the one for which the hotel booking is intended

/on_select

• context.timestamp should be captured correctly; can't be the same as in /select
• quote.breakup should be provided correctly with applicable taxes
• item price is changing from /on_search to /on_select; is this intended?
• payments.tags.list is not required for FULL-PAYMENT modes
• enums should be used correctly; code should be "FULL-PAYMENT" instead of "FULL_PAYMENT"
• message.ack is not a valid attribute; applicable for all the APIs
• error should not be provided until intended for

/init and /on_init

• APIs must be submitted for verification

/confirm

• context.timestamp can't be earlier than /select timestamp
• created_at and updated_at timestamps are not captured correctly;

/on_confirm

• order.status should be "ACTIVE" (enum)
• updated_at should be captured correctly

/cancel

• cancellation_reason_id is an enum

/on_cancel

• order.status should be "CANCELLED" (being an enum)
• cancellation.reason.id should be checked before processing the cancellation and proper business error should be thrown in case of invalid reason id

/on_status

• correct enum should be used for order.status

@trivendra-singh @naimishemt

[trivendra-singh]

I could find only these enum values for order status - ACTIVE, COMPLETE, CANCELLED, COMPLETED, SOFT_CANCEL, CANCELLATION_INITIATED, CANCELLATION_REJECTED.

As discussed in an earlier call, bookings take about 2 minutes to get processed after landing into our system, but due to the TTL constraints, Rishabh suggested we could return the status as something like BOOKING_ACCEPTED for the on_confirm call when we receive the booking and then when we can show ACTIVE or CONFIRMED for the on_status call. I don't see any such ENUMS. Please suggest what should be done here. @sandeepshahi

These are enum values we are currently using -
CONFIRMED, CANCELLED, ACCEPTED, MODIFIED, MODIFICATION_ACCEPTED, CANCELLATION_ACCEPTED
Also, what's the difference between COMPLETE and COMPLETED??

And, please share the enum values for cancellation_reason_id, couldn't find it in the docs.