Как настроить автоматическое закрытие сделок в CRM по событию оплаты

Автозакрытие сделок по факту оплаты — это когда CRM сама переводит карточку заказа в статус «оплатирован» и двигает её дальше по воронке, как только платёжный шлюз прислал подтверждение. Менеджеру не нужно вручную проверять выписку, сверять реквизиты и переключать этапы — система делает это за него за секунды. Ниже разберём, какие события использовать как триггер, как связать CRM с платёжной системой и кассой и где обычно спотыкаются предприниматели из Минска, Гомеля и Бреста, когда собирают эту связку в первый раз.

Какие события оплаты вообще можно отслеживать

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

• Платёж создан — покупатель нажал «оплатить», но деньги ещё не дошли. Закрывать сделку здесь рано: клиент может уйти со страницы, платёж отвалится по таймауту.
• Платёж получен — деньги дошли до продавца. Для большинства интернет-магазинов это и есть сигнал, что заказ оплатирован.
• Платёж зачислен на расчётный счёт — актуально для b2b и опта, когда важно дождаться именно банковского перевода, а не холда на карте.
• Возврат проведён — обратное событие. Если его не отслеживать, CRM продолжит считать сделку закрытой, хотя деньги уже у покупателя.

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

Как связать CRM и платёжную систему между собой

Связка делается через вебхуки — это HTTP-уведомления, которые шлюз шлёт на ваш адрес, когда статус платежа меняется. У платёжного провайдера в личном кабинете вы указываете URL вашей CRM и выбираете события, по которым CRM должна получать уведомления. После этого в настройках CRM нужно создать триггер, который ловит нужное событие и меняет статус сделки.

В RetailCRM это работает через раздел «Интеграции» — там подключаются bePaid, Stripe, Assist, ЮKassa и другие шлюзы, которые поддерживают белорусские карты и ЕРИП. Для ЕРИП обычно добавляют промежуточный обработчик: банк-эквайер шлёт callback вашему бэкенду, бэкенд проверяет статус и только потом дёргает CRM. Если бизнес использует несколько каналов оплаты одновременно — карточки на сайте, ЕРИП в офисе и оплату курьеру наличными — каждое событие нужно привязать к одной и той же сделке по общему идентификатору заказа.

Когда деньги пришли, система должна не просто поменять статус, а сделать цепочку действий: перевести сделку на следующий этап, убрать её из списка «жду оплату», поставить задачу на сборку, отправить клиенту подтверждение. Именно эта цепочка превращает CRM из записной книжки в рабочий инструмент, потому что менеджер не копирует данные между окнами и не забывает про заказы.

Как проверить, что связка работает корректно

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

Если в тестовых прогонах задержка между платежом и сменой статуса превышает пару минут, ищите причину в очереди вебхуков — она иногда встаёт, если CRM принимает уведомления медленнее, чем шлюз их шлёт. Для b2-бытовых сценариев достаточно проверять развязку вручную раз в неделю по отчёту «Сделки без движения за 7 дней».

Что учесть, если в магазине есть предзаказы или возвраты

Предзаказ оплачивается частично — клиент вносит предоплату, остаток — при поступлении товара. В этом случае нужны два триггера: первый закрывает часть суммы и двигает сделку в статус «предоплата получена», второй ждёт остаток и только после него переводит заказ в финальный статус. Подробно про связку предзаказов и CRM рассказали в материале про настройку предзаказов в интернет-магазине.

Возвраты требуют отдельной логики, потому что деньги уходят обратно, а товар может оставаться у клиента. Здесь же стоит настроить отдельный статус «возврат инициирован», по которому CRM автоматически ставит задачу менеджеру и блокирует повторную отправку заказа. Практические приёмы по работе с возвратами собраны в статье как настроить возвраты и обмены в интернет-магазине через CRM.

Как избежать типичных ошибок

• Закрывать сделку по событию «платёж создан» — клиент ещё не заплатил, только открыл форму. Ждите «платёж получен».
• Использовать один идентификатор заказа для всех каналов оплаты — иначе одна и та же покупка появится в CRM как две разные сделки.
• Забыть про возвраты — без отслеживания возвратов сделки остаются в статусе «оплачено», хотя деньги уже у покупателя.
• Не тестировать отмену — клиент жмёт «отмена» на стороне банка, CRM не узнаёт и продолжает собирать заказ.
• Подключать вебхуки только на проде — сначала прогон на тестовом шлюзе, потом переключение боевых ключей.
• Игнорировать очередь вебхуков — если CRM медленно обрабатывает уведомления, статусы отстают на минуты и часы.