Сверка заказов и платежей в n8n: как находить расхождения без двойной обработки

MAATRIX · 17 октября 2026 · 8 мин чтения

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

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

Заказ и платёж — разные сущности

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

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

Для учебного процесса возьмём магазин с собственной базой заказов и ЮKassa. Если у вас другой провайдер, принципы остаются, но статусы, способы проверки уведомлений и интерфейсы нужно брать из его документации. Универсального поля «деньги точно получены» для всех систем не существует.

Разберите статусы до первой сверки

В ЮKassa состояние waiting_for_capture означает ожидание подтверждения платежа, а succeeded — успешное завершение соответствующего процесса. Не следует считать ожидание подтверждения равнозначным окончательной оплате. Жизненный цикл описан в документации о процессе платежа.

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

Суммы сравнивайте вместе с валютой и в точном представлении. Строка десятичной суммы из API не должна превращаться в приблизительное число с плавающей точкой. Учитывайте частичные оплаты, скидки и доставку, если они входят в вашу модель заказа. Сначала зафиксируйте ожидаемую сумму на момент создания попытки, затем сравнивайте с ней.

Не используйте текущую цену каталога для проверки старого заказа. Товар мог подорожать после покупки. Для сверки важны условия конкретной операции, а не сегодняшняя витрина.

Два канала: быстрый и проверочный

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

На входе уведомлений сначала проверьте структуру и сохраните событие в устойчивую очередь. Отвечайте провайдеру в соответствии с его протоколом. Для ЮKassa подтверждение получения — HTTP 200; особенности повторной доставки приведены в документации вебхуков. Нельзя отправлять успешное подтверждение и затем надеяться, что несохранённое событие как-нибудь восстановится.

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

Повторные уведомления допустимы. Уникальный ключ события или сочетание объекта и перехода состояния должны позволять обработать их без повторной выдачи товара. Порядок поступления также не стоит считать гарантированным, если это прямо не обещано API.

Настраиваем read-only сверку в n8n

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

Затем HTTP Request получает состояние платежа по документированному методу провайдера. Для ЮKassa используйте запрос получения информации о платеже из справочника API. Настройте credentials для своего магазина, а адрес и ID объекта формируйте только из проверенных значений. Тестовые и рабочие ключи храните раздельно.

В Edit Fields соберите обе стороны сравнения: ожидаемую сумму и валюту, актуальные значения провайдера, статус заказа, статус платежа и время проверки. Добавьте явный признак тестового режима. Тестовый успешный платёж не должен разрешать выдачу настоящего товара.

Узел IF или Switch распределяет результаты по понятным категориям. Например: состояния согласованы; провайдер подтверждает оплату, магазин ещё нет; магазин считает заказ оплаченным, подтверждения нет; сумма или валюта отличаются; операция не найдена; API временно недоступен. Последняя категория не является финансовым расхождением — это невозможность завершить проверку.

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

Очередь исключений должна объяснять проблему

У каждой записи покажите ID заказа и платежа, ожидаемые и фактические значения, источник проверки, время и предложенный следующий шаг. Не отправляйте в общий чат платёжные реквизиты или полный ответ API. Обычно достаточно номера случая и ссылки на закрытую карточку.

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

Решение сотрудника тоже записывайте. «Связали с другой попыткой оплаты», «исправили статус заказа», «передали в поддержку провайдера» — разные результаты. Комментарий помогает следующему специалисту не начинать расследование заново.

Важен возраст проблемы. Свежая задержка уведомления и расхождение, существующее несколько дней, требуют разного внимания. Порог задавайте по процессу и документированным задержкам интеграции, не объявляя любую секунду ожидания аварией.

Исправление статуса не равно повтору платежа

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

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

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

При обращении к изменяющим методам изучите правила идемпотентности ЮKassa. Ключ относится к конкретной операции; новый ключ при каждом повторе не защищает от повторного действия. Но даже правильный ключ не заменяет проверку того, что сам запрос соответствует заказу.

Возвраты и поздние события

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

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

После временного сбоя n8n повторно проверяет накопившиеся записи. Ограничьте частоту API-запросов и сохраняйте позицию обхода. Не запускайте всю годовую историю одновременно после каждого перезапуска сервера.

Приёмка на тестовых операциях

Проверьте успешную оплату, отмену, ожидание подтверждения, повтор уведомления, частичный возврат и несовпадение суммы. Отдельно имитируйте недоступность API: заказ не должен стать неоплаченным только потому, что проверка временно не состоялась.

Затем отправьте одно событие дважды и запустите параллельные проверки. В журнале должен остаться один бизнес-результат, а доступ или товар не должны выдаваться повторно. Перед рабочим запуском сверяйте данные вручную на ограниченном наборе и сохраняйте найденные исключения как тестовые примеры.

Для n8n с внешним магазином и небольшим реестром можно начать с VPS MAATRIX Uab Start с 4 GB RAM. При собственной базе и нескольких интеграциях рассмотрите Heka Standard с 8 GB, измерив нагрузку. Подойдёт поддерживаемая Ubuntu или Debian. Ограничьте доступ к ключам, не храните лишние платёжные данные в истории выполнений и резервируйте журнал сверки.

На VPS MAATRIX с n8n проверка сможет работать по расписанию. Её результат — не ещё одна таблица с цветными статусами, а короткий список конкретных расхождений, с которыми человек понимает, что делать дальше.