When a Booking Engine wishes to work with the BookingCenter APIs to Query Rates & Availability and Save Bookings, they usually use the following APIs:

1) Connect to the ‘PMS/CRS’ and retrieve hotel rates and availability, with specifics for finding which rates are Packages, what Items they include, and Quantity and Price.  To learn about rates and availabiity for an XML developer, we recommend reviewing the KnowledgeBase articles here.

OTA_ HotelAvailRQ/RS-

As summarized at: https://docs.bookingcenter.com/display/MYPMS/APIs+and+Web+Services+Available+From+BookingCenter this message provides an array with Type and Rate availability, and you could parse the array to get the ‘lowest’ available rate, or whatever hierarchy desired to offer a Guest. The credentials (User ID and password or API key) enable this API call to return what is needed when formatting this message for showing by date or Type.  

2) Save the Booking, what we call the NewBooking message

OTA_HotelRes

This is the message that sends a 'payload' of all data needed to save a booking.  As we explain at: https://support.bookingcenter.com/index.php?/Knowledgebase/Article/View/667 when querying and selling Packages, understanding the way your API calls for Inventory Items (which constitute the ‘parts’ of a package), and then saving them with a booking, is critical. 

If the BookingCenter customer is using a Payment Gateway, then you can request the server 'process' the deposit amount (payment) as part of saving the Booking.  The deposit policy for the specific Rate & Availability will be sent with the OTA_ HotelAvail so doesn't have to be cal;culated by teh developer.  If a deposit/payment is requested by the developer, if we get an authorization, then the server sends back the Booking ID (reference number) and you can be assured the 'payment' was saved with the Booking. The payment will be qued for the next merchnat account 'Batch' and assocaited to the booking.  See: Point of Sale/MyCard (credit cards, hardware, etc.) part of the XML KnowledgeBase to understand the settings for requesting a payment or saving an 'offline' payment a developer may make, and to understand errors with failed deposits/payments.