Платежное решение в турбизнесе часто выбирают по комиссии. Сложности появляются позже. Нужно выдать чек за тур, проданный по агентскому договору, вернуть деньги после отмены, зачесть предоплату при доплате и сверить поступления с бронированиями в CRM. На этих операциях тариф уже мало что решает.

Платежную инфраструктуру удобнее рассматривать как три связанных слоя. Первый слой — онлайн-касса и фискализация по 54-ФЗ. Второй — прием денег: интернет-эквайринг через платежного провайдера или Система быстрых платежей. Третий — сервисы оплаты частями. Слои работают вместе, и выбирать их приходится вместе. Касса должна получать данные о каждом платеже и возврате. Способ оплаты должен поддерживать авансы, полные и частичные возвраты. А вся связка должна передавать статусы в CRM или систему бронирования через API и вебхуки, иначе деньги не получится сверить с заказами.

Организации и индивидуальные предприниматели при расчетах в России в общем случае обязаны применять онлайн-кассу, если не действует одно из исключений, предусмотренных 54-ФЗ (памятка ФНС по онлайн-кассам). Поэтому онлайн-оплату тура или проживания нужно сразу планировать вместе с фискализацией.

При дистанционной безналичной оплате через интернет продавец обязан отправить покупателю электронный кассовый чек на номер телефона или адрес электронной почты (статья 1.2 закона о ККТ). Значит, форма бронирования или ссылка на оплату должна собирать хотя бы один из этих контактов и передавать его в кассу.

С 1 сентября 2025 года в чеках при расчетах через интернет указываются специальные реквизиты (разъяснение ФНС): признак расчета в интернете с тегом 1125, адрес сайта или места расчетов в интернете и контактные данные покупателя. Если касса и платежный модуль настроены давно, проверьте, что эти поля действительно попадают в чек.

Регистрировать кассу стало проще. С 1 марта 2025 года зарегистрировать, перерегистрировать или снять ККТ с учета можно через новые каналы, в том числе через личный кабинет на Госуслугах, производителя ККТ или оператора фискальных данных. Срок регистрации сократили до пяти рабочих дней (ФНС об изменениях 2025 года).

У турагентства с фискализацией своя сложность: прежде чем выбирать кассу, нужно понять, кто вообще выдает чек. Агентство продает продукт туроператора и принимает деньги клиента, а услугу оказывает другая компания. Кто в такой схеме формирует чек, зависит от условий агентского договора, от того, кто проводит расчет и кто оказывает услугу. Поэтому роли агента и принципала турагентству приходится настраивать отдельно («Налоговые вести Красноярского края» о применении ККТ при расчетах через агента).

Туроператору с собственным продуктом или отелю, который сам продает проживание, обычно проще: продавец и исполнитель здесь одна компания. Но модели у многих смешанные. Агентство продает и чужие туры, и собственные экскурсии, отель работает и напрямую, и через посредников. Касса и платежная интеграция должны различать эти случаи в каждом заказе.

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

Здесь варианты действительно можно сравнивать: СБП и интернет-эквайринг решают одну задачу — принимают деньги онлайн.

Через СБП оплату принимают по QR-коду, ссылке, кнопке на сайте, через NFC и API. Подключение оформляют через банк — участника системы. Комиссия для бизнеса — не больше 0,7% от суммы операции, деньги зачисляются на счет мгновенно (вопросы и ответы НСПК для бизнеса). Специальный платежный терминал для онлайн-продаж не нужен: оплату встраивают в сайт или приложение кнопкой, ссылкой или через API (СБП для бизнеса). Менеджеру, который отправляет клиенту счет в мессенджере, оплата по ссылке подходит в первую очередь.

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

Сравнивать удобно по одним и тем же параметрам:

• комиссия: у СБП есть публичный потолок 0,7%, условия эквайринга смотрят в предложении конкретного провайдера;
• скорость зачисления: в СБП деньги приходят мгновенно, у провайдера срок уточняют по договору;
• связь с кассой: попадут ли данные платежа в чек через функции провайдера или понадобится отдельная интеграция с кассой;
• возвраты: какие операции доступны для конкретного способа оплаты и как они проводятся;
• уведомления и API: сможет ли CRM или PMS получать статус оплаты автоматически, чтобы менеджеру не приходилось проверять выписку вручную.

Бронь редко оплачивают одним платежом. Клиент вносит предоплату, ближе к поездке доплачивает, иногда меняет состав услуг или отменяет заказ. На каждом шаге платежная интеграция и касса должны сработать согласованно.

Начнем с отмены. Провайдер может поддерживать полные и частичные возвраты, но с ограничениями. В ЮKassa возврат выполняется только на исходное платежное средство, а комиссия за уже подтвержденный платеж при возврате не возвращается (правила возвратов ЮKassa). Это правило не универсально: при отмене неподтвержденного двухстадийного платежа, а также при некоторых возвратах в день оплаты комиссия может не взиматься (возвраты в личном кабинете ЮKassa). Если клиент отменил тур уже после подтверждения платежа и получил деньги обратно, комиссия за его платеж обычно остается расходом бизнеса, и эту стоимость отмены стоит заложить в условия бронирования. Вернуть деньги другим способом через ту же операцию не получится, даже если клиент об этом попросит.

Вторая сложность — чеки на разных этапах. Если касса сторонняя, провайдер может передавать ей данные для чека по одному из трех сценариев: «платеж и чек одновременно», «сначала чек, потом платеж» или «сначала платеж, потом чек». Поддерживаются чеки платежей, возвратов и зачета аванса (отправка чеков в стороннюю онлайн-кассу). В жизни брони это выглядит так: предоплата — чек платежа, доплата с зачетом ранее внесенной суммы — чек зачета аванса, отмена — чек возврата.

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

Сервис оплаты частями добавляется к кассе и эквайрингу как еще один способ оплаты и не заменяет их. Яндекс Сплит для бизнеса доступен туристическим агентствам и другим компаниям сферы услуг. Продавец сразу получает всю сумму покупки, а клиент выплачивает ее частями. Заявлены лимиты до 50 000 рублей для обычного Сплита и до 1 млн рублей для Супер Сплита, тариф зависит от продукта и условий подключения (Яндекс Сплит для бизнеса).

Для туризма важны как раз эти параметры. От лимита зависит, получится ли разбить на части весь заказ или только его часть. Единой публичной ставки нет, поэтому условия тарифа нужно получить до подключения. В Яндекс Путешествиях оплата частями доступна для отдельных отелей: клиент выбирает эту опцию и получает график автоматических списаний («Сплитуйте путешествия»). Если оплату частями подключают на своем сайте, ее включают в тот же пилот, что и остальные способы оплаты, и проверяют отмену брони и чеки по такому заказу.

При агентской продаже туров критичный слой — касса. До выбора провайдера нужно зафиксировать по договорам роли агента и принципала и проверить, что интеграция передает их в чек. Способ приема платежа здесь вторичен.

Для собственного турпродукта на первый план выходит цикл оплаты: предоплата, доплата, отмена. Провайдер и касса должны поддерживать чеки зачета аванса и частичные возвраты.

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

Когда менеджер отправляет клиенту ссылку на оплату, важны скорость и простота: ссылка или QR-код через СБП, мгновенное зачисление. Электронный чек с обязательными интернет-реквизитами при этом должен уходить клиенту так же, как при оплате на сайте.

Правила и доступность операций зависят от способа оплаты, поэтому возвраты, частичные возвраты, авансовые и закрывающие чеки тестируют отдельно для каждого способа (тестирование платежей и чеков в ЮKassa). Минимальный сценарий пилота:

1. Провести тестовые платежи каждым подключенным способом: картой через провайдера, через СБП по ссылке и QR-коду, оплатой частями, если она подключена.
2. Сделать полный и частичный возврат по каждому способу и убедиться, что деньги уходят на исходное платежное средство.
3. Пройти цепочку брони целиком: предоплата, доплата с зачетом аванса, отмена. На каждом шаге должен формироваться правильный чек.
4. Открыть чеки и проверить интернет-реквизиты: признак расчета в интернете, адрес сайта, контакт покупателя.
5. Убедиться, что электронный чек дошел до клиента на телефон или email.
6. Для агентских продаж проверить, что роли агента и принципала отражены в чеке корректно.
7. Проверить, что уведомления о статусах платежей и возвратов приходят в CRM или PMS и меняют статус брони без ручных действий.
8. Сверить поступления на счет с бронированиями за тестовый период с учетом удержанных комиссий по отмененным заказам.

Решение о кассе и провайдере лучше принимать по итогам такого прогона, а не после сравнения тарифов.