Публичные webhook и риск недоплаты на сайтах из ИИ-сборки

Прямой ответ

Если платёжные или процессные webhook можно вызвать без проверки подлинности и они принимают суммы с клиента, атакующий создаёт дешёвые счета или запускает бизнес-процессы. Суммы и идентичность товара должны быть авторитетны на сервере.

Сборка в ИИ-чате часто «для удобства» делает /api/pay и /api/webhook открытыми. Это не удобство - это дыра.

Что это значит на практике

• Начинайте с реального платёжного и fulfilment-процесса, не с демо-кнопки Checkout.
• Опишите простым языком: кто выставляет сумму, кто подтверждает оплату, кто открывает доступ.
• Проверьте каждый путь, где клиентский браузер может подменить amount, plan id или coupon.
• Оставьте ручной путь для спорных платежей и возвратов.

Как выглядит хорошо

• Webhook с проверкой подписи провайдера (Stripe и аналоги).
• Сумма и product id берутся из серверного прайса / заказа, не из body клиента.
• Идемпотентная обработка: повтор webhook не выдаёт двойной доступ.
• Логи: event id, order id, результат, ошибки.
• Ключи и секреты только на сервере; стоп-кнопка на выдачу доступа.

Как выглядит плохо

• «В превью оплата проходит» без проверки подписи.
• Публичный endpoint «отметить оплаченным» без auth.
• Цена и plan id доверяются query/body с фронта.
• Нет сверки underpay / overpay.
• Тонкий машинный лендинг «оплата» без серверной модели заказа.

Типичные атаки

1. Underpayment - клиент шлёт amount=1, сервер открывает premium.
2. Replay - старый успешный event гоняется повторно.
3. Forged webhook - POST без подписи, как будто от Stripe.
4. Workflow trigger - открытый URL запускает скидку, письмо, CRM-сделку.

Как Dali это закрывает

Укрепляем путь оплаты и процессов: спасение vibe-кода, платежи и секреты, лимиты admin/promo. Связанное: боевые агенты, точки контроля.