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
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.Cobrança com split
Cobrança criada emPOST /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%.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
Osimulate-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.
Tratando
Pagou com cartão?
O evento é outro e a forma do corpo muda. Vale a leitura antes de escrever um handler
genérico.

