Как передавать оплаты из Prodamus в amoCRM: статусы, дубли и контроль сбоев

Оплата прошла в Prodamus, менеджер открыл amoCRM, а сделка всё ещё висит в статусе «Счёт отправлен». Клиент уже ждёт доступ к курсу, отдел продаж считает оплату вручную, продюсер смотрит в отчёт и не понимает, сколько денег реально пришло с запуска.

Так выглядит не отсутствие интеграции. Так выглядит слабая передача оплат.

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

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

Оплата в CRM - это не галочка «оплачено». Это точка, от которой дальше живёт вся воронка: доступ, сегмент, дожим, отчётность и работа менеджеров.

Зачем вообще передавать оплаты из Prodamus в amoCRM

На маленьких объёмах ручная сверка кажется терпимой. Менеджер открыл Prodamus, нашёл платёж, перешёл в amoCRM, сменил этап сделки, написал комментарий, поставил задачу, отправил сообщение клиенту.

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

Представим запуск на 300 оплат за два дня. На одну ручную проверку уходит хотя бы 2 минуты: открыть платёж, найти клиента в amoCRM, проверить сумму, обновить сделку, записать комментарий. Это уже 600 минут, то есть 10 часов чистой механики. И это без ошибок, без дублей, без «а он оплатил с другой почты», без частичных оплат и без переписки в Telegram.

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

Главная ценность такой связки не в экономии пары кликов. Она в том, что отдел продаж перестаёт жить отдельно от фактических денег.

Почему ручная сверка ломается на масштабе

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

Клиент говорит: «Я оплатил». Менеджер отвечает: «Сейчас проверю». В Prodamus платёж есть. В amoCRM сделка не обновлена. А в рассылке человек всё ещё получает дожим «успейте оплатить до полуночи».

Снаружи это выглядит как мелочь. Для клиента, как ощущение бардака.

Самые частые точки поломки:

1. Человеческий фактор. Менеджер забыл сменить статус, выбрал не тот этап, не записал сумму или записал её в комментарий вместо поля.
2. Пики оплат. После эфира или дедлайна оплаты приходят пачками, и ручная обработка начинает отставать.
3. Дубли контактов. Один и тот же человек оставляет заявку с одной почты, оплачивает с другой, а телефон указывает в третьем формате.
4. Несколько сделок на одного клиента. У клиента может быть сделка по консультации, по вебинару и по основному курсу. Платёж надо прикрепить не «куда-нибудь», а к правильной сделке.
5. Возвраты и частичные оплаты. Продажа уже учтена, но деньги вернули или получили не всю сумму. CRM продолжает показывать красивую картинку, которая не совпадает с реальностью.
6. Сбой уведомления. Webhook не дошёл, обработчик вернул ошибку, сценарий остановился, а команда узнаёт об этом только от клиента.

Если 10 оплат из 300 не попали в CRM, отдел продаж видит искажённую картину: кому звонить, кого дожимать, кому уже выдавать доступ, какие менеджеры закрывают лучше. На одном запуске такая ошибка стоит не только времени.

Какие есть способы связать Prodamus и amoCRM

Связать Prodamus и amoCRM можно несколькими способами. Ошибка - выбирать инструмент только по принципу «быстрее подключить». Для базовой передачи статуса подойдёт одно решение, для воронки с условиями, выдачей доступа и контролем сбоев - другое.

В Vakas-tools такой вариант оформлен как сценарий передачи оплат Prodamus → amoCRM: Prodamus становится источником события об оплате, amoCRM местом фиксации сделки и статуса, а между ними работает сценарный слой. Его задача не «перекинуть данные», а проверить условия, найти контакт и его сделку, записать историю, обработать сбой и запустить следующую логику.

Это и есть отличие платформенного подхода от обычного коннектора. Коннектор отвечает на вопрос «как передать поле А в поле Б». Управляющий слой отвечает на вопрос «что должно произойти с клиентом после оплаты, повтора уведомления или сбоя».

Что именно нужно передавать в amoCRM

Минимальный набор данных выглядит так:

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

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

Например, после успешной оплаты можно записать сумму в поле «Оплачено», номер заказа в поле «ID оплаты», добавить примечание «Оплата Prodamus: курс X, тариф Y, сумма Z», перевести сделку на этап «Оплачено» и снять задачу на дожим.

Сложные случаи: о чём спросить заранее (и что зависит от платёжки)

Большинство инструкций описывает счастливый путь: клиент оплатил, сделка обновилась. Реальная школа живёт не только в нём, но и не всё «сложное» приходит автоматически. Очень многое зависит от того, что именно платёжный сервис кладёт в уведомление об оплате. С Prodamus это особенно важно: часть данных он просто не присылает, и это нужно закладывать в процесс, а не ждать, что система догадается сама. Ниже то, о чём честно стоит договориться на этапе настройки.

Частичные оплаты и предоплаты. Для онлайн-школ предоплата обычная история: клиент внёс 5 000 рублей из 50 000, и такая сделка уже не должна висеть как холодная заявка. Здесь есть подвох именно с Prodamus: в его уведомлении не приходит надёжного «сколько осталось оплатить», поэтому отличить предоплату от полной оплаты по данным самой платёжки автоматически не выйдет. Если предоплаты для вас важны, эту логику закладывают отдельно, например, разными платёжными ссылками или отдельными этапами под частичную и полную оплату, а не рассчитывают, что Prodamus сам пометит платёж как частичный. Иначе человек с предоплатой выглядит как обычная незакрытая сделка, и менеджер работает вслепую.

Рекуррентные платежи. Тут тоже всё упирается в платёжку. С Prodamus каждое списание приходит как отдельная оплата: нет различия «первое / повторное списание», не приходит дата следующего платежа, не видно неудачных попыток и завершения подписки. То есть на стороне CRM рекуррент с Prodamus - это серия независимых оплат, а не управляемая подписка с историей. Если вам нужна полноценная подписочная картина (когда следующее списание, сколько было неудачных попыток, когда клиент отвалился), это отдельная задача, и решается она обычно не на стороне Prodamus. Перед запуском честно ответьте, нужна ли вам такая детализация и откуда она вообще возьмётся.

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

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

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

Как выглядит правильная автоматизация

Хороший сценарий начинается не с вопроса «какое поле куда передать», а с карты событий.

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

1. Prodamus отправляет уведомление об оплате.
2. Сценарий проверяет, что событие настоящее и раньше не обрабатывалось.
3. Система ищет контакт и его сделку.
4. В сделке обновляется сумма, статус, ID заказа и дата оплаты.
5. В карточку добавляется примечание с деталями платежа.
6. Клиент получает тег «оплатил курс».
7. Дожим по неоплаченным останавливается.
8. Менеджеру уходит уведомление, если нужна ручная проверка.
9. В LMS или другой системе запускается выдача доступа.
10. Событие сохраняется в истории, чтобы потом проверить, что произошло.

На практике именно пункты 2, 3 и 10 отделяют устойчивую автоматизацию от хрупкой. Пока всё работает, разницы не видно. Она появляется в день запуска, когда за 20 минут приходит 70 оплат, часть клиентов платит с других email, а одна из систем временно отвечает с ошибкой.

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

Где теряются деньги

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

Ошибка 1.

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

Мини-расчёт. Если сверка занимает 4 часа после каждого запуска, а запусков 4 в месяц, это 16 часов ручной операционки. При ставке техспеца или администратора 1 000–2 000 рублей в час выходит 16 000–32 000 рублей в месяц только на разбор того, что можно было фиксировать автоматически.

Ошибка 2.

Предоплату не отличают от полной оплаты. Клиент внёс часть суммы, но в CRM он выглядит как обычная незакрытая сделка. Менеджер либо давит слишком агрессивно, либо забывает довести до полной оплаты, и тёплые клиенты выпадают из фокуса. Тонкость в том, что с Prodamus предоплату не отличить от полной оплаты автоматически, платёжка не присылает «сколько осталось». Поэтому если предоплаты есть, отдельную логику (свой этап, поле с внесённой суммой, задачу на следующий шаг) приходится закладывать вручную, а не надеяться, что она появится сама.

Ошибка 3.

Повтор webhook создаёт дубль. Событие пришло повторно, а сценарий снова добавил оплату, снова сменил статус или снова создал комментарий. В карточке становится шумно, а отчёт начинает врать. Последствие: команда перестаёт доверять CRM и снова уходит в ручную сверку. Главная защита, хранить ID платежа или номер заказа и проверять, обрабатывалось ли событие раньше.

Как выбрать способ интеграции под свою ситуацию

Один продукт, одна воронка, один менеджер, можно начинать с готового приложения или простого webhook-сценария. Задача понятная: создать ссылку, принять оплату, перевести сделку в «Оплачено».

Несколько продуктов, вебинары, рассрочки, предоплаты, GetCourse, Tilda, Bizon365, рассылки и amoCRM - это уже не связка двух сервисов. Это стек. В стеке оплата управляет несколькими процессами одновременно: останавливает дожим в рассылке, переводит сделку, выдаёт доступ, записывает источник и тариф, уведомляет менеджера, не создаёт дубль, сохраняет историю события и показывает сбой, если что-то не дошло.

Для техспеца вопрос звучит так: где будет жить логика? В amoCRM? В коде? В коннекторе? В отдельной платформе? В таблице? У подрядчика в голове? Самый рискованный вариант, когда логика нигде толком не описана: часть условий в CRM, часть в Prodamus, часть в Make или Albato, часть в коде, часть в инструкции менеджеру. Такая схема работает месяцами, а потом ломается на первом нестандартном запуске.

Выбор проще делать по уровню сложности:

Что проверить перед запуском

Перед тем как считать интеграцию готовой, стоит пройти не только happy path. Проверьте восемь сценариев:

1. Успешная полная оплата.
2. Предоплата, видно ли в CRM, что оплата частичная.
3. Повторная отправка одного и того же уведомления.
4. Оплата клиентом с другим email.
5. Несколько сделок на один контакт.
6. Возврат и узнаёт ли о нём CRM вообще.
7. Повторное или неудачное списание по подписке, приходит ли оно в CRM.
8. Временная ошибка amoCRM или обработчика.

Если проверен только первый сценарий, автоматизация ещё не готова к запуску. Она готова только к демонстрации.

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

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

Проверить связку на своих сделках, статусах и реальных сценариях оплат можно через сценарий передачи оплат Prodamus → amoCRM  в Vakas-tools есть 14 дней триала, чтобы прогнать те самые восемь сценариев на живых данных.

Автоматизация оплат нужна не для красоты в CRM. Она нужна, чтобы в день запуска команда не спорила, кто оплатил, кому выдали доступ, кого ещё дожимать и почему отчёт по деньгам снова не сходится.