Skip to main content
Депозит несёт два уровня статуса:
  • бизнес-статус — поле status в объекте депозита (например check, process, paid);
  • on-chain статус — поле transaction.networkStatus, которое появляется, когда замечена входящая транзакция.
Бизнес-статус отвечает за вашу логику (зачислить клиенту, запросить доплату, вернуть средства), а on-chain статус показывает, что именно сейчас происходит с транзакцией в сети.

​
Бизнес-статусы (status)

​
Допуск недоплаты и доплата (1.4.0)

  • Допуск (accuracyPaymentPercent депозита → настройка сайта → глобальная): если получено не меньше expectedAmount × (1 − N/100), депозит финализируется как paid, а не wrong_amount.
  • Доплата (allowTopUp): при недоплате депозит получает wrong_amount, но адрес остаётся под мониторингом до конца окна. Каждая новая транзакция на адрес присылает webhook deposit.topup_detected (opt-in), после подтверждения суммы складываются и приходит повторный deposit.finalized с итоговым статусом paid / paid_over. Если окно истекло, а сумма так и не набралась — приходит deposit.underpaid с isFinal=true, средства сметаются по правилам недоплаты.

​
Поток статусов

​
Что означает каждый переход

1

check → process

Платформа заметила первую входящую транзакцию на адрес (и memo) депозита. В этот момент появляется объект transaction. Срабатывает webhook deposit.tx_detected.
2

process → confirm_check

Транзакция набрала требуемое число подтверждений (transaction.confirmations достигло transaction.requiredConfirmations). Платформа выполняет финальную сверку фактической суммы с ожидаемой. Промежуточный статус, webhook не шлётся.
3

confirm_check → paid | paid_over | wrong_amount

Депозит финализирован. Исход зависит от суммы: paid — получено ровно expectedAmount; paid_over — получено больше; wrong_amount — получено меньше. Срабатывает webhook deposit.finalized.
4

check → expired

Истекло окно мониторинга (expiresAt), а оплата так и не пришла. Срабатывает webhook deposit.failed.
5

check → cancel | fail | system_fail

Депозит отменён (cancel) либо завершился ошибкой обработки (fail) или внутренней ошибкой платформы (system_fail). Для fail / system_fail срабатывает webhook deposit.failed.
6

paid* → refund_process → refund_paid | refund_fail

Запущен возврат средств отправителю. По завершении статус становится refund_paid (возврат отправлен, срабатывает webhook deposit.refunded) или refund_fail (возврат не удался, opt-in webhook deposit.refund_failed). Возврат запускается через POST /v1/public/deposits/{uuid}/refund или оператором в админке — см. Обзор депозитов.
paid, paid_over и wrong_amount — все три считаются «оплаченными» исходами. Сравните transaction.receivedAmount с expectedAmount, чтобы выбрать действие: зачислить клиенту, вернуть разницу при переплате или запросить доплату при недоплате. Если expectedAmount равен "0", принимается любая сумма и исход всегда paid.

​
On-chain статусы (transaction.networkStatus)

Появляются внутри объекта transaction, как только замечена входящая tx.
Для сетей с детерминированной финальностью (например TON) транзакция может прийти сразу со статусом confirmed и confirmations равным requiredConfirmations — депозит финализируется практически мгновенно. Для EVM-подобных сетей confirmations растёт постепенно от 0 до требуемого порога.

​
Когда приходят webhooks

См. также Webhooks, Обзор депозитов.