Webhook по выплатам
Для входящих платежей исходящий POST на callbackUri описан в разделе Webhook по платежу — там же пример реального JSON.
Для выплат (заявок на вывод) в текущей версии бэкенда нет отдельного исходящего HTTP webhook на произвольный URL мерчанта в том же стиле, что у внешних платежей. Заявки создаются и обрабатываются в продуктовом контуре кабинета; статусы хранятся в сущности вывода (см. ниже).
Ниже — что есть сейчас (статусы + polling), и отдельно — целевой черновик webhook для выплат: он не отправляется сервером, пока контракт не будет реализован и не попадёт в релиз-ноуты.
Статусы заявки на выплату (продукт)
Поле status в заявке — строка; возможные значения в текущей модели:
pending— заявка создана, ожидает обработкиprocessing— в обработкеapproved— одобрена (этап процесса уточняйте у поддержки)rejected— отклонена; смотритеreject_reasoncompleted— выплата завершена
Что доступно сейчас (вместо webhook)
Список заявок с актуальными статусами возвращает API кабинета, например:
GET {BASE}/api/merchant-portal/merchant-withdrawals/summary
Элементы data.applications[] содержат поля в духе:
{
"id": 2001,
"payout_address_id": 10,
"amount": "5000.00000000",
"fee_amount": "50.00000000",
"net_amount": "4950.00000000",
"status": "processing",
"reject_reason": null,
"created_at": "2026-04-20T12:00:00+00:00"
}Точный набор полей — как в ответе живого API; используйте его как контракт polling до появления push-webhook.
Целевой webhook (черновик, не реализован)
Когда появится исходящий webhook по выплатам, разумно ожидать явный тип события и стабильный eventId для дедупликации, по аналогии с типичными платёжными API. Ниже — иллюстрация, а не текущий ответ сервера:
{
"type": "withdrawal.status.updated",
"eventId": "evt_01h2…",
"createdAt": "2026-04-20T12:00:00.000000Z",
"data": {
"id": 2001,
"status": "processing",
"amount": "5000.00000000",
"currency": "USDT",
"net_amount": "4950.00000000",
"reject_reason": null
}
}Рекомендации интегратору
- До появления webhook: периодически опрашивайте summary и сравнивайте
id+status. - Финальные статусы для бизнес-логики: как минимум
completedиrejected; промежуточные —pending,processing,approved(уточняйте процесс у поддержки). - После появления webhook: обрабатывайте повторы и отсутствие порядка так же, как для платежей — см. общие правила Webhooks.
В отличие от платежей: выплату инициируете вы; webhook (когда будет) будет подтверждать итог операции; до тех пор polling может быть основным каналом.