API генерации видео с оплатой в рублях: оценка, резерв и реальное списание

Три суммы, которые нельзя называть одним словом «цена»

Предварительная оценка отвечает на вопрос, во сколько запрос ориентировочно обойдётся при текущих параметрах. Резерв временно ограничивает доступную часть денег на время выполнения. Окончательное списание отражает подтверждённый расход конкретного заказа. Если смешать их в одной строке интерфейса, пользователь может увидеть будто бы двойную оплату.

В общем задании Gate эти значения разделены в billing. estimated_cost_rub относится к предварительной оценке, reserved_rub показывает текущий резерв, cost_rub — итоговое списание. Для отчёта о завершённой генерации используйте последний показатель, а не разницу доступного баланса до и после нажатия.

Долларовый upstream_cost_usd имеет другое назначение: это подтверждённый расход у провайдера. Он полезен для прозрачности, но не заменяет рублёвую стоимость клиента. Не выводите из одного примера вечный курс пересчёта: текущий расчёт Gate и параметры заказа нужно проверять отдельно.

Получите оценку того запроса, который отправите

Для общего маршрута POST /v1/media/estimate принимает тот же model и input, что будущая генерация. Он не создаёт платный ролик. Сначала получите схему операции, затем составьте полное тело. После оценки сохраните его вместе с заказом: подмена длительности или звука между экраном цены и отправкой меняет смысл расчёта.

Значение null означает отсутствие подтверждённого числа, а не бесплатную работу. Не преобразуйте его в ноль для сортировки или кнопки «Создать за 0 ₽». Если цена требует дополнительной проверки, интерфейс должен это объяснить. Подтверждённое число тоже остаётся предварительным до окончания выполнения.

Оценка не является бессрочной бронью тарифа. Между чтением каталога и отправкой могут измениться доступность маршрута и условия расчёта. При создании конкретного задания Gate сохраняет своё решение. Поэтому в истории храните и показанную оценку, и окончательный ответ, не переписывая одно значение другим без подписи.

Считайте не только секунды, но и условия заказа

Цена видеомодели может зависеть от длительности, размера, звука и конкретной версии. Редактирование исходного ролика и создание нового видео часто имеют разные формулы. Для некоторых вариантов расчёт связан с кадрами или порогом длительности. Универсальная формула «пять секунд умножить на любое рекламное число» непригодна без проверки условий.

Общая маршрутизация сравнивает совместимые предложения одной модели при заданных настройках. Если один путь не поддерживает нужное поле, его нельзя считать дешёвым эквивалентом. Уменьшить разрешение или выключить звук можно как явное изменение заказа пользователя, после которого нужна новая оценка.

Для всех выбранных моделей цена проверяется через POST /v1/media/estimate с каноническим model и обязательной input.operation. Не подменяйте неподтверждённую оценку ручной котировкой. Клиент задаёт реальные материалы и параметры, а сервер рассчитывает поддерживаемые единицы тарифа. Неизвестная стоимость не становится нулевой и не доказывает преимущество перед другим маршрутом.

Что показывает один реальный тест Kling

В обычном чате Gate 20 октября 2026 года проверили замену персонажа в Kling O1: исходное видео длительностью пять секунд и опорное фото женщины в жёлтом платье. Для этого задания подтверждены $0,84 у fal и окончательное списание Gate 93,79 ₽. Это данные выполненного заказа, а не предварительной оценки.

Пример позволяет показать, как выглядит честный отчёт: модель, задача, длительность исходника, выбранный провайдер и два вида расхода. Он не устанавливает цену всех режимов Kling и не доказывает стоимость нового запроса с другими материалами. Генерация по тексту в Kling 3 Pro — уже другой сценарий.

Внутри вашего продукта рядом с результатом достаточно строки «Списано 93,79 ₽» и подробностей конкретного запроса. Текущий резерв следует показывать отдельно, если он ещё есть. Для клиента важна связь суммы с полученным файлом, а не длинная техническая формула, по которой невозможно найти его заказ.

Задайте бюджет заказа и ограничьте число попыток

Пользователю обычно нужен пригодный ролик, а не просто успешный HTTP-ответ. Поэтому бюджет работы складывается из числа реальных попыток и сопутствующих операций. Если после первой генерации нужны исправление, увеличение разрешения и добавление звука, это отдельные действия со своей ценой. Их следует считать и показывать заранее настолько, насколько позволяет контракт.

Начните с ограниченного плана: один короткий тест, проверка конкретных недостатков и одна осмысленная правка. Не повторяйте один и тот же запрос автоматически только потому, что картинка субъективно не понравилась. Сначала определите, что изменится в инструкции или модели и почему это должно исправить результат.

Для серии заказов учитывайте параллельные резервы. Приложение может проверять внутренний остаток бюджета до постановки очередной работы и ограничивать число одновременных запусков. Это ваш дополнительный контроль, а не обещание, что оценка API жёстко фиксирует верхнюю границу окончательного расхода.

{
  "order_id": "catalog-video-007",
  "internal_budget_rub": "150.00",
  "max_attempts": 2,
  "attempts_started": 0,
  "quoted_cost_rub": null,
  "actual_total_rub": "0.00"
}

Сверяйте списание по ID, а не по общему кошельку

При завершении получите актуальный GET задания и сохраните billing вместе с его ID. Если работают несколько генераций, общий баланс меняется сразу по нескольким причинам. Простое вычитание двух снимков баланса не доказывает цену выбранного видео и может ошибочно приписать ему расходы другого заказа.

Для внутреннего отчёта удобно иметь одну строку на попытку: собственный номер заказа, ID Gate, model, operation, provider, предварительную оценку, итоговую сумму и статус. Сумма по заказу складывается из его завершённых учтённых попыток. Повторный GET того же результата не должен создавать ещё одну строку расхода.

Деньги в собственной базе храните точными десятичными значениями либо целым числом копеек. Не складывайте рублёвые значения бесконтрольно в бинарном float и не округляйте каждую промежуточную операцию по-разному. Представление в интерфейсе с двумя знаками — последний шаг; исходные поля ответа полезно сохранить для проверки. Здесь речь о техническом учёте, а не о форме бухгалтерских документов.

Ошибка и повтор не должны превращаться в незаметный дубль

Сетевой тайм-аут после POST не сообщает, была ли работа принята. Сохранённые тело и Idempotency-Key позволяют восстановить тот же заказ. При известном ID используйте GET. Новый ключ при каждом сетевом повторе способен создать дополнительные оплачиваемые задачи, даже если человек нажал кнопку только один раз.

При awaiting_billing итоговый расход ещё подтверждается. Не списывайте резерв второй раз в своей внутренней таблице и не обещайте клиенту нулевую сумму. Дождитесь результата учёта. При failed или cancelled смотрите фактический billing и ошибку: общее утверждение «любая ошибка бесплатна» не заменяет разбор выполненных действий.

Отмена безопасно доступна не на любом этапе. Закрытие вкладки, остановка программы и локальный тайм-аут не отменяют работу провайдера. Если клиент передумал, обработайте допустимый cancel и сохраните его результат. Нельзя обещать, что уже переданная работа обязательно остановится без расхода.

Как показывать рублёвый учёт простым языком

До запуска покажите модель, существенные параметры и строку «Предварительно». Во время выполнения при необходимости добавьте «Зарезервировано» и статус ожидания. После завершения замените основную сумму на «Списано», сохранив оценку в подробностях. Так человеку понятно, почему доступный остаток менялся раньше появления результата.

Не придумывайте способы пополнения, реквизиты и платёжные гарантии из самого факта рублёвого billing. Текущие доступные действия пользователь смотрит в своём кабинете. Эта статья объясняет стоимость запросов; она не описывает неподтверждённые способы оплаты или юридические условия документов.

Для приёмки возьмите один конкретный заказ и проверьте совпадение ID, модели, провайдера, файла и суммы. Затем повторно получите тот же результат и убедитесь, что внутренний отчёт не вырос. Только после такой проверки включайте массовую генерацию: прозрачность начинается с одного воспроизводимого заказа.

Частые вопросы

Резерв и списание — это две оплаты?

Нет. reserved_rub показывает текущий резерв, а cost_rub — окончательную стоимость задания. В своём интерфейсе и отчёте их нельзя складывать как два независимых расхода.

Почему цена в рублях не равна простому пересчёту долларов из примера?

Подтверждённый долларовый расход поставщика и рублёвая стоимость клиента имеют разное назначение. Один исторический пример не задаёт постоянный курс или условия будущих запросов.

Можно ли считать null бесплатной генерацией?

Нет. null означает неподтверждённое значение. Нулевой расход должен быть подтверждён фактическим учётом, а не отсутствием оценки.

Как узнать, сколько стоил один ролик при параллельных задачах?

Получить его задание по ID и прочитать billing.cost_rub после подтверждения завершения. Изменение общего баланса не изолирует расходы конкретного заказа.

Источники

• Документация Celestria Gate
• Текущий общий каталог Gate
• Тарифы моделей fal
• Подтверждённые расходы fal: Billing Events