Интеграция CRM и Т-Банк

Интеграция CRM с Т-Банком — это на самом деле два разных сценария, которые постоянно путают на этапе постановки задачи. Первый: интернет-эквайринг, когда менеджер выставляет ссылку на оплату или QR-код по системе быстрых платежей прямо из карточки сделки. Второй: открытый API банка, когда CRM сама получает выписку по расчетному счету и помечает счет оплаченным, без бухгалтера-посредника. Ключи, права доступа и логика у них разные, подключаются они независимо, и многим компаниям нужны оба. Для amoCRM у банка есть собственные виджеты, Битрикс24 и RetailCRM подключаются модулем или собственным коннектором.

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

Два сценария, которые нельзя перепутать

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

Разница принципиальная. Эквайринг — это про то, чтобы клиент заплатил здесь и сейчас с карты или телефона. Открытый API — про то, чтобы понять, что юрлицо перечислило деньги по вашему счету, и сделать это без ручной сверки.

Компания, которая продает и физлицам, и организациям, приходит к обоим сценариям. Тогда в CRM появляется единая картина оплат, независимо от того, как именно клиент заплатил.

Эквайринг: ссылка и QR прямо из сделки

Здесь все довольно предсказуемо. Менеджер нажимает кнопку в карточке, система создает платеж, получает ссылку и отправляет ее клиенту в мессенджер. Для оплаты через быстрые платежи вместо ссылки формируется QR-код — удобно, когда разговор идет по телефону или клиент стоит перед вами.

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

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

Открытый API банка: конец ручной сверке

Это тот раздел, ради которого к нам обычно и приходят компании, работающие по безналу.

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

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

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

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

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

Авторизация и подпись: где обычно спотыкаются

Два сценария — два набора доступов, и путать их не надо.

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

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

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

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

Чеки: кто и что бьет

Развилка та же, что и в любой платежной интеграции, и решается она один раз на старте.

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

Что важно для CRM в любом случае: контактные данные покупателя должны быть в сделке до момента оплаты, иначе чек отправлять некуда. Мы делаем соответствующее поле обязательным на стадии выставления счета, чтобы менеджер физически не мог отправить ссылку без него.

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

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

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

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

amoCRM хороша для услуг и B2B-продаж по счетам. Именно здесь автоматическая разноска выписки дает самый заметный эффект: сделка сама переходит дальше, как только деньги пришли, и менеджеру не надо ничего выяснять у бухгалтерии.

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

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

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

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

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

Не заложили частичные оплаты. Пришла половина суммы, сделка помечена оплаченной, товар отгружен. Дальше неприятный разговор.

Подпись сломалась при добавлении чеков. Интеграция работала, добавили фискализацию, начались отказы. Причина в другом порядке формирования подписи для запросов с вложенными данными.

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

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

Эквайринг с выставлением ссылок и сменой статуса по уведомлению — обычно 8-12 часов работы. Разбор выписки с правилами разноски, частичными оплатами и экраном нераспознанных платежей — от 25 часов, и это тот случай, когда большая часть времени уходит не на код, а на согласование логики. Оба сценария вместе с фискализацией и несколькими юрлицами считаются отдельно.

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

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

Чем отличается интеграция эквайринга от интеграции с расчетным счетом?

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

Может ли CRM сама определять, какой счет оплачен?

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

Что происходит, если клиент оплатил не всю сумму?

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

Можно ли подключить несколько юрлиц?

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

Нужен ли отдельный терминал для двухстадийных платежей?

Как правило, да: режим списания определяется настройкой терминала, а не параметром запроса. Если нужны обе схемы, терминалов будет два, и в CRM должно быть понятно, через какой идет конкретная оплата.

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

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

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

Интеграция CRM и Т-Банка распадается на два независимых проекта. Эквайринг закрывает розницу и услуги: ссылка или QR из сделки, статус, чек. Открытый API банка закрывает работу по счетам: выписка приезжает в CRM, оплаты разносятся по сделкам, бухгалтер перестает быть посредником между банком и отделом продаж.

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

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