Skip to main content
Eventos relacionados ao ciclo de vida das cobranças (charges) na FastPay.

Eventos Disponíveis

Status possíveis (status)

Envelope padrão (charge.created / pending / paid / refunded)

Os eventos charge.created, charge.pending, charge.paid e charge.refunded usam o envelope padrão com campos em snake_case. São entregues via fila (BullMQ) a todos os webhook endpoints configurados do merchant, e adicionalmente ao postback_url da cobrança quando presente.

Campos do objeto data (snake_case)

Objeto customer

Objeto payment_method — cartão de crédito

Objeto payment_method — PIX / outros meios

Para cobranças PIX o objeto contém apenas { "type": "pix" }. Dados como QR Code e expiração não são incluídos no payload do webhook (estão disponíveis na resposta da API de criação).

Objeto shipping_address

Objeto tracking_info

trackingStatus pode ser awaiting_shipment, on_the_way ou delivered.

Payloads por evento

charge.created

Enviado imediatamente após a criação de uma nova cobrança.

charge.pending

Enviado quando a cobrança está aguardando pagamento (ex: PIX gerado).

charge.paid

Enviado quando o pagamento é confirmado com sucesso.

charge.refunded

Enviado após a conclusão bem-sucedida de um estorno.

charge.updated — canal legado de postback

charge.updated é diferente dos demais eventos de cobrança.Ele é entregue exclusivamente ao postbackUrl informado na criação da cobrança — nunca aos webhook endpoints cadastrados no painel. É um canal legado (postback direto) com um envelope e convenção de nomenclatura diferentes.Situações que disparam o charge.updated:
  • Transação bloqueada pelo fluxo de bloqueio (ver Bloqueio de Transação)
  • Falha de autenticação 3DS
  • Atualização de status pelo PSP (ex: recusa, falha)

Envelope do charge.updated (camelCase)

O envelope não contém id nem livemode. O objeto data é o charge completo convertido para camelCase:
O campo isBlocked estará presente no payload quando a cobrança tiver sido bloqueada. Consulte a documentação de Bloqueio de Transação para entender o fluxo completo.

Retentativas do postback legado

O postback legado tenta o envio até 3 vezes em caso de falha, com backoff exponencial: ≈1 s, ≈2 s, ≈4 s entre as tentativas.

Exemplo de Implementação

Fluxo Típico (PIX)