разработать сайт для транспортной кассы webinnovator.ru — Эта страница предназначена для команды, которая планирует разработать или переделать сайт транспортного сервиса webinnovator.ru: продажать поездки, трансферы, бронирования, абонементы или дополнительные услуги с онлайн-оплатой. Результат работы должен быть конкретным: карта расчетов, ТЗ для разработчика и набор приемочных тестов, при которых заказ, платеж и чек не расходятся.
Автор: Александр Пылев, Основатель Интернет Касса.
Не начинайте с выбора кнопки оплаты. Сначала определите, кто продает услугу, каким способом клиент платит и какое событие должно запускать кассовый документ. Это снимает большую часть проблем с предоплатами, возвратами и продажами услуг нескольких перевозчиков.
В проекте должно быть одно место, где хранится итоговый статус заказа: сайт, CRM или диспетчерская система. Именно она передает в платежный и кассовый контур номер заказа, состав услуги, сумму, контакты покупателя и нужное событие расчета.
Разделите роли до написания ТЗ. При прямой продаже сервис сам продает поездку и принимает деньги. При агентской продаже сервис действует от имени или по поручению поставщика. В агрегаторской модели площадка продает услуги нескольких исполнителей. Для двух последних схем нельзя оставлять поля продавца и поставщика «на усмотрение интегратора»: договорная модель должна определить, чьи данные передаются в чек и кто отвечает за его формирование.
Для базовой логики работы с ККТ используйте материал «54-ФЗ для бизнеса: когда нужна ККТ и как запустить работу с чеками».
Подключайте интернет-эквайринг и облачную кассу с API. Сайт создает заказ, платежный сервис подтверждает или отклоняет платеж, а ваша серверная логика проверяет уведомление и передает корректное событие в кассовый сервис. Не формируйте чек при открытии платежной страницы: заказ еще не означает расчет.
Используйте отдельный выездной сценарий с переносной ККТ и терминалом, если он нужен. Не смешивайте оплату у водителя с платежом по ссылке: у них разные источники подтверждения, порядок возврата и ответственность сотрудника. В приложении водителя должны отображаться номер заказа, сумма и услуга, чтобы не вводить их вручную.
Создайте отдельные события для предоплаты, зачета предоплаты, доплаты и возврата. Статус «оплачено» для всех операций не подходит: он не объясняет бухгалтерии и поддержке, что произошло с конкретным заказом.
Отделите оплату по счету между организациями от оплаты физлица на сайте. Если сотрудник компании или пассажир оплачивает заказ картой через checkout, это должен идти по сценарию интернет-платежа; не маскируйте такую операцию под корпоративный счет.
Передайте эту таблицу разработчику, бухгалтерии, эквайеру и кассовому сервису. В колонке «момент расчета» зафиксируйте ваше фактическое бизнес-событие, а не абстрактный статус «успех».
| Событие | Когда запускать обработку | Что передать в кассовый контур | Источник статуса | Ответственный |
|---|---|---|---|---|
| Полная оплата услуги | После подтверждения оплаты или при расчете на месте | Полный расчет, состав услуги, сумма, заказ | Эквайер, терминал или касса | Владелец кассовой схемы |
| Предоплата | После получения денег до оказания услуги | Событие предоплаты, сумма, заказ | Эквайер или касса на выезде | Владелец кассовой схемы |
| Зачет предоплаты | Когда услуга оказана или наступил определенный в модели расчет | Событие зачета, связанный заказ и предоплата | CRM или диспетчерская система | Владелец бизнес-процесса |
| Доплата | После подтверждения отдельного платежа | Сумма доплаты и состав услуги | Эквайер, терминал или касса | Владелец кассовой схемы |
| Возврат | После подтверждения возврата в платежном канале | Связь с исходным расчетом, сумма возврата | Эквайер, терминал или касса | Поддержка по утвержденному процессу |
Тип и реквизиты кассового документа для каждого события закрепите в настройках кассы и согласуйте с вашей учетной и договорной схемой. Особенно внимательно проработайте предоплату, зачет и агентские продажи: здесь нельзя копировать настройки обычной разовой продажи.
Для сайта и приложения выбирайте облачную кассу, если решение умеет принимать данные заказа по API, формировать чеки автоматически и возвращать результат обработки. Готовый модуль подходит для простого checkout; при связке сайта, CRM и диспетчерской системы понадобится API-интеграция.
До подключения запросите у провайдера: описание webhook, способ проверки подписи, перечень статусов, API для запроса статуса платежа, правила возврата и тестовую среду. Сравнение подходов есть в статье «Облачная онлайн-касса: выбор, запуск и типовые сценарии для бизнеса».
| Критерий | Облачная касса для сайта | Переносная ККТ для выезда |
|---|---|---|
| Основной канал | Сайт, приложение, платежная ссылка | Карта через терминал или наличные у клиента |
| Триггер обработки | Проверенное серверное событие платежа или бизнес-событие зачета | Фактический расчет у водителя или сотрудника |
| Главное требование | API, проверка уведомлений, защита от повторов | Передача заказа в приложение сотрудника, связь и порядок возврата |
| Главный риск | Дубль или пропуск из-за неверной обработки webhook | Ручной ввод суммы и расхождение с заказом |
Webhook — это уведомление, а не безусловная команда пробить чек. Сервер должен проверить подпись или секрет уведомления по документации провайдера, сопоставить ID платежа с ID заказа, сумму и валюту. Если хотя бы один параметр не совпал, остановите автоматическую обработку и отправьте событие на разбор.
Далее сделайте обработку идемпотентной: сохраните уникальный ID платежа и результат обработки. Повторное уведомление с тем же ID не создает второй чек. Ведите журнал: время уведомления, проверенные параметры, решение системы, ID кассового документа и ответ провайдера.
При спорном уведомлении не полагайтесь на его содержимое. Запросите текущий статус платежа через серверный API провайдера, затем примите решение по вашей карте расчетов. Такой порядок защищает от сетевых повторов, задержанных callback и ошибок интеграции.
Если сайт еще не готов, сначала определите структуру checkout, поля заказа и интеграционные события. Практические требования к сайту собраны в статье «Сайт с онлайн-оплатой и кассой: лендинг, каталог или интернет-магазин».
Все оплаты оформляются как полная продажа. Исправление: выделите предоплату, зачет, доплату и возврат отдельными событиями в ТЗ.
Webhook обрабатывается без проверки. Исправление: проверяйте подпись, ID, сумму и валюту; спорные случаи сверяйте через API провайдера.
Водитель вручную вводит сумму на кассе. Исправление: передавайте заказ в приложение сотрудника или установите обязательную сверку номера заказа перед расчетом.
В агентской схеме не определен продавец. Исправление: до запуска утвердите договорную модель и набор данных, которые должны попадать в кассовый документ.
Тестируется только успешная оплата. Исправление: добавьте отмену до списания, неуспешный платеж, возврат, повторный webhook и несовпадение суммы.
Сначала подтвердите схему продажи и момент расчета для каждого события. Затем настройте кассовое решение под эту схему и проверьте передачу фискальных данных. Официальные сервисы и разъяснения доступны на сайте ФНС России; текст нормативных актов и изменения удобно отслеживать через КонсультантПлюс.
Для агентской, агрегаторской модели, сложных предоплат или расчетов нескольких перевозчиков нужна отдельная проверка договорной и кассовой модели профильным специалистом до запуска. Здесь ошибка в роли продавца или данных чека не исправляется заменой webhook.
Нужен готовый стартовый пакет? На первом созвоне разберем вашу схему продаж и каналы оплаты. Затем подготовим карту расчетов, ТЗ на интеграцию и список приемочных тестов для разработчика; после согласования можно переходить к подключению. Оставьте заявку в Интернет Касса.
Да, если сервис принимает оплату за собственные услуги от клиентов и расчет требует применения ККТ. При агентской или агрегаторской продаже сначала определите по договорной модели продавца, получателя оплаты и сторону, формирующую чек.
Да, для дистанционных оплат подключайте облачную кассу с интеграцией по API. ККТ физически размещается у поставщика сервиса, а сайт должен передавать подтвержденные события расчета и состав заказа.
Нет, настройте отдельное кассовое событие для каждого вида расчета. Успешный платеж может подтверждать предоплату или полную оплату, а зачет предоплаты, доплата и возврат должны запускаться по правилам карты расчетов.
Проверяйте подпись уведомления, сумму, валюту, ID платежа и ID заказа, затем сохраняйте результат обработки как идемпотентный. При повторном уведомлении не создавайте новый чек, а при расхождении запросите статус платежа у провайдера и зафиксируйте решение в журнале.
Да, тестируйте их как разные сценарии. У терминала и наличного расчета на выезде свой источник оплаты и процесс возврата, а платеж по ссылке требует обработки дистанционного статуса от платежного провайдера.