ProtoPays · API
кабинет

Webhook по выплатам

Для входящих платежей исходящий POST на callbackUri описан в разделе Webhook по платежу — там же пример реального JSON.

Для выплат (заявок на вывод) в текущей версии бэкенда нет отдельного исходящего HTTP webhook на произвольный URL мерчанта в том же стиле, что у внешних платежей. Заявки создаются и обрабатываются в продуктовом контуре кабинета; статусы хранятся в сущности вывода (см. ниже).

Ниже — что есть сейчас (статусы + polling), и отдельно — целевой черновик webhook для выплат: он не отправляется сервером, пока контракт не будет реализован и не попадёт в релиз-ноуты.

Статусы заявки на выплату (продукт)

Поле status в заявке — строка; возможные значения в текущей модели:

  • pending — заявка создана, ожидает обработки
  • processing — в обработке
  • approved — одобрена (этап процесса уточняйте у поддержки)
  • rejected — отклонена; смотрите reject_reason
  • completed — выплата завершена

Что доступно сейчас (вместо 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 может быть основным каналом.