Дубли броней при обрыве связи
Пользователь нажал кнопку дважды или соединение упало после отправки запроса — создаются две брони. Идемпотентного ключа нет, а провайдер обрабатывает оба запроса.
Booking-платформы
Собираем поиск, бронирование и оплату в один надёжный контур
Подключаем GDS и NDC-каналы, прямые API отелей и наземных перевозчиков, держим корректный кэш availability и защищаем бронь от двойных списаний, оверселлинга и зависших платежей.
Или сразу: +7 (962) 368-39-51 Telegram
GDS+NDC
Amadeus, Sabre, NDC и прямые API
1–2 с
целевой отклик поиска из кэша
идемпотентно
ни одной двойной брони
24/7
очереди, ретраи и мониторинг обменов
Что ломается в системах бронирования
Это не гипотезы: такие дефекты мы находили и устраняли в работающих проектах туроператоров, агентских сетей и OTA.
Кэш availability расходится с провайдером
Остаток в кэше обновляется раз в сутки, поэтому клиент видит место, которого уже нет: оплата проходит, а подтверждение от поставщика не приходит.
Возвраты и обмены считают вручную
У каждого тарифа свои правила: невозвратный, с штрафом за сутки, с удержанием сервисного сбора. Менеджер считает сумму в калькуляторе и ошибается в пользу клиента или компании.
Платежи зависают в промежуточном статусе
Вебхук эквайринга не дошёл, рассрочка одобрена частично, возврат отправлен дважды. Сверка с банком превращается в ручной поиск расхождений за месяц.
Данные пассажиров без учёта требований
Номера документов, даты рождения и контакты лежат в нескольких базах и рассылках, доступ есть у всей смены, сроки хранения не определены. Это прямые вопросы по 152-ФЗ.
Агентская сеть живёт вне системы
Агенты бронируют по телефону, комиссия считается в таблице, а агент не видит свои брони и статусы выплат — отсюда споры и потерянные партнёры.
Из чего состоит платформа
Можно взять весь контур или отдельный слой: например, только постпродажное обслуживание поверх существующего движка бронирования.
Поиск и агрегация предложений
Единая выдача по авиа, отелям, ж/д и трансферам с нормализацией тарифов и правил от разных поставщиков.
- GDS Amadeus и Sabre, NDC-каналы авиакомпаний, прямые API отелей и агрегаторов
- Двухуровневый кэш: горячие направления в Redis, редкие запросы — на провайдера
- Нормализация багажа, правил обмена и возврата к единой модели
- Асинхронная подгрузка источников, чтобы выдача не ждала самого медленного
Движок бронирования и оплаты
Сердце системы: превращаем выбранное предложение в подтверждённую бронь и платёж без дублей и расхождений.
- Идемпотентные ключи на всех шагах: создание брони, оплата, отмена
- Очереди и повторные попытки при отказе провайдера, с журналом каждой попытки
- Эквайринг, оплата частями и рассрочка, разделение платежа на депозит и остаток
- Промокоды, агентская комиссия и правила тарифных семейств
Постпродажное обслуживание
Самая дорогая в обслуживании часть: обмены, возвраты, переписка с поставщиками и перевыпуск документов.
- Расчёт суммы возврата и штрафа по правилам тарифа, а не вручную
- Автоматическая отмена у поставщика с контролем подтверждения
- Частичный возврат по одному пассажиру в мультипассажирской брони
- Журнал обращений и статусов, чтобы клиент видел движение заявки
Back-office и агентская сеть
Рабочее место менеджера, кабинет агента и отчётность, которая закрывает месяц без ручной сверки.
- Личный кабинет агента: свои брони, комиссия, отчёты, акты
- Роли и права: менеджер, старший смены, финансовый контролёр, агент, партнёр
- Выгрузка в 1С, реестры для бухгалтерии, закрывающие документы и ЭДО
- Сверка с эквайером и поставщиками по реестрам, а не по письмам
Как мы запускаем платформу
Интеграции — главный источник неопределённости, поэтому первый этап целиком посвящён им, а не интерфейсу.
-
01 2–3 недели
Карта интеграций и данных
Разбираем, что продаём и у кого покупаем: какие GDS и NDC-каналы, какие прямые договоры, кто источник истины по остаткам и ценам. Проверяем песочницы и лимиты запросов.
-
02 6–10 недель
Ядро брони и поиска
Собираем модель предложения, кэш availability, идемпотентный сценарий создания брони и обработку отказов поставщика. На этом этапе появляется первый сквозной сценарий покупки.
-
03 4–8 недель
Оплата, документы и постпродажа
Подключаем эквайринг и рассрочку, реализуем возвраты и обмены, выгрузки в 1С и ЭДО, кабинет агента и роли. Закрываем юридически значимый документооборот.
-
04 3–4 недели
Нагрузка и вывод в прод
Прогоняем высокий сезон на нагрузочном стенде, настраиваем мониторинг обменов и алерты, запускаем пилотную группу и затем открываем трафик.
Как мы работаем с GDS и NDC
GDS остаётся основой для сложных маршрутов и корпоративных сегментов, но экономика всё чаще уходит в NDC: у авиакомпаний там шире набор тарифных опций и нет исторического сбора. Мы проектируем слой поставщиков как набор адаптеров с единым внутренним контрактом, поэтому добавление нового канала не требует переписывать поиск и бронирование.
Практическая часть важнее архитектурной схемы: у каждого канала свои лимиты запросов, окна обслуживания и формат ошибок. Мы закладываем деградацию — если NDC-канал не ответил за отведённое время, выдача собирается из остальных источников и помечается, что часть предложений могла не попасть в результат.
Почему идемпотентность бронирования важнее скорости
Классический сценарий: клиент нажимает «Забронировать», запрос уходит в GDS, ответ приходит через 12 секунд, браузер к этому моменту уже отправил повтор. Без идемпотентного ключа создаются две брони, одну из которых придётся отменять со штрафом. Стоимость такой ошибки несопоставима с экономией на оптимизации запроса.
Мы используем ключ идемпотентности, генерируемый на стороне клиента и сохраняемый вместе с состоянием операции: повторный запрос с тем же ключом возвращает результат первой попытки, а не создаёт новую бронь. Тот же принцип применяем к платежам, возвратам и любым операциям, которые меняют деньги или остатки.
Кэш availability: где экономия времени превращается в отказ
Обращаться к GDS на каждый поисковый запрос невозможно: лимиты и стоимость запросов делают такой сценарий нерентабельным. Поэтому остатки и цены кэшируются. Вопрос в том, как долго и что делать, когда данные устарели.
Мы разделяем кэш на слои: короткий TTL для горячих дат, длинный — для дальних направлений, отдельное правило для последних мест. Никогда не продаём из кэша напрямую: перед созданием брони выполняется revalidation у поставщика, а разница в цене или отсутствие места показывается пользователю как понятное предложение альтернативы, а не как техническая ошибка на этапе оплаты.
Частые вопросы
Минимальный рабочий продукт с одним-двумя каналами поставщиков, поиском, бронированием, оплатой и базовым back-office занимает от четырёх до шести месяцев. Полноценная платформа с несколькими GDS, прямыми API отелей, агентской сетью, возвратами и выгрузками в 1С — от девяти месяцев. Срок сильнее всего зависит от готовности договоров с поставщиками и доступа к их тестовым контурам.
Да, и часто так и стоит делать. Если у вас есть прямые договоры с отелями или наземными перевозчиками, первый релиз можно собрать на их API — это быстрее и дешевле, а GDS добавить вторым этапом. Архитектура с набором адаптеров поставщиков позволяет подключить GDS позже без переписывания поиска.
Такие ситуации мы обрабатываем как отдельный класс состояний. Бронь переходит в статус ожидания оплаты с ограниченным таймаутом, система автоматически пытается провести платёж повторно по расписанию и уведомляет менеджера. Если оплата не поступила до дедлайна, запускается автоматическая отмена у поставщика, чтобы не получить штраф за невыкупленное место.
Мы проектируем хранение документов и контактов в отдельном защищённом контуре с ограниченным доступом по ролям, шифрованием чувствительных полей и журналом обращений. Определяем сроки хранения, порядок удаления по требованию и объём данных, который реально нужен поставщику, чтобы не передавать лишнее. Это соответствует требованиям 152-ФЗ к обработке персональных данных.
TravelTech: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Нужна платформа бронирования?
Расскажите, какие каналы продаж и поставщиков у вас уже есть, — предложим архитектуру и реалистичный график по этапам.