Промты для ИИ-агентов

Подключи приём оплаты Kaspi Pay через yespay в этот проект.

Сначала прочитай контекст yespay, который я приложил ниже (или открой
https://getyespay.com/docs/api), и только потом пиши код. Не выдумывай эндпоинты и
поля, которых там нет.

Что нужно сделать:
1. Сервис-обёртку над API yespay: создание платежа, чтение платежа по id,
   поиск по order_id, возврат. Ключ читать из переменной окружения
   YESPAY_SECRET_KEY, базовый адрес — из YESPAY_API_BASE со значением по
   умолчанию https://api.getyespay.com.
2. Создание платежа при оформлении заказа. Сумму считать на сервере из
   корзины/прайса, а не брать из запроса клиента. В Idempotency-Key класть
   идентификатор заказа.
3. Хранение связи заказ ↔ payment_id в нашей базе, вместе со статусом и
   временем последнего обновления.
4. Обработчик вебхука по отдельному промту (см. следующий шаг) — здесь только
   оставь место под него.
5. Повторы: 429/502/503 и сетевые ошибки — экспоненциальная выдержка, тот же
   Idempotency-Key, не больше 5 попыток. 4xx не повторять.

Ограничения:
- Не помечай заказ оплаченным нигде, кроме обработки payment.paid или явного
  чтения платежа из API.
- Статус unknown не считай отказом: заказ переводи в состояние «нужна проверка»
  и не отпускай товар.
- Секреты не хардкодь и не логируй; телефон покупателя в логах маскируй.

Покажи изменения по файлам и объясни, где именно заказ становится оплаченным.

Напиши обработчик вебхуков yespay для этого проекта.

Требования к проверке подписи:
- Читай СЫРОЕ тело запроса. Фреймворковый JSON-парсер для этого маршрута
  отключи — после JSON.parse/повторной сериализации подпись не сойдётся.
- Заголовок X-Yespay-Signature имеет вид "t=<unix>,v1=<hex>".
- Ожидаемая подпись = HMAC-SHA256(secret, "<t>." + сырое тело), hex.
  secret — из переменной окружения YESPAY_WEBHOOK_SECRET.
- Отклоняй событие, если |now - t| > 300 секунд.
- Сравнивай подписи в постоянном времени.
- При неудачной проверке — 400 и ничего не выполнять.

Требования к обработке:
- Дедупликация по заголовку X-Yespay-Event-Id: сохраняй обработанные id и на
  повтор отвечай 200, не выполняя работу второй раз.
- Обрабатывай типы: payment.paid, payment.failed, payment.expired,
  payment.cancelled, payment.status_unknown, refund.succeeded,
  payment_account.reauth_required.
- payment.paid: пометь заказ оплаченным. Перед этим сверь data.amount с
  суммой заказа в нашей базе; при расхождении — не помечай, заведи алерт.
- payment.status_unknown: НЕ отказ. Переведи заказ в состояние «нужна ручная
  проверка» и уведоми ответственного. Товар не отпускать, деньги не возвращать.
- payment_account.reauth_required: это операционный инцидент — уведомление
  человеку, а не запись в лог.
- Отвечай 2xx быстрее 10 секунд: тяжёлую работу ставь в очередь.
- Неизвестный тип события — отвечай 200 и игнорируй, не падай.

Добавь тесты: верная подпись, испорченная подпись, просроченный timestamp,
повторная доставка того же event id, неизвестный тип события.

Проверь интеграцию с yespay в тестовом режиме и покажи результат.

Используй ключ sk_test_... из окружения. Сценарий выбирается двумя последними
цифрами номера покупателя, поэтому прогони все ветки:
  +77001234500 → ожидается failed примерно через 5 секунд
  +77001234511 → ожидается unknown примерно через 5 секунд
  +77001234577 → остаётся pending навсегда
  +77001234599 → ожидается expired примерно через 20 секунд
  +77001234567 → ожидается paid примерно через 8 секунд

Для каждой ветки:
1. Создай платёж через наш сервисный слой (не curl-ом мимо кода).
2. Дождись финального статуса: либо через наш обработчик вебхуков, либо опросом
   GET /v1/payments/:id не чаще раза в 3 секунды, максимум 60 секунд.
3. Проверь, в каком состоянии оказался заказ в нашей базе.
4. Отдельно проверь ветку unknown: убедись, что заказ НЕ отменён и НЕ отгружен,
   а помечен как требующий проверки.

Дополнительно:
- Отправь POST /v1/webhooks/test и убедись, что проверка подписи проходит.
- Повтори доставку одного и того же события дважды и убедись, что второй раз
  ничего не выполняется.
- Дважды отправь создание платежа с одинаковым Idempotency-Key и проверь, что
  платёж один.

Отчитайся таблицей: ветка → ожидание → факт → прошло/нет. Не пиши «работает»
про то, что не выполнялось.

Сделай ревью нашей интеграции с yespay перед выходом в бой.
Проверь по пунктам и на каждый дай вердикт с ссылкой на файл и строку.

1. Секретный ключ используется только на сервере, не попадает в бандл
   фронтенда, в мобильное приложение и в репозиторий.
2. Idempotency-Key передаётся на каждом POST /v1/payments и POST /v1/refunds,
   и он детерминирован от заказа (ретрай даёт тот же ключ).
3. Подпись вебхука считается по сырому телу, проверяется возраст события
   (<= 300 c) и сравнение идёт в постоянном времени.
4. Обработчик вебхука идемпотентен по X-Yespay-Event-Id.
5. Заказ помечается оплаченным только по payment.paid или по чтению платежа из
   API, а не по редиректу покупателя.
6. Сумма заказа сверяется с data.amount из события.
7. Статус unknown нигде не трактуется как отказ, отмена или повод вернуть деньги.
8. Обработка payment_account.reauth_required доходит до человека.
9. Повторы делаются только для 429/502/503 и сетевых ошибок, с выдержкой.
10. Телефоны и секреты не попадают в логи.

Формат: пункт → статус (ок / нарушено / не применимо) → где → что исправить.
Если чего-то в коде нет, так и скажи, не додумывай.

Подключи оплату Kaspi через yespay к моему боту/агенту как инструмент.

Опиши агенту ровно два действия и ничего сверх:
  create_payment(amount_kzt: int, phone: str, order_id: str, description: str)
    → POST /v1/payments с Idempotency-Key = order_id, возвращает payment_id и статус
  get_payment(payment_id: str)
    → GET /v1/payments/:id, возвращает статус и сумму

Правила, которые агент нарушать не должен:
- Сумму агент не выбирает сам: она приходит из прайса/корзины на нашей стороне.
- Агент не имеет доступа к возвратам. Возврат делает человек.
- Ответ «оплачено» агент даёт только при status == "paid".
- При status == "unknown" агент отвечает «оплата уточняется» и передаёт диалог
  оператору. Не «не оплачено».
- Ключ sk_live_... находится в серверном коде инструмента, агент его не видит и
  не может подставить в запрос сам.