Мегаплан и Prodamus: как связаны платёж и передача заказа

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

Что сообщает октябрьский анонс

В публикации Мегаплана, обновлённой 7 октября 2026 года, описан виджет оплаты в карточке процесса. Он использует позиции блока «Заказ» либо общую сумму, если блока нет; поддерживаются рубли. После результата оплаты регистрируются поступление и комментарий, а изменение статуса требует настроенного сценария.

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

Один учебный заказ от ссылки до работы

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

По анонсу при отличии полученной суммы от ожидаемой платёж фиксируется, сотрудник получает уведомление, а статус требует ручной проверки. Не заменяйте такую проверку общим правилом «любое поступление запускает заказ». Особенно если условия исполнения зависят от согласованного объёма оплаты.

Канал уведомлений должен быть частью приёмки

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

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

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

Как проверить передачу заказа без реального списания

1. Зафиксируйте актуальный состав учебного заказа и ожидаемый результат оплаты.
2. Определите, какое подтверждение разрешает следующий этап процесса.
3. Проверьте согласованный способ тестирования интеграции без платежа клиента.
4. Разберите изменение заказа после формирования ссылки.
5. Проверьте случай расхождения суммы и задержки отражения в CRM.
6. Сопоставьте поступление, комментарий и итоговый статус процесса.
7. Передайте сотруднику инструкцию проверки, не содержащую секретов.

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

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