Frontend не должен быть источником истины
Клиентский код может показать сообщение об успехе, но не должен финально менять заказ.
Основной принцип безопасности платежей: frontend не подтверждает оплату. Он может отправить пользователя на checkout и показать результат, но финальное решение принимает backend после проверки статуса.
Если заказ меняется в paid только из браузера, злоумышленник или ошибка клиента может привести к ложным статусам. Поэтому любые критичные изменения должны проходить через серверную проверку.
- не доверять success redirect без проверки;
- проверять сумму, валюту и order id на backend;
- сохранять внешний payment id;
- менять бизнес-статус только после доверенного события.
Webhook endpoint должен быть защищенным
Webhook принимает внешние события, поэтому его нельзя оставлять как публичную форму без проверки.
Webhook endpoint должен проверять подлинность события способом, который поддерживает конкретный провайдер. Это может быть подпись, секрет, доверенный канал или дополнительная server-side verification.
Также endpoint должен быть идемпотентным. Повторная доставка одного события не должна создавать новый заказ, новый чек или повторную отправку в CRM.
- проверка подписи или доверенного механизма;
- защита от replay и повторных событий;
- быстрый технический ответ провайдеру;
- очередь для тяжелых downstream-интеграций.
Права доступа и ключи нужно учитывать с первого дня
Интеграционные ключи, raw payload и ручные исправления должны иметь владельца и аудит.
Даже MVP платежей должен иметь понятный доступ к настройкам и логам. Кто может видеть raw response провайдера, кто может повторить доставку события и кто может вручную исправить статус?
Если эти роли не определить, поддержка и разработка быстро начнут пользоваться общими ключами и ручными правками без следа. Это риск для платежей и клиентского доверия.
- минимально необходимые права для каждой роли;
- маскирование чувствительных данных в логах;
- владелец и срок жизни интеграционных ключей;
- аудит ручных изменений и повторных доставок.
FAQ
Достаточно ли HTTPS для безопасной оплаты?
Нет. HTTPS необходим, но дополнительно нужны backend verification, защищенные webhooks, idempotency, журналирование и контроль доступа.
Можно ли хранить карточные данные в CRM?
В общем случае сайт и CRM не должны хранить полные карточные данные. Такие данные должны обрабатываться на стороне платежного провайдера.
Что проверять перед запуском оплаты?
Проверить server-side status verification, webhook security, retries, idempotency, логи, права доступа и сценарии ошибок.
