Интеграция CRM и ЮKassa

Интеграция CRM с ЮKassa дает менеджеру возможность выставить ссылку на оплату прямо из карточки сделки, отправить ее клиенту и получить автоматическую смену статуса, когда деньги поступили. В Битрикс24 платежная система подключается штатно в Центре продаж, у amoCRM есть официальный виджет, для RetailCRM — модуль из маркетплейса. Но самая полезная возможность этой связки обычно остается невключенной: платеж можно проводить в две стадии, когда деньги сначала замораживаются на карте клиента и списываются только после того, как вы подтвердили наличие товара.

Ниже разберем, как это устроено, какие статусы платежа надо разложить по воронке, зачем нужен ключ идемпотентности и почему в сделке обязательно должен быть email клиента.

Холдирование: возможность, которую почти никто не включает

Обычный сценарий выглядит так: клиент оплатил, деньги списались, а через час выясняется, что позиции нет на складе. Дальше возврат, комиссия за операцию, недовольный клиент и запись в статистике возвратов.

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

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

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

Четыре статуса платежа и что им соответствует в воронке

Статусная модель у сервиса простая, но раскладывать ее по сделке надо осознанно. Иначе получается классика: в CRM только «оплачено» и «не оплачено», а между ними теряется половина ситуаций.

Вторая строка — та, ради которой все и затевается. Если ее не завести, менеджер увидит «оплачено» и отдаст заказ на отгрузку, хотя денег на счете компании еще нет. Ошибка редкая, но неприятная.

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

Ключ идемпотентности: страховка от двойного списания

Особенность API, которую разработчики без опыта работы с платежами регулярно понимают неправильно.

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

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

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

Уведомления могут прийти дважды

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

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

Реализуется просто: перед обработкой проверяем, не записан ли уже этот идентификатор платежа в сделке. Если записан — отвечаем успехом и ничего не делаем. Звучит очевидно, но пропускают это регулярно, а потом разбираются, почему у одного заказа три оплаты.

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

Чеки: почему в сделке обязателен email

Практический момент, который ломает процессы чаще, чем любая техническая деталь. Если чеки формирует платежный сервис, он доставляет их только на электронную почту — отправка чека в SMS недоступна.

Для интернет-магазина это не проблема, почта и так есть в заказе. А вот для отдела продаж, который работает по телефону и в мессенджерах, это меняет скрипт: email надо спросить и записать, иначе чек уйти не сможет. Мы такие поля делаем обязательными на стадии выставления счета, чтобы менеджер не мог отправить ссылку без почты.

Второй вопрос — кто вообще бьет чек. Либо платежный сервис, либо ваша касса, и включать оба одновременно нельзя: клиент получит два чека на одну покупку. Решение принимается на старте вместе с бухгалтерией и фиксируется письменно, потому что через полгода никто не помнит, как договорились.

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

amoCRM, Битрикс24 и RetailCRM: чем отличается связка

Битрикс24 дает самый быстрый старт: платежная система включается в интерфейсе, ссылка формируется из сделки и уходит клиенту в мессенджер. Холдирование при этом обычно не входит в штатный сценарий, и если оно вам нужно, логику мы дописываем своим коннектором на REST с отдельными стадиями под заморозку и подтверждение.

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

amoCRM хороша для услуг и коротких сделок с одной позицией: выставил ссылку, получил оплату, поехали по воронке дальше. Если позиций много и нужен товарный учет, состав платежа и чека разумнее собирать в МойСклад или 1С, а в amoCRM держать факт оплаты и ссылку на чек.

Порядок работ

1. Выбираем режим платежа. Одностадийный или с холдированием, и если второй — укладывается ли ваша сборка в срок заморозки по используемым способам оплаты.
2. Раскладываем статусы по воронке. Все четыре состояния из таблицы выше плюс сценарии частичного подтверждения и возврата.
3. Решаем вопрос с чеками. Кто фискализирует, откуда берется состав, обязательные поля в сделке. Согласуется с бухгалтерией до начала работ.
4. Готовим поля. Идентификатор платежа, сумма, комиссия, статус, дата, ссылка, email клиента. Без отдельных полей данные окажутся в примечаниях, и отчет по ним не построить.
5. Настраиваем обработчик уведомлений. Устойчивость к повторам, проверка источника, корректный ответ сервису.
6. Реализуем идемпотентные операции. Детерминированные ключи, хранение их вместе с платежом.
7. Тестируем альтернативные сценарии. Неуспешная оплата, частичное подтверждение, отмена заморозки, частичный и полный возврат. Именно эти сценарии обычно и находят проблемы.
8. Включаем контроль. Отчет по сделкам с замороженными деньгами, у которых подходит срок подтверждения, и уведомление об ошибках обработчика.

Ошибки, которые мы разбираем чаще всего

Заморозку принимают за оплату. Сделка помечается оплаченной, заказ уходит на отгрузку, а деньги на счет компании еще не пришли. Отдельный статус решает вопрос полностью.

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

Ключ идемпотентности генерируется заново при каждой попытке. Защита превращается в свою противоположность, и на повторе появляется второй платеж.

Обработчик не устойчив к повторным уведомлениям. У одного заказа три записи об оплате, клиент получил три письма, отчетность врет.

Email не собирают. Чек отправить некуда, менеджеры вручную допрашивают клиентов задним числом.

Сроки и стоимость

Базовое подключение с выставлением ссылок и сменой статуса по уведомлению — обычно 6-10 часов работы, если система поддерживает платежную систему штатно. Контур с холдированием, частичным подтверждением, возвратами и фискализацией — от 25 часов. Собственный коннектор для нетиповой системы считается отдельно.

Основной фактор — не техника, а количество сценариев. Чем больше вариантов оплаты, возвратов и частичных подтверждений, тем дольше проектирование и тестирование.

Частые вопросы

Что такое холдирование и зачем оно в CRM?

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

Сколько времени деньги остаются замороженными?

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

Можно ли списать не всю замороженную сумму?

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

Почему оплата прошла, а статус в CRM не изменился?

Чаще всего обработчик уведомлений не получил запрос: на коробочном портале не открыт доступ, либо смена статуса завязана на возврат клиента на страницу после оплаты, а он ее не открыл.

Обязательно ли собирать email клиента?

Если чеки формирует платежный сервис — да. Чек доставляется только на электронную почту, в SMS его отправить нельзя. Поле стоит сделать обязательным на стадии выставления счета.

Кто должен пробивать чек?

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

Коротко о главном

Интеграция CRM и ЮKassa обычно сводят к ссылке на оплату и смене статуса, хотя самое ценное здесь — двухстадийный платеж. Он убирает целый класс проблем с возвратами и дает менеджеру время между поступлением денег и отгрузкой.

Технически проект держится на трех вещах: правильно разложенных статусах платежа, идемпотентных операциях с детерминированными ключами и обработчике уведомлений, который переживает повторы. Все остальное — надстройка.

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