Логи должны отвечать на вопросы поддержки
Главный критерий платежного журнала: можно ли восстановить историю заказа без доступа к коду.
Когда клиент пишет "деньги списались, а заказ не обновился", поддержке нужно быстро увидеть цепочку событий. Если есть только raw callback или только статус в CRM, расследование становится долгим.
Платежный backend должен хранить понятную timeline: кто создал заказ, какой payment id выдан, какие события пришли от провайдера, что отправилось в CRM/ERP и что произошло с фискальным чеком.
- order id и payment id во всех связанных событиях;
- correlation id для сквозного поиска;
- timestamps создания, обновления и доставки;
- статус каждой внешней интеграции.
Что нельзя бездумно писать в лог
Логирование не должно превращаться в хранилище чувствительных данных.
Платежные логи должны помогать расследованию, но не должны хранить полные карточные данные или лишнюю персональную информацию. Доступ к raw payload лучше ограничивать и маскировать чувствительные поля.
Практичный подход: нормализованные поля доступны поддержке, raw provider payload доступен только технической роли и только когда нужен разбор инцидента.
- маскировать чувствительные значения;
- не хранить полные карточные данные во внутренних логах;
- разделять технические и операционные роли;
- фиксировать ручные просмотры и исправления.
Какие события логировать обязательно
Логировать нужно не только ошибки, но и успешные переходы состояния.
Если логируются только ошибки, невозможно доказать, что корректные события действительно прошли. Для платежей важна полная история переходов и внешних доставок.
Отдельно стоит логировать запрещенные переходы статусов. Например, если поздний pending пытается перезаписать paid, это не должно менять заказ, но должно быть видно разработчикам.
- создание платежной попытки;
- ответ провайдера и внешний payment id;
- webhook/callback receipt;
- переход бизнес-статуса;
- доставка в CRM/ERP/фискальный сервис.
FAQ
Нужно ли хранить raw response провайдера?
Да, но с ограниченным доступом и маскированием чувствительных данных. Для поддержки обычно достаточно нормализованных полей.
Что такое correlation id?
Это сквозной идентификатор, который помогает найти все события одного заказа или платежа в разных логах и системах.
Логировать только ошибки достаточно?
Нет. Для платежей важно видеть и успешные события, чтобы восстановить полную цепочку обработки.
