Оплата, онлайн‑касса и доставка — три разные интеграции, которые сходятся в одном заказе. Покупатель видит одну кнопку, но за ней должны согласованно сработать CMS, платёжный провайдер, система фискализации, служба доставки, CRM и учётная система.
Главная ошибка — подключать сервисы независимо друг от друга. Тогда оплаченный заказ остаётся в статусе «новый», чек не формируется, доставка создаётся дважды или менеджер вручную исправляет данные. Надёжный запуск начинается со схемы статусов.
Содержание:
Из чего состоит контур
| Компонент | За что отвечает | Что передаётся |
|---|---|---|
| Платёжный провайдер | Приём и возврат денег | Сумма, валюта, идентификатор заказа, статус |
| Онлайн‑касса и ОФД | Фискальный чек | Позиции, ставки НДС, признаки расчёта, контакты |
| Служба доставки | Расчёт и перевозка | Адрес, вес, габариты, тариф, пункт выдачи |
| CMS магазина | Корзина и заказ | Товары, скидки, покупатель, согласия |
| CRM или 1С | Обработка и учёт | Заказ, оплата, отгрузка, возврат, статусы |
Правильная последовательность подключения
- Опишите способы расчёта. Предоплата, оплата при получении, частичная оплата, юридические лица, возвраты.
- Согласуйте фискализацию. Бухгалтер, банк, кассовый сервис и ОФД должны подтвердить применимую схему и реквизиты чека.
- Настройте каталог. Наименования, цены, скидки, НДС, вес и габариты должны быть заполнены в источнике данных.
- Подключите тестовые кабинеты. Секретные ключи хранятся только на сервере, доступы разделяются по средам.
- Свяжите статусы. Оплачен, отменён, возвращён, передан в доставку, выдан покупателю.
- Проведите сквозную приёмку. От корзины до оплаты, чека, создания отправления и возврата.
Что важно в платёжной интеграции
Нельзя считать оплату успешной только потому, что покупатель вернулся на страницу «Спасибо». Статус подтверждается серверным уведомлением платёжного провайдера или отдельным запросом к API. В официальной документации ЮKassa успешным считается платёж в статусе succeeded; для создания платежа также используется ключ идемпотентности, защищающий от повторной операции.
| Сценарий | Что тестируем | Критичный результат |
|---|---|---|
| Успешная оплата | Уведомление и смена статуса | Заказ отмечен оплаченным один раз |
| Отказ или закрытие формы | Возврат в магазин | Заказ не становится оплаченным |
| Повторный webhook | Идемпотентность | Нет дубля оплаты и чека |
| Полный возврат | Провайдер, касса, CRM | Суммы и статусы совпадают |
| Частичный возврат | Состав позиций | Возвращены правильные товары и налоги |
| Недоступность внешнего API | Очередь и повтор | Событие не теряется |
Сколько занимает и стоит подключение
Оценка зависит от CMS, готовности официальных модулей и числа нестандартных сценариев. Ставка разработки — 2 300 ₽/ч.
| Вариант | Часы | Ориентир |
|---|---|---|
| Готовый модуль одного сервиса и стандартный checkout | 8–16 | 18 400–36 800 ₽ |
| Доработка API одного провайдера со статусами и возвратами | 24–50 | 55 200–115 000 ₽ |
| Оплата + касса + доставка + CRM/1С | 60–120+ | 138 000–276 000+ ₽ |
| Изменения дизайна оформления заказа | Отдельно | 2 000 ₽/ч |
Комиссии провайдера, аренда кассы, ОФД, SMS и тарифы службы доставки оплачиваются отдельно. До разработки их нужно внести в общую экономику заказа.
Практический пример
В кейсе YANA исправление эквайринга и НДС выполнялось вместе с интеграцией 1С и RetailCRM. Это важная связка: платёж нельзя чинить изолированно, если сумма, ставка налога или статус заказа формируются в другой системе. Для MIMPI перед запуском сквозно проверялись поиск товара, фильтры, оформление заказа и онлайн‑оплата.
Чек-лист перед запуском
- Сумма заказа совпадает на сайте, у провайдера, в кассе и CRM.
- Скидки и доставка корректно распределены по позициям.
- Статусы меняются только после подтверждённого события.
- Секретные ключи не попадают в HTML, JavaScript и логи браузера.
- Повторные уведомления безопасны.
- Протестированы отмена, полный и частичный возврат.
- Ответственный получает уведомление, если чек или доставка не создались.
Частые вопросы
Нужна ли интернет-магазину онлайн-касса?
Это зависит от юридической модели, способа расчёта и применимых исключений. Перед настройкой технической схемы её нужно подтвердить у бухгалтера, оператора фискальных данных и платёжного партнёра.
Можно ли подключить оплату готовым модулем?
Да, если версия CMS и модуль совместимы, а процесс стандартный. Но даже готовое решение необходимо настроить и проверить на реальных сценариях статусов и возвратов.
Почему нельзя ориентироваться на страницу «Спасибо»?
Покупатель может не вернуться на сайт, а злоумышленник — открыть URL вручную. Источником истины должно быть серверное подтверждение провайдера.
Что такое идемпотентность?
Это защита от повторного выполнения одной операции. Повторный запрос не должен списать деньги, создать второй заказ, чек или отправление.
Как подключить несколько служб доставки?
Можно интегрировать их напрямую или через агрегатор. Сначала согласуют правила выбора тарифа, ограничения по регионам, габаритам, оплате и пунктам выдачи.
Что обязательно проверить после запуска?
Первые реальные платежи, чеки, статусы, уведомления, создание отправлений и возвраты. Несколько дней полезно ежедневно сверять данные между системами.
Нужно подключить оплату, кассу и доставку без потери заказов?
Разберём текущую схему магазина, составим карту статусов и оценим интеграции отдельными понятными этапами.
