У нас был проект для онлайн-сервиса, где деньги с карты списывались нормально, но доступ клиенту все равно открывал менеджер после проверки в кабинете банка. Бухгалтер параллельно искал тот же платеж по выписке, а в CRM заказ стоял в статусе «ждет оплату». Кнопка оплаты была, а платежного контура по сути не было.
Если картина знакома, стоит читать дальше по одной причине: проблема обычно не в эквайринге. Банк, сайт, CRM и 1С просто живут каждый своей жизнью, а команда потом руками сводит разные версии правды.
Платеж - это не конец, а середина процесса
После успешной оплаты должны сработать статус заказа, чек, выдача доступа или отгрузка, письмо клиенту и запись в учете. Если интеграция заканчивается переходом на платежную форму, ручная работа появляется почти сразу.
Мы обычно начинаем с карты событий. Прямо в таблице: заказ создан - счет создан - клиент начал оплату - авторизация - списание - webhook - заказ оплачен - выписка подтвердила зачисление. Когда такой цепочки нет, у сайта одна правда, у CRM вторая, у бухгалтерии третья.
Быстрый чеклист, по которому видно скрытую ручную работу:
- менеджер сверяет оплату в банке вручную
- в CRM и банке разные статусы по одному заказу
- возвраты ведутся отдельно от заказов
- бухгалтер каждый день сводит выписки руками
- заказ уже «оплачен», но в 1С денег еще нет
На одном e-commerce проекте без нормальной сверки в ручную проверку уходило 12-15% заказов в день. После того как мы ввели единый payment_id, webhook и повторную сверку по выписке, через 6 недель ручные кейсы упали до 1-2%.
Дешевый эквайринг часто выходит дороже
Обычно все смотрят на комиссию. На деле сопровождение через полгода нередко обходится дороже, чем стартовая разница в тарифе. Возвраты, частичные оплаты, B2B-счета, зависшие статусы - именно здесь начинает течь время команды.
Я сам однажды ошибся и взял самый дешевый вариант по комиссии. Экономия была около 0,3%, но бухгалтерия тратила почти 2 часа в день на сверку, а поддержка банка отвечала по несколько дней. В итоге скидка на эквайринг быстро превратилась в постоянные операционные потери.
Для подписочного сервиса в прошлом году мы запускали прием оплаты на Node.js 20 + NestJS через платежный шлюз. Это заняло 4 недели. Прямое подключение к двум банкам оценили в 10-12 недель, и по поддержке оно выходило заметно дороже.
| Вариант | Запуск | Поддержка | Где обычно берем |
|---|---|---|---|
| Платежный шлюз | 3-4 недели | ниже | быстрый старт, подписка |
| Прямой банк | 2-3 месяца | выше | B2B, сложные правила |
| Промежуточный слой | 5-8 недель | средняя | несколько банков и систем |
Я бы проверял четыре вещи: sandbox, webhook, partial refund и стабильную выгрузку выписок. Если хотя бы 2 пункта слабые, проблемы обычно вылезают уже в первый сезон пиковых оплат.
Выписка подтверждает деньги, webhook только ускоряет процесс
Webhook нужен, чтобы быстро показать клиенту статус «оплачено». Выписка нужна, чтобы финансы признали деньги. Это разные уровни достоверности, и лучше их не смешивать.
Выписка банка - это финансовая правда, а webhook - только сигнал.
В B2B-компании с регулярными счетами бухгалтер тратил на сверку 2-3 часа в день. Мы сделали загрузку выписок по API банка, промежуточный сервис на Laravel 11 и правила сопоставления по invoice_id, сумме, ИНН и назначению платежа. После запуска ручная сверка сократилась до 15-20 минут.
Простейший обработчик выглядит так:
if (!verifySignature($request)) exit('bad sign');
if (alreadyProcessed($event['id'])) exit('ok');
saveEvent($event['id'], $event['type'], $event['payment_id']);
if ($event['type'] === 'payment_captured') {
markOrderPaid($event['payment_id']);
}
queueStatementRecheck($event['payment_id']);
Здесь критичны проверка подписи и идемпотентность. Без них дубли и ложные статусы прилетают очень быстро.
Сайт, CRM и 1С ломаются там, где не договорились о главной сущности
Самая частая ошибка - связать системы точка в точку и не определить, что у вас главное: заказ, счет или платеж. Для розницы мы чаще берем заказ + payment_id. Для B2B обычно счет + договор + payment_id.
Один раз мы пошли в прямую связку сайта, CRM и 1С без единого центра платежных событий. Формально все работало, но по факту было 3 разных статуса оплаты, возвраты терялись между CRM и учетом, а менеджеры спорили с бухгалтерией, кому верить. После переделки через единый слой спорные кейсы упали примерно на 70% за месяц.
Небольшой срез до и после:
- До: 40-50 спорных кейсов в месяц, 3 источника правды, подтверждение заказа до 30 минут
- После: один payment_id, одно правило статусов, подтверждение почти мгновенно
Если идете в событийную схему, для нагрузки до 50 000 операций в сутки нам обычно хватает RabbitMQ. Kafka берем там, где нужно долго хранить поток событий и раздавать его нескольким потребителям - например, отдельно в CRM, 1С, аналитику и антифрод.
Что проверить до старта, чтобы не переплачивать потом
Если хотите быстро понять состояние своей схемы, не начинайте с кода. Возьмите один реальный платеж и пройдите его путь от кнопки на сайте до проводки в 1С и возврата статуса в CRM. На этом упражнении почти всегда видно, где сидит ручной труд, где теряются события и кто на самом деле подтверждает деньги.
В ближайшие 6-12 месяцев бизнес все чаще будет уходить от идеи «подключить оплату» к нормальной платежной архитектуре. Когда у компании появляется второй банк, новый канал продаж или отдельный B2B-поток, выигрывают не самые дешевые интеграции, а те, где один платеж можно объяснить целиком - без звонка менеджеру и поиска по выписке.
