Разделы и статьи

Как каналу продавать ранний заезд и поздний выезд через Partner API

1. Реализуйте доработку на тестовой среде https://partner.qatl.ru/docs/booking-process/.

2. Самостоятельно протестируйте доработку по всем пунктам чек-листа ниже. Для пунктов 1, 2, 4 и 5 чек-листа требуется создание скриншотов, демонстрирующих успешную реализацию и работоспособность. Для пунктов 3 и 6 скриншоты не требуются.

3. Запишите видеоролик, показывающий процесс бронирования раннего заезда или позднего выезда. Бронирование должно соответствовать диаграмме:

 

4. Отправьте подготовленные скриншоты и ссылку на сайт проекта, где доступно бронирование с возможностью продажи раннего заезда или позднего выезда за дополнительную плату, на электронную почту: partner_ota_dynamic_dev@travelline.ru

5. Мы проведем сертификацию в течение 5 рабочих дней. В случае нереализации или неполадок хотя бы в одном из пунктов чек-листа, потребуется дополнительная доработка.

6. После успешной сертификации, в течение 2 рабочих дней, мы активируем для вас функционал, позволяющий работать с правилами раннего заезда или позднего выезда на продуктовой среде.

7. Самостоятельно проинформируйте отели о новой возможности.

 

Чек-лист для тестирования продажи раннего заезда или позднего выезда на сайте OTA

На тестовой среде у средства размещения id 8616 (PartnerAPI для сертификации РЗПВ) настроены различные правила раннего заезда или позднего выезда для настройки и тестирования интеграции

1. При поиске раннего заезда или позднего выезда в рамках одного объекта размещения должна отображаться полная информация: период раннего заезда или позднего выезда, стоимость, валюта.

2. Во время поиска должно обеспечиваться отсутствие дублирующих периодов раннего заезда или позднего выезда. На тестовой среде у тестового объекта размещения все варианты услуг уникальны.

Чтобы проверить корректность выдачи правил в API, отправьте запрос с поиском услуг на два взрослых и одного ребенка 5 лет.

Запрос:

 

Response в API

Возможное отображение ответа API в канале

  

 

 

 

3. Перед шагом оплаты необходимо вызвать метод /bookings/verify. В ответе на этот запрос, значение checksum изменится из-за включения раннего заезда или позднего выезда в бронь. После осуществления оплаты нужно вызвать метод создания бронирования, где проводится проверка корректности checksum.

4. Информация об обновленной стоимости бронирования должна быть представлена гостю на стороне канала продаж перед шагом оплаты, если в бронь были добавлены правила раннего заезда или позднего выезда.

5. Должна быть предусмотрена возможность отмены бронирования. При отмене активируется метод calculate-cancellation-penalty, который корректно отображает условия отмены на текущую дату, включая стоимость раннего заезда или позднего выезда, входящих в предоплату.

6. Необходимо обеспечить корректную передачу данных в API, которые указываются при формировании запроса на создание бронирования.

Система управления для отелей и хостелов

Управляйте отелем в АСУ — следите за бронями, номерами и доходом, просматривайте удобные отчеты и работайте с шахматкой везде, где есть интернет.
Узнать больше
Система управления для отелей и хостелов