ЮKassa и n8n: платежи, статусы, CRM и сверка ¶
Обновлено: 2026-05-29
ЮKassa чаще всего подключают к n8n не ради “уведомления об оплате”, а ради сквозного процесса: клиент оплатил заказ, CRM получила новый статус, менеджер увидел событие, бухгалтерия получила данные для сверки, а повторный webhook не создал второй заказ. В n8n такой сценарий удобно строить через Webhook node, нормализацию payload, проверку уникальности события и запись результата в CRM или учётную систему.
Главная ошибка — считать webhook от платёжки окончательной бизнес-командой. На практике его нужно принять быстро, сохранить технические поля, проверить тип события, связать payment/order ID с вашей CRM и только потом запускать дальнейшие действия: статус сделки, задача менеджеру, письмо клиенту, строка в отчёте.
Что автоматизировать через n8n
| Сценарий | Что делает n8n | Где хранить результат |
|---|---|---|
| Оплата заказа | принимает уведомление, ищет заказ, меняет статус | CRM, CMS, таблица сверки |
| Платёж ждёт подтверждения | ставит задачу или ждёт финального события | CRM timeline, Telegram, Postgres |
| Возврат | обновляет сделку и помечает строку отчёта | CRM, бухгалтерский экспорт |
| Повторное уведомление | проверяет event/payment ID и не выполняет write-действия повторно | Postgres, Google Sheets, Data Store |
| Ежедневная сверка | сравнивает платежи, заказы и CRM-статусы | отчёт, Telegram, email |
Рабочая схема webhook → CRM
- В ЮKassa указываете production URL активного n8n workflow.
- Webhook node принимает событие и сразу отделяет headers, body, event ID, object ID и тип события.
- IF/Switch пропускает только нужные события: например, успешную оплату, ожидание подтверждения или возврат.
- n8n проверяет, обрабатывался ли уже этот
event_idилиpayment_id. - HTTP Request получает актуальный объект платежа или обновляет связанную CRM-сущность.
- В CRM записываются только нормализованные поля: сумма, валюта, статус, order ID, payment ID, источник.
- Respond to Webhook возвращает короткий ответ, чтобы платёжный сервис не ждал долгую CRM-цепочку.
Минимальный контракт данных
Сразу договоритесь, какие поля проходят через весь workflow. Это упрощает отладку, сверку и переход между CRM.
| Поле | Зачем нужно | Пример |
|---|---|---|
event_id | защита от повторной обработки уведомления | evt_... |
payment_id | связь с объектом платежа | 2f... |
order_id | связь с заказом, сделкой или счётом | order_1042 |
amount_value | сумма для CRM и сверки | 9900.00 |
currency | валюта платежа | RUB |
payment_status | бизнес-статус для CRM | succeeded |
received_at | время получения события в n8n | 2026-05-29T10:15:00+03:00 |
Как не создать дубль оплаты
Для платёжных событий idempotency обязательна. Один и тот же платёж может прийти повторно из-за сетевой ошибки, таймаута, ручной повторной отправки или переигрывания события. Если workflow сразу обновляет CRM без проверки, появятся две задачи, два комментария или неверная история оплаты.
Надёжная схема: перед CRM-действиями сделать lookup по event_id или связке payment_id + event_type. Если запись уже есть, workflow возвращает accepted_duplicate и завершает выполнение без повторного изменения сделки.
{
"source": "yookassa",
"event_id": "{{$json.body.id}}",
"payment_id": "{{$json.body.object.id}}",
"event_type": "{{$json.body.event}}",
"processed_at": "{{$now}}"
}Как маппить оплату в CRM
| В ЮKassa | В CRM | Комментарий |
|---|---|---|
| payment succeeded | сделка оплачена | не закрывайте сделку, если нужна доставка или акт |
| payment waiting_for_capture | статус “ожидает подтверждения” | назначьте задачу ответственному |
| payment canceled | отмена/неуспешная оплата | оставьте причину в комментарии |
| refund succeeded | возврат выполнен | помечайте отдельным событием, а не стирайте оплату |
Частые проблемы
| Симптом | Что проверить | Как чинить |
|---|---|---|
| Уведомление не приходит | production URL, HTTPS, активен ли workflow | отправить тестовый POST в n8n и проверить executions |
| Оплата есть, CRM не обновилась | ветка IF/Switch, тип события, ID заказа | логировать normalized payload перед CRM-ноду |
| Две задачи по одной оплате | нет проверки event/payment ID | добавить таблицу обработанных событий |
| CRM получила неправильную сумму | строка/число, копейки, валюта | нормализовать amount до CRM-действия |
| Платёж завис в промежуточном статусе | ожидание подтверждения или финального события | сделать отдельную ветку ожидания, а не считать это ошибкой |
Готовые материалы
- Workflow: ЮKassa payment → CRM
- Диагностика webhook ЮKassa
- Карта внедрения: ЮKassa → CRM → учёт
- Защита webhook от дублей
Официальные источники
FAQ
Нужно ли после webhook запрашивать платёж через API?
Для критичных операций лучше да: webhook даёт событие, а отдельный запрос помогает получить актуальное состояние объекта и не полагаться на неполный payload.
Что возвращать в ответ на webhook?
Короткий JSON с подтверждением приёма. Долгие операции — CRM, AI, таблицы, отчёты — лучше выполнять после быстрого ответа или через отдельную ветку.
Как отличить повтор события от новой оплаты?
Сохраняйте event ID и payment ID. Если связка уже обработана, не повторяйте write-действия в CRM, а завершайте workflow как повторное уведомление.
Production-чеклист для ЮKassa-интеграции
Используйте этот блок как быстрый контроль перед публикацией workflow или изменением существующей автоматизации. Он не заменяет staging, но помогает поймать самые частые отказы заранее.
- Перед запуском: проверить подпись, payment_id, status, идемпотентность и связку с CRM.
- Минимальный тест: отправить тестовые succeeded/canceled/pending события и повтор того же события.
- Типовой отказ: повторный webhook меняет сделку дважды или создаёт дубль оплаты.
- Что логировать: входной payload без секретов, статус внешнего API, branch ошибки, execution id и владельца процесса.
Критерий готовности: сценарий проходит успешный путь, ошибочный путь и повтор события без дублей, потери данных и неконтролируемого падения execution.