Один и тот же скидочный модификатор принимается сервером многократно в одном заказе. Дубли не отсекаются, итоговая сумма уходит в 1–2% от реальной, платёжная ссылка всё равно выдаётся.
- Создать заказ на товар стоимостью 3 550 ₽.
- В массиве options[] передать скидочный модификатор −698 ₽ пять раз.
- Сервер суммирует все пять вместо дедупликации → full_amount = 60,00 ₽.
- Платёжный шлюз принимает сумму, выдаёт payment_url, автодоставка срабатывает.
POST /api/v1/orders · PATCH /api/v1/orders/{uuid}
Цифровой товар: 3 550 ₽ → 60,00 ₽. Воспроизведено на 6 разных позициях, платёжная ссылка выдана в каждом случае. PoC остановлен до оплаты.
Продавец получает 1–2% выручки за товар, разница — прямой убыток. При автоматической выдаче товара ущерб невосполним: он уходит до того, как расхождение заметят.
Нет серверного пересчёта суммы перед выдачей платёжной ссылки; модификаторы не дедуплицируются; сервер доверяет сумме, пришедшей от клиента.
- Пересчитывать итог на сервере из каталога, игнорируя цену и сумму из запроса.
- Дедуплицировать модификаторы; запрещать итог ниже пороговой маржи.
- Валидировать количество как целое число ≥ 1.
- Ре-валидировать сумму на стороне платёжного шлюза перед выдачей ссылки.
2–3 человеко-дня бэкенда с регрессом на корзину и промо. Компенсирующая мера на сегодня: жёсткий порог минимальной суммы заказа на стороне шлюза.
C-ORDER-FRACTIONAL-QTY · C-ORDER-FLOOD
Демонстрационный пример. Значения, пути, идентификаторы и наименование товара изменены; в реальной работе карточка содержит конкретные эндпоинты, UUID, суммы клиента и ссылку на PoC-скрипт.