Создание счёта (
POST) подписывается HMAC, как все write-операции — см. Аутентификация.
А вот публичные GET-эндпоинты страницы оплаты не требуют подписи: токен в URL и есть
аутентификация (страницу открывает конечный клиент, а не ваш сервер). Ответы — всегда в конверте
{ "ok": true, "data": … }.Эндпоинты
Как это работает
1
CMS создаёт счёт
POST /v1/public/invoices с суммой и активом. В ответ — token и payPath.2
Редирект клиента на оплату
Соберите абсолютную ссылку
https://<домен-вашего-кошелька>{payPath} и откройте её клиенту.
Страница сама покажет адрес, QR, сумму и обратный отсчёт.3
Клиент платит, платформа отслеживает
Приход средств отслеживается существующим мониторингом депозитов ровно до конца срока счёта.
4
Вы узнаёте об оплате
Либо вебхуком
deposit.finalized на ваш callback_url (рекомендуется), либо поллингом статуса
по токену. См. Отслеживание оплаты.Создать счёт
POST /v1/public/invoices
Создаёт счёт для вызывающего сайта и возвращает данные, нужные для редиректа клиента на оплату.
Тело запроса
string
required
Код актива:
USDT_TRC20, TRX, GRAM, USDT_TON, … (до 32 символов). Список доступных активов —
GET /v1/public/assets (см. Валюты).string
required
Сумма к оплате — десятичная строка, строго больше нуля (например
"49.90"). Никогда не число:
деньги передаются строками, чтобы избежать потери точности. "0" и отрицательные значения отвергаются
с INVALID_AMOUNT.integer
default:"60"
Срок действия счёта в минутах. Диапазон 5…43200 (до 30 дней), по умолчанию 60. Срок задаёт
окно мониторинга: платформа следит за адресом ровно до
expiresAt. После истечения счёт переходит в
expired, но публичная ссылка живёт ещё 1 день (grace), чтобы клиент увидел финальный статус —
затем ссылка отключается (410 Gone).string
Ваш
order_id. Если не передан — платформа сгенерирует уникальный. Уникален в рамках сайта; повтор
того же order_id идемпотентно вернёт тот же счёт (второй не создаётся). До 255 символов.
См. Идемпотентность.string
Заголовок/назначение платежа — показывается клиенту на странице оплаты (до 200 символов).
string
Описание — показывается клиенту на странице оплаты (до 1000 символов).
string
UUID системного кошелька-получателя свипа после оплаты (override маршрутизации). Если не указан —
применяется дефолтная маршрутизация (обычно hot). Кошелёк должен быть
active, той же сети, что и
актив, и иметь роль hot, admin, payout или cold (роль energy запрещена).Поля ответа
string
Внутренний UUID счёта (для корреляции).
string
Ваш
order_id (или сгенерированный, если не передавали).string
Публичный токен ссылки (64 hex-символа, неугадываемый). Используется в публичных
GET-эндпоинтах и в payPath.string
Относительный путь страницы оплаты. Абсолютная ссылка:
https://<домен-вашего-кошелька>{payPath}.string
Код актива счёта.
string
Сеть актива (
TRON, TON, …).string
Адрес для оплаты (тот же, что покажет страница).
string | null
Memo для memo-сетей (TON). Для остальных сетей —
null.string
Сумма к оплате (десятичная строка).
string
Срок действия счёта (ISO-8601). После него счёт
expired.string
Состояние счёта на момент создания — обычно
pending. Полный набор — Состояния счёта.Отслеживание оплаты
Есть два способа узнать об оплате. Их можно комбинировать.1
Вебхук (рекомендуется)
Поскольку счёт — это депозит, при финализации оплаты платформа отправит на
callback_url вашего
сайта событие deposit.finalized с вашим order_id. Отдельной подписки не нужно — достаточно
настроенного callback_url. См. Webhooks.2
Поллинг по токену
Опрашивайте
GET /v1/public/invoices/{token}/status (облегчённый ответ) каждые ~3 секунды для
live-обновления экрана оплаты. Полное состояние страницы — GET /v1/public/invoices/{token}.
Оба эндпоинта публичные (подпись не нужна, аутентификация по токену).Получить данные платёжной страницы
GET /v1/public/invoices/{token}
Возвращает всё, что нужно для отрисовки страницы оплаты: адрес, актив, сумму, USD-эквивалент (best-effort),
срок (для обратного отсчёта), текущее состояние, подтверждения, ссылки на explorer и брендинг оператора.
Поля ответа
string
Публичный токен счёта.
string | null
Заголовок/назначение платежа.
string | null
Описание счёта.
string
Код актива (
USDT_TRC20).string
Короткий символ для UI (
USDT).string
Человекочитаемое имя актива.
string
Сеть актива.
string
Адрес для оплаты (показывается + QR).
string | null
Memo для memo-сетей (обязателен при оплате), иначе
null.string
Сумма к оплате.
string | null
USD-эквивалент суммы (best-effort, по oracle).
null, если цены нет.number
Число знаков после запятой для актива.
string
Срок оплаты (для обратного отсчёта).
string
Когда счёт создан.
string
Состояние оплаты для UI. См. Состояния счёта.
string
Сырой статус депозита (для отладки/детализации). По умолчанию
check.string | null
Фактически полученная сумма (
null, пока нет tx).number | null
Текущее число подтверждений (
null, пока нет tx).number
Сколько подтверждений нужно для финализации.
string | null
Хеш входящей транзакции.
string | null
Ссылка на tx в explorer.
string | null
Ссылка на адрес в explorer.
string | null
Когда оплата финализирована (
null, пока не оплачено).object
Брендинг оператора для white-label страницы.
Опрашивать статус оплаты
GET /v1/public/invoices/{token}/status
Облегчённый ответ для частого поллинга страницы (раз в ~3 секунды). Содержит только поля, нужные для
live-обновления, без брендинга и метаданных актива.
Поля ответа
string
Состояние оплаты для UI. См. Состояния счёта.
string
Сырой статус депозита.
string | null
Фактически полученная сумма.
number | null
Текущее число подтверждений.
number
Сколько нужно для финализации.
string | null
Хеш входящей транзакции.
string | null
Ссылка на tx в explorer.
string | null
Когда оплата финализирована.
string
Срок оплаты (для обратного отсчёта).
Состояния счёта
Полеstate (в обоих GET-ответах) и status (при создании) — это упрощённое для UI представление
статуса депозита. Возможные значения:
Счёт делегирует приём средств депозиту, поэтому переплата/недоплата обрабатываются ровно как у
депозита. Логика подтверждений и финализации — та же; см. Статусы депозита.
Поле
paymentStatus отдаёт сырой статус депозита, если нужна более точная детализация.Краевые случаи и ошибки
Полный формат ошибки и справочник кодов — Ошибки.
Частые вопросы
Чем счёт отличается от депозита?
Чем счёт отличается от депозита?
Ничем по сути приёма средств — счёт это депозит плюс публичная hosted-страница оплаты и срок жизни
ссылки. Если вам не нужна готовая страница (вы рисуете платёжный экран сами), используйте
Депозиты напрямую. Если хотите редиректить клиента на готовую страницу —
используйте счета.
Нужно ли подписывать запросы к странице оплаты?
Нужно ли подписывать запросы к странице оплаты?
Нет.
POST на создание счёта подписывается HMAC (это делает ваш сервер). А GET /{token} и
GET /{token}/status — публичные: их вызывает браузер клиента, и аутентификацией служит сам
неугадываемый токен в URL. Не встраивайте api_secret в клиентский код.Как клиент попадает на оплату?
Как клиент попадает на оплату?
Из ответа на создание возьмите
payPath и соберите абсолютную ссылку
https://<домен-вашего-кошелька>{payPath}. Откройте её клиенту (редирект или новая вкладка).
Альтернативно постройте ссылку из token: …/invoice/{token}.Как долго работает ссылка?
Как долго работает ссылка?
Платформа мониторит адрес до
expiresAt (задаётся ttlMinutes, по умолчанию 60 минут). После
истечения счёт переходит в expired, но публичная ссылка остаётся доступной ещё 1 день, чтобы
клиент увидел финальный статус. Затем ссылка отключается и возвращает 410 Gone. Оператор также
может отключить ссылку вручную из админки в любой момент.Лучше вебхук или поллинг?
Лучше вебхук или поллинг?
Вебхук
deposit.finalized — основной и надёжный способ обновить вашу заявку на бэкенде (см.
Webhooks). Поллинг GET /{token}/status — для живого обновления экрана у
клиента в браузере (раз в ~3 секунды). Обычно используют оба: вебхук на сервере, поллинг на странице.Что с переплатой и недоплатой?
Что с переплатой и недоплатой?
Обрабатываются как у депозита: точная сумма →
paid, больше → overpaid, меньше → underpaid.
Сравнивайте receivedAmount и expectedAmount. Окно мониторинга равно сроку счёта — после
expiresAt адрес больше не отслеживается.Можно ли направить средства на конкретный кошелёк?
Можно ли направить средства на конкретный кошелёк?
Да. Передайте
sweepDestinationWalletUuid при создании — после оплаты свип уйдёт на этот системный
кошелёк (override маршрутизации). Кошелёк должен быть active, той же сети, что и актив, и иметь роль
hot, admin, payout или cold. Без этого поля применяется дефолтная маршрутизация.