---
title: "ЮKassa и n8n: платежи, статусы, CRM и сверка — Nodbot"
source_url: "https://nodbot.ru/russia/yookassa/"
canonical_url: "https://nodbot.ru/russia/yookassa/"
language: "ru"
content_type: "KnowledgePage"
section: "russia"
generated_at: "2026-05-30"
word_count_source: 1008
---

# ЮKassa и n8n: платежи, статусы, CRM и сверка

## AI summary

ЮKassa и n8n: webhooks оплат, подписи, статусы платежей, идемпотентность, CRM и учёт ошибок.

## Best used for

Страница объясняет «ЮKassa и n8n: платежи, статусы, CRM и сверка — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Что автоматизировать через n8n
- Рабочая схема webhook → CRM
- Минимальный контракт данных
- Как не создать дубль оплаты
- Как маппить оплату в CRM
- Частые проблемы
- Готовые материалы
- Официальные источники

## Source outline

# Ю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 от дублей

## Официальные источники

- ЮKassa: входящие уведомления
- ЮKassa API
- n8n Webhook node

## 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.

## Особенности внедрения в российском стеке

Страницу «ЮKassa и n8n» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным.

Базовый источник для проверки: лид, сделка, контакт или задача из CRM с external_id и ответственным. Главный риск — создать дубли, перезаписать статус сделки или потерять ответственного при повторной доставке события.

- Слой | Что зафиксировать | Зачем
- Вход | лид, сделка, контакт или задача из CRM с external_id и ответственным | позволяет повторить проблему без доступа к production-секретам
- Контроль | created_vs_updated, duplicate_rate, api_429_count, manual_review_count, owner_missing_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | создать дубли, перезаписать статус сделки или потерять ответственного при повторной доставке события | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «ЮKassa и n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "external_id": "lead_12345",
  "source": "webhook|form|chat|email",
  "contact": {"email_hash": "sha256:...", "phone_masked": "+7***"},
  "stage": "new|qualified|waiting",
  "owner_id": "crm_user_id",
  "dedupe_policy": "update_existing_before_create"
}
```

### Критерий готовности

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.