Skip to main content
Movimentos de subconta avisam as URLs da conta, configuradas em Dashboard → Equipe & API → Developer API. Vale para movimentos feitos pela API e pelo painel: uma transferência manual do dono da loja chega no seu sistema do mesmo jeito. A venda não ganha evento próprio aqui: ela já avisa pelo charge.paid/payment.paid, que carrega o subaccountId.
Sandbox não emite eventos de subconta. Evento de teste caindo na URL de produção confundiria mais do que ajudaria: valide o fluxo com o extrato (GET /v1/subaccounts/{id}/transactions), que funciona igual nos dois ambientes.

Campos

string
required
subaccount.transfer, subaccount.payout ou subaccount.payout_reversal.
string
required
A subconta movimentada.
integer
required
Valor do movimento em centavos, sempre positivo. O sentido vem de direction (transferência) ou do próprio tipo de evento (saque debita, estorno credita).
string
Só em subaccount.transfer. É o mesmo refId do extrato (tr_ ou idem_).
string
Só em subaccount.transfer: to_master ou to_subaccount.
integer
Só em subaccount.transfer: saldo da subconta logo após o movimento.
string
Só em subaccount.transfer: api ou panel. É como você descobre que o dono da loja moveu saldo pelo painel.
string
Nos eventos de saque: o código do saque, o mesmo que aparece em GET /v1/payouts e no extrato da subconta.
string
Só em subaccount.payout: completed (banco confirmou) ou processing (o PIX saiu ou pode ter saído; a confirmação vem depois). Nos dois casos o débito no ledger FICA: não trate processing como falha.
string
Só em subaccount.payout_reversal: motivo interno do estorno.
subaccount.payout com status: "processing" seguido de subaccount.payout_reversal com o mesmo code é o ciclo completo de um saque que o banco acabou negando: o débito aconteceu, depois voltou. Espelhe os dois no seu ledger em vez de ignorar o primeiro.
As garantias são as mesmas dos outros eventos: assinatura HMAC em X-Webhook-Signature, idempotência em X-Webhook-Id (formato evento:id) e reentrega com backoff.