Архитектурный якорь и бизнес-модель платформы

Версия: 2.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа

Этот документ — расширенное обоснование выбора архитектурного якоря (architectural anchor) платформы и формальное описание бизнес-модели, цепочки ответственности, географии первой волны и динамической тарификации платформенных услуг.

Документ читается после главной архитектурной оси и манифеста переосмысления. Здесь детализируется то, что в этих двух документах зафиксировано тезисно.

Краткая формулировка позиционирования (elevator pitch)

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором концепция платформы была охарактеризована формулировкой «Промышленный радикализм — попытка построить Stripe в мире Travel». Эта формулировка точно передаёт замысел и принимается как каноничное краткое позиционирование платформы для всех внешних коммуникаций.

Каноничный elevator pitch

Vitiana — это платформа-инфраструктура для туристической индустрии, построенная по модели верхнеуровневых программных платформ (Stripe, Twilio, Algolia, Cloudflare).

Что это значит на практике:

• Не агрегатор-посредник. Vitiana не «перепродаёт услуги поставщиков» — она даёт партнёрам программный интерфейс, через который они строят собственные туристические продукты.
• Не сайт-витрина. Витрина vitrip.store существует как демонстрация возможностей платформы, не как её основной продукт. Главный продукт — программный интерфейс, потребляемый агентствами, корпоративными службами путешествий и партнёрами white-label.
• Не легаси-OTA. Архитектура с нулевого дня опирается на современные паттерны верхнеуровневых платформ: канонические доменные модели вместо database-coupled API, событийная шина с гарантиями доставки, динамическая тарификация по потреблению вместо commission-based модели, ML-первый approach, isolation strength как product feature.

Vitiana думает Offer-ами и Quote-ами, не «комнатами» — это позволяет строить Tour Builder (компонуемый туристический продукт из множества segment'ов) как ядро платформы, не как надстройку над hotel search engine.

Что обещает Stripe-модель партнёру

В обмен на использование платформы партнёр получает:

1. Один программный интерфейс на множество поставщиков — нормализованная каноничная модель освобождает партнёра от интеграции с каждым supplier'ом отдельно.
2. Динамическая тарификация по потреблению — партнёр платит за реально использованные ресурсы (запросы, бронирования, supplier-вызовы), не commission с маржи.
3. Финансовые гарантии и compliance-обеспечение — insolvency protection, GDPR, EU TOMS VAT, Package Travel Directive — на стороне платформы.
4. Стабильный контракт с явной политикой версий — партнёрский код, написанный сегодня, продолжит работать через 2 года при условии следования migration policy.
5. Self-service партнёрский опыт — регистрация, песочница, сертификация, ротация ключей, потребление, журналы аудита — всё через partner console без обращения в support.
6. ML-driven optimizations на стадиях зрелости платформы — ranking, dynamic pricing, fraud detection, recommendation как платформенные фичи.

Что НЕ обещает Stripe-модель

Чтобы избежать неправильных ожиданий:

• Vitiana не управляет конечными клиентами партнёра. Брендинг, customer relationships, marketing — на стороне партнёра.
• Vitiana не пишет контент за партнёра. Описание property и его презентация в партнёрской витрине — выбор партнёра, платформа предоставляет только supplier content и canonical model.
• Vitiana не гарантирует доступность конкретного supplier'а — supplier'ы подключаются и отключаются по их собственным contractual reasons; партнёрский код должен быть подготовлен к ротации supplier-сети.

Позиционирование для разных аудиторий

Аудитория	Краткое позиционирование
Технический партнёр / интегратор	«Stripe для travel — один API, normalised inventory, idempotent operations, semantic versioning»
Бизнес-партнёр / агентство	«Платформа, на которой вы строите свой туристический продукт без интеграционной боли и без commission-зависимости»
Корпоративный заказчик	«Compliance-ready инфраструктура для travel programs с insolvency protection и multi-region SLA»
Инвестор	«Travel-tech инфраструктура с unit-economics на основе потребления, а не commission, с monetization-axis независимой от supplier margins»
Регулятор	«Каноничная merchant-of-record платформа с явной liability chain, GDPR-by-design, full audit trail»

Эта табличка — рекомендация для коммуникаций; точные формулировки зависят от контекста и языка.

Обоснование (тезисы)

Тезис 1. Краткое позиционирование «Stripe в travel» — точно передаёт каноничную модель.

Альтернативы: (а) описывать платформу через её продуктовые компоненты («B2B API + B2C витрина + Tour Builder»); (б) описывать через бизнес-модель («multi-supplier OTA с partner program»); (в) краткое архитектурное позиционирование («верхнеуровневая программная платформа для travel»).

Trade-off: варианты (а) и (б) описывают что делает платформа, но не как. Вариант (в) точнее передаёт архитектурный замысел и сразу отделяет нас от legacy travel-агрегаторов в восприятии аудитории — за счёт известного reference point (Stripe).

Тезис 2. Каноничное позиционирование должно быть зафиксировано в anchor-документе.

Альтернативы: (а) каждая команда формулирует позиционирование на свой манер; (б) единое каноничное позиционирование, фиксированное в anchor-документе, используется во всех внешних коммуникациях.

Trade-off: вариант (а) приводит к фрагментации сообщения и путанице партнёров; вариант (б) — каноничный для зрелой платформы, обеспечивает consistent voice.

Главное решение

Архитектурный якорь: маркетплейс программных интерфейсов для бизнес-клиентов (B2B API marketplace).

Это означает: при любом конфликте между направлениями развития (приоритет инвестиций, темп реализации, спорные доменные решения) приоритет получает то направление, которое ближе к маркетплейсу программных интерфейсов.

При этом все четыре направления сохраняются в зрелой архитектуре. Якорь — это порядок инвестиций и приоритетов, не исключение направлений.

Тезисное обоснование выбора якоря

Цель

Выбрать одно главное (primary) направление монетизации, вокруг которого выстраиваются архитектурные приоритеты, инвестиционные решения и порядок выпуска документного слоя. Без выбора якоря платформа застревает в попытках развивать четыре направления параллельно, что нереализуемо никакой реалистичной командой.

Тезисы поддержки выбора маркетплейса программных интерфейсов

Тезис 1. Самая высокая верхняя граница рынка (total addressable market, TAM). Туристическая индустрия движется к дистрибуции через программные интерфейсы (API distribution). Каждый средний и крупный туристический агрегатор, онлайн-тревел-агентство (online travel agency, OTA), метапоиск (metasearch), корпоративная система туризма (corporate travel system), витрина под партнёрским брендом (white-label travel storefront) — потенциальный потребитель агрегационного интерфейса. Это десятки тысяч возможных тенантов (tenants). Маркетплейс программных интерфейсов имеет наибольший верхний потолок монетизации.

Тезис 2. Самая высокая маржинальность. Маркетплейс программных интерфейсов продаёт доступ к платформенному слою, а не отдельные туры. Маржа на платформенный доступ выше, чем маржа на туристический продукт (которая ограничена сверху ценой поставщика). Партнёр платит за нашу нормализацию, контроль качества (governance), поисковую проекцию (search projection), фиксацию промежуточных коммерческих обещаний (quote fixation), а не за «найденный отель».

Тезис 3. Самая защищённая позиция от прямой конкуренции. Booking.com и аналоги — конкуренты в потребительском сегменте (B2C) и в работе с агентствами (B2B agency). В сегменте маркетплейса программных интерфейсов их нет в роли сильных игроков (их интерфейсы предназначены для крупных корпоративных контрактов, а не для свободного доступа). Vitiana как открытый маркетплейс программных интерфейсов со свободной средой тестирования (sandbox) занимает позицию, которую трудно скопировать существующим онлайн-тревел-агентствам без перестройки бизнес-модели.

Тезис 4. Усиление через сетевой эффект (network effect). Чем больше партнёров в маркетплейсе, тем выше переговорная сила перед поставщиками, тем больше покрытие поставщиками (supplier coverage), тем привлекательнее интерфейс для новых партнёров. Сетевой эффект работает в маркетплейсе программных интерфейсов сильнее, чем в потребительской витрине одного бренда.

Тезис 5. Архитектура маркетплейса программных интерфейсов естественно охватывает остальные направления. Если архитектура построена для маркетплейса программных интерфейсов (с чистой каноничной моделью, видимостью с учётом поверхностей взаимодействия, динамическим ценообразованием, прочной тенантной изоляцией) — она автоматически поддерживает:

• собственные сайты vitrip.store как демонстрацию возможностей платформы (один из тенантов на собственном интерфейсе);
• платформу для агентств как ещё одного тенанта с другим набором возможностей;
• расширенные потребительские витрины как тонкий слой над платформенным интерфейсом.

Обратное не работает: архитектура, оптимизированная под потребительскую витрину, не масштабируется до маркетплейса программных интерфейсов без переписывания.

Тезис 6. Динамическое ценообразование платформенных услуг работает только в маркетплейсе программных интерфейсов. Плата за поисковые запросы, коммерческие фиксации (quotes), бронирования, ML-инференс, бюджет вызовов поставщиков (supplier-call budget) — это структура тарификации доступа к платформе. В потребительской витрине эта структура невидима для конечного клиента. В маркетплейсе программных интерфейсов это центральный коммерческий продукт.

Тезис 7. Реальное состояние реализации совместимо с этим выбором. Текущий вид платформы имеет работающий эндпоинт (endpoint) для поставщика Stuba — https://api.vitrip.store/stuba. Это первая итерация слоя приёма данных (ingestion), а также первый прототип внешнего интерфейса (хотя ещё не готовый к статусу партнёрской поверхности — Partner API Surface). Разворачивать реальный маркетплейс программных интерфейсов вокруг каноничной модели — естественное продолжение того, что уже есть.

Альтернативы и почему они отклонены

Альтернатива А. Расширенные потребительские витрины (B2C broader storefronts) как главное направление. Отклонено по следующим причинам:

• экономика конверсии (conversion economics) в потребительском сегменте жёстко конкурирует с Booking.com, Expedia, Trivago — компаниями с массивными бюджетами на маркетинг и брендом;
• маржа в потребительском сегменте ограничена сверху ценой поставщика;
• архитектура с приоритетом потребительского сегмента не масштабируется до маркетплейса программных интерфейсов без переписывания;
• vitrip.store сохраняется как собственный канал и демонстрация, но не как главный якорь.

Альтернатива Б. Платформа для агентств (B2B agency platform) как главное направление. Отклонено по следующим причинам:

• рынок туристических агентств в Восточной Европе ограничен (оценочно несколько тысяч активных агентств в UA + CZ + PL + KZ);
• каждое агентство — низкобюджетный клиент;
• маржа на инструменты для агентств ниже, чем на платформенный доступ через программный интерфейс;
• архитектура для платформы агентств не охватывает естественно модель партнёрской интеграции.

Альтернатива В. Каноничный инвентарный хребет (canonical inventory backbone) как главное направление. Отклонено по следующим причинам:

• каноничный инвентарь без потребителя — это не продукт, а заготовка продукта;
• без потребителя нет обратной связи через выручку (revenue feedback loop), что разрушает экономическую модель платформы;
• каноничный инвентарь — это компонент маркетплейса программных интерфейсов, а не самостоятельный продукт.

Альтернатива Г. Параллельное развитие всех четырёх направлений как главных. Отклонено по следующим причинам:

• ни одна реалистичная команда не способна параллельно развивать четыре первичных направления с полной зрелостью;
• разные направления требуют разных приоритетов архитектуры (потребительский — конверсия и задержка отклика; маркетплейс программных интерфейсов — стабильность контракта и удобство разработчика; агентства — насыщенный рабочий интерфейс; каноничный инвентарь — покрытие поставщиками);
• параллельное развитие создаёт постоянные компромиссы между направлениями, не позволяя ни одному достичь зрелости.

Принимаемые компромиссы

• Долгий цикл продаж (sales cycle) маркетплейса программных интерфейсов. Партнёрские интеграции — это месяцы переговоров, юридического оформления, технической интеграции. Компенсируется тем, что один партнёр может приносить значительный объём выручки.
• Высокие требования к стабильности контракта (contract stability) с самого начала. Одно ломающее изменение (breaking change) в партнёрской поверхности интерфейса (Partner API Surface) может стоить нескольких партнёров. Компенсируется строгой версионной дисциплиной и совместимостью.
• Необходимость экосистемы для разработчиков (developer ecosystem). Среда тестирования (sandbox), пакеты средств разработки (software development kits, SDK), примеры кода, поток сертификации (certification flow) обязательны со второй фазы. Компенсируется тем, что эти инвестиции окупаются за счёт самообслуживания партнёров.

Все четыре направления в зрелой архитектуре

Направление 1. Маркетплейс программных интерфейсов для бизнес-клиентов (главное направление)

Что: платный доступ к каноничной модели, поисковой проекции, программному интерфейсу конструктора туров (Tour Builder API), системе бронирования и сопутствующим возможностям через партнёрскую поверхность взаимодействия (Partner API Surface).

Кто потребитель: агрегаторы нижнего уровня (downstream aggregators), интеграторы для бизнес-клиентов, витрины под партнёрским брендом (white-label travel systems), корпоративные системы туризма, метапоиски, конкурирующие онлайн-тревел-агентства, использующие наш программный интерфейс в качестве дополнительного источника инвентаря.

Главная коммерческая модель: динамическая тарификация по нагрузке (см. часть «Динамическая тарификация»).

Тарифные уровни: бесплатный (Free) / стартовый (Starter) / профессиональный (Professional) / корпоративный (Enterprise). Детализация — в платформе как продукте и в reference/api-as-product.md фазы 4.

Соответствующая поверхность взаимодействия: партнёрская поверхность интерфейса (Partner API Surface) и закрытая поверхность конструктора туров (Tour Builder Closed Surface) для тарифов с конструктором туров.

Направление 2. vitrip.store — собственный канал и демонстрация

Что: собственная потребительская витрина платформы. Vitiana продаёт туристические продукты от своего имени конечным клиентам.

Двойная функция:

1. Демонстрация (demonstration) — публичный пример того, что можно построить на платформе. Партнёры, рассматривающие интеграцию, видят живой работающий пример.
2. Собственный канал — реальная выручка от прямых продаж с собственной маржой платформы.

Главная коммерческая модель: маржа платформы на туристических продуктах (стандартная потребительская модель агрегатора).

Соответствующая поверхность взаимодействия: потребительская витрина (B2C Storefront Surface).

Архитектурно: vitrip.store — обычный тенант на собственном программном интерфейсе. Это означает, что никаких архитектурных привилегий vitrip.store не получает. Та же каноничная модель, те же контракты, те же правила поверхностей. Это и есть правильная демонстрация: партнёр видит, что vitrip.store построен на тех же возможностях, что доступны и ему.

Направление 3. Рабочая платформа для туристических агентств (быстрый последователь, fast-follower)

Что: рабочее место для туристических агентств. Поиск, коммерческая фиксация (quote), бронирование, конструктор туров, контекст клиента (customer context), отчётность в пределах агентства (agency-scoped reporting).

Кто потребитель: туристические агентства первой волны географии (UA, CZ, PL, KZ); расширение в широкую Европу (EU broader) на четвёртой фазе.

Главная коммерческая модель: подписка (subscription) + комиссия с продаж + опциональный платный доступ к конструктору туров.

Соответствующая поверхность взаимодействия: рабочая поверхность для агентств (Agency Working Surface).

Когда разворачивается: после стабилизации партнёрской поверхности интерфейса (фазы 2–3). До этого поверхность для агентств существует как концепция.

Архитектурно: платформа для агентств — это другая категория тенантов на той же платформе, с агрегированными возможностями.

Направление 4. Расширенные потребительские витрины (планомерное расширение, sustained expansion)

Что: расширение собственных каналов продаж — мобильное приложение, дополнительные витрины под подбренды, витрины под партнёрским брендом для крупных партнёров.

Кто потребитель: конечные клиенты в расширенной географии; партнёры, которые предпочитают решение под их собственным брендом (white-label) собственной интеграции.

Главная коммерческая модель: комбинация потребительской маржи и комиссии за решение под партнёрским брендом.

Соответствующая поверхность взаимодействия: потребительская витрина (B2C Storefront Surface) с расширениями под решения под партнёрским брендом.

Когда разворачивается: фазы 3–4 после зрелости платформенного ядра.

Цепочка ответственности (merchant-of-record chain)

Платформа Vitiana — классический агрегатор с гибридной моделью отвечающего за платежи продавца (merchant-of-record, MoR) для каждого тенанта (per-tenant). Цепочка обязательств:

Каноничная цепочка:

   Поставщики (suppliers)
      ↑ инвентарь, цена, обещание исполнения
   Платформа Vitiana
      ↑ нормализация, ответственность перед поставщиком, governance, частичная ответственность
   Наши клиенты (агентства, партнёры с платным доступом, собственные каналы)
      ↑ доступ к платформе, ответственность перед своими клиентами
   Конечные клиенты партнёров (end customers)
      ↑ оплата, потребление туристического продукта

Как читать цепочку

• Платформа отвечает перед поставщиками за корректное представление их инвентаря и условий, своевременное прохождение бронирований, корректные взаиморасчёты (settlement).
• Платформа отвечает перед своими клиентами (агентствами, партнёрами, собственными каналами) за каноничную модель, доступность платформенного программного интерфейса, целостность данных, договорные обязательства тарифа.
• Наши клиенты отвечают перед своими конечными клиентами за своё представление продукта, маркетинг, обслуживание клиентов (customer service), приём платежей (payment processing) — если они выступают отвечающим за платежи продавцом, — а также за консультации.
• Конечные клиенты отвечают перед нашими клиентами за оплату, корректные данные при бронировании, соблюдение условий поставщика.

Гибрид по тенантам: разные тенанты — разные модели отвечающего за платежи продавца

Платформа поддерживает разные модели отвечающего за платежи продавца для разных тенантов:

Модель А. Платформа сама отвечающий за платежи продавец. Применяется для собственного канала vitrip.store, для агентств с самым простым тарифом без собственной платёжной интеграции. Платформа принимает платежи от конечного клиента, выпускает квитанцию (receipt), проводит обработку возвратных платежей (chargeback handling), перечисляет долю поставщику и комиссию агентству.

Модель Б. Партнёр сам отвечающий за платежи продавец. Применяется для крупных партнёров с собственной платёжной системой. Партнёр принимает платежи от своих конечных клиентов, выпускает квитанцию от своего имени, проводит обработку возвратных платежей. Платформа выставляет партнёру счёт за платформенные услуги (динамическая тарификация) и отдельно за стоимость инвентаря (передача без наценки от поставщика, passthrough).

Модель В. Гибрид с разделением по продукту. Применяется для случаев, когда тенант сам выступает отвечающим за платежи продавцом для отдельных продуктов, а для других — платформа выступает отвечающим за платежи продавцом. Например, для туров (ответственность по Директиве ЕС о пакетных турах, Package Travel Directive) — платформа выступает отвечающим за платежи продавцом; для отдельных бронирований отелей — тенант выступает отвечающим за платежи продавцом.

Точная модель для каждого тенанта фиксируется при настройке тенанта. См. настройку и активацию тенанта. Углубление — в reference/multi-tenant-isolation-strength.md фазы 5.

Следствия для соответствия нормативам

Цепочка отвечающих за платежи продавцов прямо влияет на:

• GDPR (общее регулирование защиты данных, EU 2016/679) — кто контроллер данных (data controller), кто обработчик данных (data processor); список субподрядчиков обработки (sub-processor list); соглашение об обработке данных (Data Processing Agreement, DPA) между платформой и тенантом.
• Директива о пакетных турах (Package Travel Directive, EU 2015/2302) — если тенант продаёт «пакет» (≥2 компонентов), платформа или тенант — кто организатор пакетного тура (package travel organiser); требование защиты от неплатёжеспособности (insolvency protection).
• Стандарт безопасности данных платёжной индустрии (Payment Card Industry Data Security Standard, PCI DSS) — кто принимает платёж, тот определяет область применимости PCI (PCI scope).
• Налог на добавленную стоимость и схема маржи туроператоров (VAT, Tour Operators' Margin Scheme в EU) — обязательства по налогу на добавленную стоимость зависят от модели отвечающего за платежи продавца.
• Противодействие отмыванию денег и идентификация клиента (anti-money laundering and know your customer, AML/KYC) — для модели расчёта по кредитной линии партнёра.
• Закон о цифровых услугах ЕС и Директива об административном сотрудничестве 7 (Digital Services Act, DSA, и Directive on Administrative Cooperation 7, DAC7) — обязательства онлайн-платформ по отчётности.

Полное раскрытие — в reference/compliance-and-legal.md фазы 4.

География первой волны и план расширения

Первая волна: Восточная Европа и Казахстан

Страны: Украина (UA), Чехия (CZ), Польша (PL), Казахстан (KZ).

Тезисы выбора:

1. Близость к Vitiana по операционному пониманию рынка.
2. Низкая конкуренция со стороны крупных европейских и глобальных платформ в сегменте партнёрского программного интерфейса.
3. Существующее покрытие поставщиками (Stuba имеет хорошее покрытие Европейского Союза; HomeToGo расширяет покрытие; добавление поставщиков для Казахстана через 2-ю и 3-ю фазу).
4. Частичная юрисдикция Европейского Союза (Чехия + Польша) даёт основание для базового соответствия общему регулированию защиты данных; Украина и Казахстан — отдельные регуляторные режимы, не блокируют запуск.

Базовый набор валют (multi-currency baseline):

• украинская гривна (UAH);
• евро (EUR — общая для Чехии, Польши и широкой Европы) - основная валюта системы;
• чешская крона (CZK);
• польский злотый (PLN);
• казахстанский тенге (KZT);
• доллар США (USD — как кросс-валютный ориентир и для интеграций с поставщиками, цены которых выражены в долларах).

Базовый набор языков (multi-language baseline):

• украинский (UK) - первая волна разработки;
• русский (RU — для Украины, Казахстана, частично Польши - первая волна разработки;
• чешский (CZ);
• польский (PL);
• английский (EN — для интерфейсов разработчиков, документации, технических контрактов) - первая волна разработки;
• казахский (KZ).

План расширения

Фаза 2 (12–24 месяца): стабилизация в первой волне.

Фаза 3 (24–36 месяцев): расширение в широкую Европу — Германия, Австрия, Балканы, Балтика; добавление поставщиков для расширенного покрытия.

Фаза 4 (36+ месяцев): возможные направления:

• Великобритания (после выхода из Европейского Союза — отдельная юрисдикция, требует специфического для Великобритании соответствия);
• Турция (большой исходящий туристический рынок);
• Закавказье (Армения, Грузия, Азербайджан) с собственными регуляторными режимами;
• расширение в Центральную Азию через Казахстан.

Не входит в план первой и второй фазы:

• Северная Америка (другие регуляторные режимы, другая ландшафт поставщиков, другая конкуренция);
• Азиатско-Тихоокеанский регион (другая ландшафт поставщиков, требует партнёрства с региональными игроками);
• Африка, Латинская Америка (за пределами горизонта).

Соответствующая база нормативов

Зафиксирована для первой волны:

Регулирование	Применимость	Главные требования
Общее регулирование защиты данных (GDPR, EU 2016/679)	Все граждане Европейского Союза (Чехия, Польша); Украина и Казахстан — через соглашение об обработке данных при передаче	Права субъектов данных (Data Subject Rights, DSR), соглашение об обработке данных (DPA), список субподрядчиков, механизмы трансграничной передачи (стандартные договорные оговорки, Standard Contractual Clauses, SCC), минимизация данных, ограничение цели, политика хранения
Схема маржи туроператоров (Tour Operators' Margin Scheme в EU)	При продаже туристических услуг в Европейском Союзе	Маржинальный режим налога на добавленную стоимость вместо стандартного; влияет на коммерческую модель и взаиморасчёты
Директива о пакетных турах (Package Travel Directive, EU 2015/2302)	При продаже пакетных туров (≥2 компонентов) в Европейском Союзе	Защита от неплатёжеспособности (финансовая гарантия), преддоговорная информация, ответственность за исполнение, право клиента на возврат при отмене
Платёжная директива и усиленная аутентификация клиента (PSD2 и Strong Customer Authentication, SCA)	При приёме платежей на потребительских витринах в Европейском Союзе	Усиленная аутентификация клиента (3D-Secure); влияет на платёжный домен
Стандарт безопасности данных платёжной индустрии (PCI DSS)	При приёме платежей картами	Область применимости зависит от модели отвечающего за платежи продавца; через провайдера платёжных услуг (PSP) можно минимизировать
Директива об административном сотрудничестве 7 (DAC7)	Онлайн-платформы в Европейском Союзе	Обязательства по отчётности о продавцах и сделках
Закон о цифровых услугах (Digital Services Act, DSA)	Онлайн-платформы	Обязательства по прозрачности, незаконному содержанию, рекомендательным системам
Налоговый режим Украины	Продажи в Украине	Украинский налоговый режим, отдельный от Европейского Союза
Налоговый режим Казахстана	Продажи в Казахстане	Казахстанский налоговый режим, отдельный от Европейского Союза
Местная защита прав потребителей	Все юрисдикции	Соглашение об уровне обслуживания при возвратах, обработка споров, прозрачность

Полная проработка — в reference/compliance-and-legal.md фазы 4. Этот документ зафиксирует точные процессы, артефакты, ответственности.

Динамическая тарификация платформенных услуг

Главный принцип

Платформа взимает плату с партнёров за фактическую нагрузку на платформу, а не за «результаты поиска отелей». Это переводит модель с «комиссии за бронирование» на полноценную модель доступа к платформе (platform access model).

Что измеряется (учёт потребления, metering)

Метрика	Описание	Влияние на тариф
Поисковые вызовы (search calls)	Объём поисковых запросов от партнёра	Базовая стоимость; масштабируется по объёму
Сложность поиска (search complexity)	Сложность запроса — широта геозоны, число фильтров, число поставщиков в результате	Множитель к базовой стоимости поиска
Темп создания коммерческих фиксаций (quote creation rate)	Объём создаваемых коммерческих фиксаций (quote)	Стоимость выше поиска (фиксация коммерческого обещания)
Длительность срока действия коммерческой фиксации (quote validity duration)	Длительность срока действия (validity window)	Влияет на стоимость удержания обещания
Темп подтверждения бронирований (booking commit rate)	Объём подтверждённых бронирований	Стоимость за бронирование плюс доля комиссии
Бюджет вызовов поставщиков (supplier call budget)	Объём вызовов к поставщикам, который партнёр генерирует	Партнёр, нагружающий «дорогих» поставщиков, платит больше
Профиль нагрузки на поставщиков (supplier load profile)	Профиль партнёра по используемым поставщикам	Премиум-поставщики или поставщики с низкими лимитами вызовов — дороже
Вызовы ML-инференса (ML inference calls)	Объём ML-инференса (ранжирование, рекомендации, динамическое ценообразование)	Стоимость за вызов инференса
Операции конструктора туров (Tour Builder operations)	Объём композиционных операций (добавить сегмент, заменить вариант, пересобрать, версионировать, опубликовать)	Отдельный платный уровень для конструктора туров
Доставки уведомлений по обратным вызовам (webhook deliveries)	Объём доставок уведомлений по обратным вызовам партнёру	Стоимость за доставку (минимальная)
Использование хранилища (storage usage)	Объём данных партнёра у нас (пользовательские предложения, история, вложения)	Стоимость за гигабайт-месяц
Операции взаиморасчёта и клиринга (settlement and clearing operations)	Объём финансовых операций	Стоимость за операцию для моделей, не основанных на передаче без наценки (passthrough)

Тарифные уровни

Финальная структура тарифных уровней — в платформе как продукте и reference/api-as-product.md фазы 4. Концептуально:

Бесплатный уровень (Free):

• Доступ к среде тестирования (sandbox) с реалистичными тестовыми данными.
• Ограниченный объём поисковых вызовов для интеграционного тестирования.
• Без возможности бронирования (только тестовые бронирования в среде тестирования).
• Без боевого доступа (production access).

Стартовый уровень (Starter):

• Боевой доступ с минимальными квотами.
• Базовая партнёрская поверхность интерфейса без расширенных возможностей.
• Ограниченное покрытие поставщиками.
• Без конструктора туров.
• Без расширенной аналитики.

Профессиональный уровень (Professional):

• Расширенные боевые квоты.
• Полное покрытие поставщиками.
• Доступ к программному интерфейсу конструктора туров.
• Партнёрский продукт аналитики (partner-facing analytics product).
• Управление подписками на уведомления по обратным вызовам.
• Стандартное соглашение об уровне обслуживания (SLA) с компенсациями (credits).

Корпоративный уровень (Enterprise):

• Гарантированная мощность (capacity envelope).
• Возможность выделенной инфраструктуры (фаза 4).
• Полный набор возможностей платформы.
• Премиум-соглашение об уровне обслуживания с расширенными компенсациями.
• Выделенный инженер по успеху клиентов (dedicated success engineer).
• Поддержка пользовательской интеграции (custom integration support).
• Индивидуальные коммерческие условия (разделение выручки, гибридная тарификация).

Принципы тарификации

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

Принцип 2. Отсутствие отказа в обслуживании при превышении квоты. При достижении лимита тарифа партнёр получает ясный сигнал (не молчаливый отказ) и опции:

• автоматическое продолжение по тарифу превышения (overage rate);
• немедленное повышение тарифа (upgrade);
• ожидание следующего расчётного периода.

Принцип 3. Дифференциация по сложности. «Дорогие» запросы (тяжёлые композиции, сложные геозапросы, использование премиум-поставщиков) стоят больше. Партнёр не оплачивает простые запросы по той же ставке, что сложные.

Принцип 4. Скидка за объём при росте. При росте нагрузки партнёра — снижение стоимости за единицу. Это поощряет рост на платформе.

Принцип 5. Самостоятельное повышение и понижение тарифа. Партнёр меняет тариф через самообслуживание в консоли биллинга, без переговоров.

Принцип 6. Прозрачное разделение выручки для корпоративных клиентов. Для крупных корпоративных партнёров возможна модель разделения выручки (revenue-share) вместо подписки и платы за использование. Условия — прозрачные, документированные, без скрытых множителей.

Открытые развилки

Развилка 1. Точная структура тарифных уровней и цен

Структура тарифных уровней в этом документе зафиксирована концептуально. Точные цены и параметры (envelopes) — открытая развилка, эскалируется при создании платформы как продукта и reference/api-as-product.md фазы 4.

Развилка 2. Детали провайдеров платёжных услуг для разных моделей отвечающего за платежи продавца

Какие провайдеры платёжных услуг (PSP) для модели А (платформа выступает отвечающим за платежи продавцом) в каждой стране первой волны? Stripe / Adyen / местные провайдеры. Эскалируется при создании reference/payment-domain.md фазы 4.

Развилка 3. Точная стратегия решений под партнёрским брендом для расширенных потребительских витрин

Для расширенной потребительской стратегии в фазах 3–4 — поддержка решений под партнёрским брендом через партнёрский интерфейс плюс компоненты пользовательского интерфейса, или отдельная платформа под партнёрским брендом? Эскалируется в фазе 3.

Связь с другими осями архитектуры

Связь с осью 1 (каноничная доменная)

• Тенант (Tenant) — главная сущность бизнес-модели; разные тарифные уровни — разные параметры, разные политики отвечающего за платежи продавца.
• Партнёр (Partner) — отдельная категория тенанта с платным программным доступом.
• Агентство (Agency) — отдельная категория тенанта с подпиской и комиссией.
• Клиент программного интерфейса и его учётные данные (ApiClient плюс ApiCredential) — операционная единица доступа партнёра.

Связь с осью 2 (поверхности взаимодействия)

• Партнёрская поверхность (Partner API Surface) — главная коммерческая поверхность якоря.
• Закрытая поверхность конструктора туров (Tour Builder Closed Surface) — платный уровень коммерциализации.
• Рабочая поверхность для агентств (Agency Working Surface) — другая модель монетизации.
• Потребительская витрина (B2C Storefront Surface) — собственный канал и демонстрация.

Связь с осью 3 (платформа как продукт)

Этот документ и платформа как продукт вместе образуют коммерческое описание платформы.

Связь с осью 4 (данные и интеллект)

• Учёт потребления (usage metering) — базовый источник для тарификации.
• Аналитический продукт — данные, ориентированные на партнёра (partner-facing analytics) — как часть профессионального и корпоративного уровней.
• ML — динамическое ценообразование на основе ML-моделей возможно в фазе 3.

Связь с осью 5 (операционная)

• Соглашение об уровне обслуживания (SLA) — операционное обещание тенанту, прямо зависит от тарифного уровня.
• Параметры мощности (capacity envelopes) — операционная гарантия для корпоративных клиентов.
• Восстановление после аварии (Disaster Recovery) с целевым временем восстановления (Recovery Time Objective, RTO) и целевой точкой восстановления (Recovery Point Objective, RPO) — обязательство для корпоративных клиентов.

Связь с осью 6 (реализация)

Текущий проект имеет зачаточный программный интерфейс для бизнес-клиентов через эндпоинт Stuba. Это первая итерация; структуру маркетплейса программных интерфейсов ещё нужно построить полноценно — с партнёрской поверхностью, средой тестирования, биллингом, потоком сертификации.

Связанная документация

• Главная архитектурная ось
• Манифест переосмысления
• Поверхности взаимодействия
• Каноничная доменная ось
• Платформа как продукт
• Ось данных и интеллекта
• Операционная ось
• Связь с реализацией
• Граф пересечений архитектурных осей
• Дорожная карта инфраструктурного масштабирования
• Коммерческая модель
• Партнёрские взаиморасчёты
• Тенантная настройка
• Учёт потребления и квоты