Click, Payme, CRM и мессенджеры: как связать оплаты и не потерять ни одного платежа

Почему оплаты стоит связать с CRM

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

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

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

Как это устроено в общих чертах

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

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

Как платёж находит клиента

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

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

Кто за что отвечает

• Платёжная система — провести платёж и сообщить о нём вашей системе.
• Промежуточное звено или модуль CRM — принять сообщение, проверить его и записать оплату к нужному клиенту.
• CRM — хранить счета, оплаты и долги и запускать уведомления и напоминания.
• Мессенджер или SMS — доставить сообщение клиенту и сотруднику.
• Учётная система — вести бухгалтерский и налоговый учёт на основе данных об оплатах.
• Люди — разбирать исключения: платежи без клиента, споры, возвраты.

Ключевые термины

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

• Мерчант — компания, которая заключила договор с платёжной системой и принимает через неё оплаты.
• Идентификатор платежа — уникальный номер, который платёжная система присваивает каждой транзакции. По нему платёж можно найти и проверить.
• Идентификатор клиента или счёта — ваш номер договора, заказа или лицевого счёта, который передаётся в платёж, чтобы связать деньги с клиентом.
• Уведомление о платеже — сообщение, которое платёжная система отправляет вашей системе, когда статус платежа меняется. Разработчики часто называют его callback или webhook.
• Идемпотентность — свойство обработки, при котором повторное получение того же уведомления не меняет результат: оплата засчитывается один раз, сколько бы сообщений ни пришло.
• Сверка — сравнение платежей в платёжной системе с оплатами в CRM для поиска расхождений.
• Возврат и отмена — операции, после которых деньги возвращаются клиенту полностью или частично и оплата в CRM должна быть скорректирована.
• Неопознанный платёж — платёж, для которого не удалось найти клиента или счёт.

Что автоматизировать первым

1. 01Уведомление об оплате. Платёж пришёл — оплата отмечена в карточке клиента, ответственный получает сообщение в рабочий чат, клиент — подтверждение. Это база, на которой держится всё остальное.
2. 02Ежедневная сверка. Раз в день система сравнивает платежи в платёжных системах с оплатами в CRM и показывает расхождения: платёж без клиента, оплату без платежа, разные суммы.
3. 03Напоминание о задолженности. CRM знает, кто и сколько должен, и в назначенный день отправляет клиенту вежливое напоминание со ссылкой на оплату. Менеджер видит список тех, кто не заплатил после напоминания, и звонит уже им.
4. 04Выгрузка для бухгалтерии. Данные об оплатах в формате, который удобно загружать в учётную систему, вместо ручного переноса.
5. 05Отчёты для руководителя. Поступления за день, за неделю, по филиалам и способам оплаты — в чат или на панель, без запроса к бухгалтеру.

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

Пример: как выглядит поток оплаты в учебном центре

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

Шаг 1. Счёт

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

Шаг 2. Оплата

Родитель платит по ссылке. Платёжная система проводит платёж и отправляет уведомление на адрес, который указан в настройках мерчанта. Промежуточное звено проверяет, что уведомление действительно пришло от платёжной системы, и ищет счёт по номеру.

Шаг 3. Отметка в CRM

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

Шаг 4. Уведомления

Родитель получает короткое подтверждение: сумма, за что, спасибо. Администратор филиала видит оплату в рабочем чате. Учитель, если это предусмотрено правилами центра, видит, что у ученика больше нет долга, — но не видит суммы, которые ему знать не нужно.

Шаг 5. Наличные и другие способы

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

Шаг 6. Сверка и напоминания

Утром система сравнивает вчерашние платежи в кабинетах платёжных систем с оплатами в CRM. Расхождения уходят ответственному. В назначенный день тем, у кого остался долг, уходит напоминание — только после того, как сверка за прошлые дни закрыта.

Как выбрать схему: решения, которые нужно принять заранее

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

• Если у клиента бывает несколько услуг одновременно, выставляйте счёт на каждую услугу или явную строку в счёте, потому что иначе неясно, какую из них закрывает частичная оплата.
• Если клиенты платят сами через приложение, без вашей ссылки, выбирайте короткий и проверяемый идентификатор и показывайте его в каждом сообщении, потому что ошибку в длинном номере клиент не заметит.
• Если за одного клиента платят разные люди, привязывайте платёж к счёту, а не к плательщику, потому что плательщик и получатель услуги — разные роли.
• Если у компании несколько филиалов с разными счетами мерчанта, фиксируйте филиал в счёте, а не определяйте его по сумме или времени, потому что только так платёж надёжно попадёт в нужную кассу.
• Если CRM не поддерживает платёжные системы напрямую, а платежей немного, начните со сценария в платформе автоматизации, потому что это быстрее; если платежей много или логика сложная, закажите отдельный сервис, потому что его проще проверять и поддерживать.
• Если переплата возможна, решите, куда она идёт — на следующий период или на баланс клиента, — и запишите правило, потому что иначе каждый администратор будет поступать по-своему.

Сверка: как устроить ежедневную проверку

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

1. 01Раз в день выгрузите список платежей за прошедшие сутки из кабинета каждой платёжной системы — вручную или автоматически, если это доступно.
2. 02Сопоставьте каждый платёж с оплатой в CRM по идентификатору платежа.
3. 03Выделите три списка: платёж есть, оплаты нет; оплата есть, платежа нет; суммы или статусы не совпадают.
4. 04Отправьте списки ответственному с понятным сроком разбора.
5. 05Каждое расхождение закройте с пометкой причины: не дошло уведомление, ошибка клиента в номере, возврат, ручная правка.
6. 06Раз в неделю посмотрите на причины: если одна повторяется, исправляйте процесс, а не отдельные записи.

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

Напоминания о долге и разговор о деньгах в мессенджерах

Уведомления об оплате и напоминания о долге чаще всего уходят в Telegram или по SMS. Тон здесь решает многое. Подтверждение оплаты — короткое и конкретное: сумма, за что, спасибо. Напоминание о долге — вежливое, без угроз, с суммой, сроком и ссылкой на оплату.

• Не отправляйте напоминание, если сверка за прошлые дни не закрыта.
• Не шлите несколько напоминаний подряд: одно в назначенный день, дальше — звонок менеджера.
• Не пишите о долге в общий чат группы или туда, где сообщение увидят посторонние.
• Отправляйте напоминание в рабочее время, а не ночью.
• Дайте клиенту простой способ сказать «я уже заплатил» — и чтобы это сообщение попадало к человеку, который может проверить платёж.
• Для SMS используйте тексты, согласованные с провайдером, если он этого требует, иначе сообщения могут не дойти.

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

Связь с бухгалтерией и 1С

Во многих компаниях учёт ведётся в 1С или другой учётной системе, и CRM не должна с ней конкурировать. Удобное разделение такое: CRM отвечает за клиента, его счета и историю оплат, учётная система — за бухгалтерский и налоговый учёт. Между ними регулярно передаются данные об оплатах в согласованном с бухгалтером формате.

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

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

Типичные ошибки и как их поймать

• Двойной зачёт. Платёжная система прислала уведомление дважды, и оплата записалась два раза. Как поймать: в CRM не должно быть двух оплат с одним идентификатором платежа; настройте проверку и сделайте обработку идемпотентной.
• Оплата не тому клиенту. Сопоставление шло по имени или сумме. Как поймать: в сверке смотрите платежи, где плательщик и клиент не совпадают; переходите на идентификатор счёта.
• Тихие неопознанные платежи. Платёж без клиента никто не видит, а клиент получает напоминание о долге. Как поймать: список неопознанных платежей должен иметь ответственного и срок разбора.
• Отмена без последствий. Платёж отменён в платёжной системе, а в CRM оплата осталась. Как поймать: сверка должна сравнивать не только наличие, но и статус платежа.
• Поддельное уведомление. Кто-то отправил на ваш адрес сообщение, похожее на уведомление о платеже. Как поймать: проверяйте подлинность каждого уведомления способом, который описан в документации платёжной системы, и при сомнении запрашивайте статус платежа напрямую.
• Наличные мимо системы. Часть оплат учитывается в тетради. Как поймать: долги в CRM регулярно сравнивайте с кассой филиала.
• Ключи в открытом виде. Доступы к платёжным системам лежат в таблице или переписке. Как поймать: проведите ревизию, перенесите ключи на сервер, смените их и сократите круг людей с доступом.
• Напоминание по старым данным. Напоминания ушли до того, как дошли вчерашние платежи. Как поймать: запускайте напоминания только после закрытой сверки.

Чек-лист запуска интеграции

• Выбран однозначный идентификатор, по которому платёж связывается с клиентом или счётом.
• Основной способ оплаты — ссылка с вшитым идентификатором, а не ручной ввод номера клиентом.
• Обработка уведомлений идемпотентна: повтор не засчитывается дважды.
• Подлинность каждого уведомления проверяется.
• Описано, что происходит при отмене, возврате, частичной оплате и переплате.
• Неопознанные платежи попадают в отдельный список с ответственным и сроком.
• Наличные и другие способы оплаты учитываются в той же CRM и в тех же счетах.
• Ежедневная сверка показывает расхождения, и кто-то их разбирает.
• Границы дня и часовой пояс учтены при сверке.
• Напоминания о долге включены только после того, как данные об оплатах сходятся.
• Тексты напоминаний согласованы и не содержат угроз.
• Ключи доступа к платёжным системам хранятся на сервере, круг доступа минимален.
• Бухгалтер подтвердил порядок работы с чеками и выгрузкой в учётную систему.
• Изменения в расчёте долга проверены на реальных данных по старым и новым правилам.

Итог

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