Платеж должен иметь один источник истины
Если сайт, CRM и ERP по-разному понимают статус оплаты, поддержка быстро получает конфликтные заказы.
В CRM/ERP-сценариях важно решить, какая система подтверждает оплату. Frontend не должен быть источником истины. CRM тоже не всегда должна напрямую доверять callback, если сначала требуется проверка подписи, суммы, валюты и order id.
Практичная модель: backend платежного слоя принимает события, проверяет их, сохраняет журнал и только после этого отправляет нормализованное событие в CRM или ERP. Так проще отлаживать спорные случаи и повторно доставлять события.
- Проверять сумму, валюту, order id и provider payment id.
- Хранить журнал входящих и исходящих событий.
- Передавать в CRM только нормализованные статусы.
- Повторно отправлять событие без повторного списания.
Как избежать дублей и гонок статусов
Дубли появляются не из-за плохого API, а из-за отсутствия idempotency и правил обработки повторных событий.
Webhook может прийти повторно, менеджер может вручную обновить счет, пользователь может нажать оплату несколько раз. Это нормальные edge cases, которые нужно учитывать до запуска.
Защита строится на уникальных ключах. У заказа есть внутренний id, у платежа - provider id, у операции - idempotency key. Повторное событие с тем же ключом не должно создавать новый заказ, новый счет или новый чек.
- Уникальный ключ на попытку оплаты.
- Проверка текущего статуса перед изменением заказа.
- Запрет переходов из финального статуса в промежуточный.
- Отдельный аудит ручных действий менеджеров.
Какие поля передавать в CRM/ERP
Минимальный набор данных должен помогать бухгалтерии, поддержке и разработчикам восстановить платежную историю.
В CRM или ERP не нужно отправлять весь сырой ответ провайдера как основной объект. Лучше передавать нормализованную структуру, а raw payload хранить в техническом журнале.
Для поддержки важно видеть сумму, валюту, статус, время оплаты и внешний номер транзакции. Для учета - связь со счетом, заказом и фискальным чеком. Для разработчиков - correlation id и история webhook-событий.
- Внутренний order id и внешний payment id.
- Сумма, валюта, статус, timestamps.
- Ссылка на счет, клиента и канал продажи.
- Фискальный статус и номер чека, если применимо.
- Correlation id для поддержки и логов.
FAQ
Нужно ли CRM напрямую принимать webhook от платежного провайдера?
Обычно лучше принимать webhook на backend платежного слоя, проверять событие и затем отправлять нормализованный статус в CRM.
Как обрабатывать повторный webhook?
Через idempotency: повторное событие с тем же payment id или event id не должно создавать новый бизнес-объект.
Что логировать для поддержки?
Order id, payment id, сумму, валюту, статус, timestamps, provider response code, correlation id и историю доставки событий.
