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)
  • Alerta de pré-chargeback (status: pre_chargeback) — ver seção Pré-chargeback abaixo
  • 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.

Pré-chargeback (alerta)

Quando a FastPay recebe um alerta de pré-chargeback (programas tipo Ethoca/Verifi — o portador contestou a compra junto ao emissor antes de o chargeback ser formalizado), a cobrança passa para o status pre_chargeback. A transição é notificada via postback charge.updatedpostbackUrl da cobrança) — não há evento dedicado (charge.pre_chargeback não existe) e os webhook endpoints cadastrados no painel não recebem esse evento. O objeto data inclui dois campos específicos do alerta: Com ou sem estorno. Ao registrar o alerta, a FastPay usa uma flag refund (default true):
  • Com estorno (refund: true, o caso comum): o valor é devolvido imediatamente ao portador para evitar que o alerta evolua para chargeback formal (e suas taxas/penalidades). O pedido deve ser tratado como estornado.
  • Sem estorno (refund: false): decisão operacional de contestar/não devolver (ex.: mercadoria já entregue com prova de entrega). A disputa segue aberta; o pedido não deve ser marcado como estornado.
Em ambos os casos o status vai para pre_chargeback — o estorno é uma dimensão ortogonal ao status, lida via chargebackAlertRefunded.
Tratamento recomendado. Ao receber charge.updated com status = "pre_chargeback":
  • chargebackAlertRefunded = true → marque o pedido como estornado (valor já devolvido ao portador);
  • chargebackAlertRefunded = false → marque como em disputa, sem estorno.

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)