Skip to main content

Visão Geral

Webhooks permitem que você receba notificações HTTP automáticas quando eventos importantes acontecem na sua conta, como pagamentos confirmados, reembolsos processados ou saques concluídos.

Eventos Disponíveis

Estrutura do Payload

Todos os webhooks seguem a mesma estrutura base:

Subcontas

Quando o evento pertence a uma subconta, o campo subAccount traz o reference dela:
Se a subconta não tiver um endpoint de webhook próprio cadastrado, os eventos dela são entregues nos endpoints da conta principal. É por isso que o subAccount é essencial: é ele que diz de qual carteira é o evento.Sempre use esse campo para creditar o evento na carteira certa — nunca assuma que todo evento recebido no endpoint da conta principal pertence à conta principal.

Headers Enviados

Cada requisição de webhook inclui os seguintes headers:

Validando a Assinatura

Cada webhook é assinado com HMAC-SHA256 usando o secret do seu endpoint (exibido uma única vez na criação). Siga estes passos para validar:
  1. Calcule o HMAC-SHA256 do body cru da requisição usando o seu secret como chave
  2. Prefixe o resultado em hex com sha256=
  3. Compare com o header X-Pague-Signature usando comparação em tempo constante
Node.js (crypto)
Sempre use comparação em tempo constante (timingSafeEqual) para evitar ataques de timing. Nunca compare assinaturas com ===.

Exemplos de Payload

payment_completed

Enviado quando um pagamento PIX é confirmado.
O split do webhook é o que foi efetivamente distribuído, não o que você pediu na criação da cobrança. Os dois divergem quando a taxa da conta muda entre a cobrança e o pagamento: o líquido encolhe e as pernas são reduzidas na ordem em que foram enviadas, em vez de a liquidação falhar.Para conciliar com o extrato da carteira, use sempre o valor que vem no webhook — nunca o que você mandou no request. O campo só aparece quando houve rateio; cobrança sem split não ganha a chave.

payment_expired

Enviado quando um pagamento PIX expira sem confirmação.

refund_completed

Enviado quando um reembolso é processado.
Convenção do netAmount em refund: representa o que o destinatário do evento (o cliente final) efetivamente recebe — ou seja, o valor cheio do reembolso. A taxa de reembolso é debitada separadamente do saldo do lojista. O custo total do refund para o lojista é amount + feeAmount.

withdrawal_completed

Enviado quando um saque é processado com sucesso.

withdrawal_failed

Enviado quando um saque é rejeitado ou falha.

withdrawal_reversed

Enviado quando um saque é estornado pelo PSP.

balance_block_created

Enviado quando um bloqueio de saldo é criado (MED, judicial ou administrativo).

balance_block_approved

Enviado quando um bloqueio de saldo é aprovado e o valor é devolvido ao pagador original.

balance_block_rejected

Enviado quando um bloqueio de saldo é rejeitado e o valor retorna ao saldo disponível do lojista.

Boas Práticas

Retorne um status 200 OK o mais rápido possível. Processe o webhook de forma assíncrona se necessário.
Use o eventId para evitar processar o mesmo evento duas vezes. Webhooks podem ser reenviados em caso de falha.
Configure seu endpoint apenas com HTTPS para garantir a segurança dos dados.

Retentativas

Se o seu endpoint não responder com status 2xx, tentaremos reenviar o webhook:
  • 5 tentativas com backoff exponencial
  • Intervalo inicial: 2 segundos
  • Intervalo máximo: ~30 segundos entre tentativas
Após 5 tentativas sem sucesso, o webhook é marcado como falho.