Технічні вимоги до організації взаємодії веб-систем Яндекса і Замовника для надання Замовником Матеріалів

1. Схема взаємодії при отриманні Матеріалів

Загальна схема роботи:

1. Користувач просить у сервісу Яндекс.Авіаквитки варіанти перельотів між двома пунктами на вибрану дату.

2. Сервіс Яндекс.Авіаквитки надсилає запит (GET або POST) до веб-сайту Замовника за адресою, передаючи параметри:

2.1. departure ─ IATA або Сирена-код пункту відправлення;

2.2. arrival ─ IATA або Сирена -код пункту прибуття;

2.3. date _ forward ─ дата прямого вильоту у форматі YYYY ─ MM ─ DD;

2.4. date _ backward ─ дата зворотного вильоту у форматі YYYY ─ MM ─ DD (може бути відсутнім);

2.5. class ─ клас обслуговування, наприклад, E ─ економ або B ─ бізнес;

2.6. adult ─ кількість дорослих пасажирів;

2.7. child ─ кількість дітей (може бути відсутнім);

2.8. infant ─ кількість немовлят без місця (може бути відсутнім).

3. Веб-сайт Замовника повертає XML такого формату з інформацією про місця та ціни.

Наприклад:

<variant

url = "[адреса]" // url для перенаправлення користувача на веб-сайт Замовника

>

<route _ forward

route _ code = "0123АБ" // номер рейсу

company _ code = "BL" // код авіакомпанії

company _ name = "Blah-air" // назва авіакомпанії

departure _ airport _ code = "DME" // код аеропорту вильоту

arrival _ airport _ code = "SVO" // код аеропорту прибуття

departure _ datetime = "2011-04-01 18:12" // дата-час відправлення (локальний час)

arrival _ datetime = "2011-04-01 21:20" // дата-час прибуття (локальний час)

route _ time = "123" // час у дорозі у хвилинах

farecode="WFLOWCS" // код тарифу

tariff_adult = "80.00" // тариф для дорослих, якщо вони присутні у запиті

tariff_child = "60.00" // тариф для дітей, якщо вони присутні у запиті

tariff_infant = "3.45" // тариф для немовлят без місця, якщо вони присутні у запиті

/>

...

<route _ backward

route _ code = "0123АБ" // номер рейсу

company _ code = "BL" // код авіакомпанії

company _ name = "Blah-air" // назва авіакомпанії

departure _ airport _ code = "DME" // код аеропорту відправлення

arrival _ airport _ code = "SVO" // код аеропорту прибуття

departure _ datetime = "2011-04-01 18:12" // дата-час відправлення (локальний час)

arrival _ datetime = "2011-04-01 21:20" // дата-час прибуття (локальний час)

route _ time = "123" // час у дорозі у хвилинах

farecode="WFLOWCS" // код тарифу

tariff_adult = "80.00" // тариф для дорослих, якщо вони присутні у запиті

tariff_child = "60.00" // тариф для дітей, якщо вони присутні у запиті

tariff_infant = "3.45" // тариф для немовлят без місця, якщо вони присутні у запиті

/>

...

<fare

value = "123.45" // ціна (мінімальна ціна) у цьому класі обслуговування

class = "E" // код класу обслуговування

charter = «true|false» //ознака чартерного тарифу

block = «true|false» //ознака блокового тарифу

currency = "UAH" // валюта

/>

</variant>

...

Вся інформація про переліт, використана у прикладі вище, є обов'язковою для відповіді відповідно до запитаних типів пасажирів.

Вартість окремих сегментів перельоту необхідно передавати в усіх випадках, коли тариф це дозволяє.

4. Блок variant повторюється для кожної пропозиції щодо бронювання у заданому класі обслуговування. У кожному блоці variant є один або кілька підблоків route _ forward та route _ backward, що містять інформацію про сегменти перельоту туди і назад відповідно.

5. Якщо зворотну дату не зазначено, повертаються пропозиції тільки в один бік. При цьому у блоках variant містяться лише підблоки route _ forward.

6. Рекламно-інформаційні матеріали Замовника, що надійшли після 20 секунд очікування, або після переривання часу очікування Користувачем, не будуть розміщені. Такі матеріали, що надійшли в період часу від 20 секунд до 2 хвилин, будуть збережені і відображені без повторного запиту до Замовника до закінчення часу актуальності кеша.

7. Замовники, які використовують GDS «Сирена-тревел», повинні відповідати на запити з внутрішніми кодами, що використовуються в даній GDS.

8. Замовник зобов'язується використовувати захищений протокол передачі даних – https на своєму сайті при переході з сервісу Яндекс.Авіаквитки.

9. Замовник зобов'язується інформувати Яндекс про перехід на новий протокол надання Інформації не менш ніж за 30 (тридцять) календарних днів до реалізації переходу.

10. Звіт про кількість і загальну вартість придбаних Користувачами авіаквитків у результаті їх переходу з веб-сторінок сервісу Яндекс.Авіаквитки, надається Замовником відповідно до пункту 3.3.9 Договору, має бути наданий у форматах xsl/xlsx або csv.

11. Для обмеження запитів за напрямками можливо підключити регіоналізацію. Для цього потрібно надіслати посилання на csv-файл формату: пари з IATA та/або Сирена кодів міст/аеропортів по одній в кожному рядку через «;».

Кожна пара запитує дозвіл на опитування за напрямками в обидві сторони.

Наприклад:

ATH;CMB

ATH;DXB

GBB;GOI

GPA;HAV

HER;KLX

KVD;LCA

LIS;LLK

LWN;MAD

MLE;NAP

СХТ;RHO

СХТ;СПТ

Дані збираються з періодичністю раз на добу.

2. Схема взаємодії при переході до продажу

Перехід із сервісу Яндекс.Авіаквитки на веб-сайт Замовника здійснюється таким чином:

1. Користувач вибирає пропозицію і натискає на посилання (вартість авіаційного квитка, що міститься у Матеріалі, зазначену у рублях або у відповідній національній валюті (згідно з вимогами Загальних умов)), на сервісі Яндекс.Авіаквитки.

2. Користувач перенаправляється на веб-сайт Замовника за адресою, отриманою у відповіді у полі url блоку variant для цієї пропозиції.

3. Користувач на веб-сайті Замовника починає процес бронювання:

3.1. На веб-сайті Замовника повинна здійснюватися автоматична перевірка можливості забронювати пропозицію, яку Користувач вибрав на сервісі Яндекс.Авіаквитки (перевірка повинна здійснюватися до того, як Користувач на веб-сайті Замовника починає процес бронювання);

3.2. Якщо вибраний Користувачем варіант бронювання недоступний, Користувачеві має показуватися відповідне інформаційне повідомлення і повинні пропонуватися інші варіанти, що відповідають параметрам пошуку Користувача;

3.3. Якщо вибраний Користувачем варіант бронювання доступний, повинна відображатися сторінка із докладною інформацією про вибраний варіант бронювання і пропозицією ввести дані про пасажирів для бронювання. На сторінці також повинні виконуватися такі умови:

  • Вартість авіаційного квитка при оплаті банківською карткою у мережі інтернет, що відображається на сторінці, повинна повністю відповідати вартості, наданій Замовником у Матеріалах: бути розміщеною на видному місці і візуально відокремленою від інших можливих пропонованих Замовником варіантів.

  • В описі обраного варіанту бронювання повинна міститися вичерпна інформація про застосовні до цього квитку норми перевезення багажу і ручної поклажі. Ці дані повинні бути доступні на цій же сторінці і не можуть перебувати в прихованих за замовчуванням блоках.

3.4. У разі, якщо Замовник разом з авіаційними квитками пропонує Користувачеві на веб-сайті Замовника додаткові послуги, Замовник зобов'язується надати Користувачеві можливість вибрати такі додаткові послуги на веб-сайті Замовника самостійно. Усі додаткові послуги повинні бути запропоновані до вводу даних банківської картки Користувача. До згоди Користувача додаткові послуги не повинні додаватися до вартості авіаційного квитка.

4. У випадку, якщо Користувач на веб-сайті Замовника починає процес бронювання і за вибраним варіантом потрібне підтвердження від Замовника, повинні виконуватися такі вимоги:

  • Для авіаційних квитків, що вимагають ручного підтвердження, повинна здійснюватися автоматична відповідь із зазначенням термінів остаточного підтвердження.

  • Термін остаточної відповіді про наявність вибраної пропозиції та її вартості повинен становити не більше 1 робочого дня.

  • Користувач має бути проінформованим у разі, якщо пропозиція не підтверджується.

5. Замовник зобов'язується не передавати Матеріали у відповідь на запит сервісу Яндекс.Авіаквитки у таких випадках:

5.1. Якщо параметри, описані в цьому документі, під час отримання Матеріалів відображаються на веб-сайті Замовника не повністю.

5.2. Якщо веб-сайт Замовника за адресою, отриманою у відповіді, згідно з п. 2. Схеми взаємодії під час переходу до продажу не завантажується і видає повідомлення про помилку.

5.3. Із будь-яких технічних та інших причин, що не дозволяють Користувачеві перейти на сторінку із докладною інформацією про вибраний варіант (згідно з п. 3.3 цього документа) і завершити процес купівлі на веб-сайті Замовника.

6. У разі виявлення технічних проблем Замовник зобов'язаний негайно сповістити представників сервісу Яндекс.Авіаквитки поштою avia-info@yandex-team.ru. При надходженні запиту від Яндекс.Авіаквитків Замовник зобов'язується протягом трьох годин відповісти на звернення і в найкоротші терміни надати всю технічну інформацію, необхідну для діагностики та вирішення проблем.

7. Далі процес купівлі повинен тривати відповідно до технології, прийнятої на веб-сайті Замовника.

 

_____________________________

Дата розміщення: 11.11.2016 р.

Дата набуття чинності: 11.11.2016 р.

Попередня версія документа: https://yandex.ua/legal/airplane_timetable_requirements/06102016/

Попередня версія документа: https://yandex.ua/legal/airplane_timetable_requirements/25072016/.

Попередня версія документа: https://yandex.ua/legal/airplane_timetable_requirements/05042016/.

Попередня версія документа: https://yandex.ua/legal/airplane_timetable_requirements/25012016/.

Попередня версія документа: https://yandex.ua/legal/airplane_timetable_requirements/15122015/.