Skip to main content
Quando o PIX é confirmado, a gente faz POST na callbackUrl informada na criação. Se você não mandou nenhuma, o evento vai pras URLs da conta. O nome do evento depende do recurso: O corpo é o mesmo nos dois eventos.

Campos

string
required
payment.paid ou charge.paid.
string
required
Identificador do pagamento. É a chave para reconciliar do seu lado.
number
required
Valor em centavos. Confira contra o esperado antes de entregar.
string
required
Sempre paid neste evento.
string
required
Data e hora da confirmação, em ISO 8601.
object
name, email e externalId, como você informou na criação.
string
A string JSON que você mandou, devolvida sem alteração.
number
O mesmo valor em reais, decimal. Conveniência para exibição.
string
Descrição informada na criação.
string
O que foi entregue automaticamente, quando o produto tem entrega automática. Veja Entrega.
string
Presente quando a cobrança foi criada com subconta. O ledger dela já foi creditado quando este evento chega.
boolean
true quando o evento veio de um endpoint de simulação.

Dados do pagador

Vêm do banco, não de você. Chegam nos dois eventos, e só quando o banco de origem informa: PIX pago por certas instituições não traz o documento, e alguns não trazem nem o nome.
string
Nome de quem pagou, como consta no banco.
string
CPF ou CNPJ de quem pagou, completo e só com os dígitos: 12345678909. Sem pontuação, para bater direto com o que você guarda do seu lado. Use para conciliar com o extrato bancário e para responder disputa.
string
Banco de origem, no formato código - nome.
string
Identificador end-to-end da transação no Bacen. Serve para conciliação bancária e para responder disputa.
string
txid da transação PIX.
Campo opcional é omitido quando não se aplica, e não enviado como null.
cpf é dado pessoal de quem pagou, e chega inteiro. Receba em HTTPS, guarde só o tempo que a sua operação precisa e não exponha em log de aplicação nem em tela de terceiro. A chave PIX, o telefone e o endereço do pagador não saem em webhook nenhum.

Cobrança com split

Cobrança criada em POST /v1/split-charges avisa pelo mesmo evento, charge.paid. É o mesmo fato, um PIX foi pago, e o handler que você já tem continua valendo. O que muda vem no corpo: o paymentId começa com psplit_ e chegam três campos a mais.
number
A taxa retida, em centavos. Sai da sua fatia, não da dos beneficiários. A conta inteira está em Splits.
number
amountCents menos gatewayFeeCents. É a soma do que foi creditado em splits[].
array
A repartição de fato, já creditada. Cada item traz recipientEmail (mascarado), percentage, amountCents e isOwner. Você entra na lista com isOwner: true e fica com o resto: a soma dos beneficiários é sempre menor que 100%.
Use o amountCents de cada item, não percentage × amountCents recalculado por você. O arredondamento já foi decidido no crédito, e refazer a conta gera divergência de centavo no seu relatório, especialmente na sua própria fatia, de onde a taxa saiu.
Se o seu handler precisa distinguir os dois casos, use o prefixo do paymentId (psplit_) ou a presença de splits. O campo event é o mesmo de propósito: é o mesmo fato do domínio, e o handler que você já tem continua valendo.Split não aceita metadata, então esse campo não aparece neste corpo.

Em sandbox

O simulate-paid sempre envia event: "payment.paid", inclusive ao simular uma cobrança psc_. O corpo é enxuto: event, paymentId, amountCents, status, paidAt, customer, metadata e sandbox: true.
Se o seu handler faz if (evento.event === "charge.paid") para cobranças, ele não vai disparar em sandbox. Trate os dois nomes no mesmo caminho.

Tratando

Pagou com cartão?

O evento é outro e a forma do corpo muda. Vale a leitura antes de escrever um handler genérico.