Skip to main content
A FastPay envia notificações automáticas toda vez que o status de aprovação de uma subconta (submerchant) é alterado. Este webhook informa se a conta foi pré-aprovada, aprovada, devolvida para correção, rejeitada ou bloqueada.
Este webhook usa um canal completamente separado dos webhooks de cobrança e assinatura. Ele é entregue à URL configurada no campo merchant_status_postback_url das configurações do merchant — não aos webhook endpoints cadastrados no painel, e não ao postbackUrl de cobranças individuais.O payload também é diferente: sem envelope id / event / livemode, e campos em camelCase (payload slim).

Configuração

Defina a URL de recebimento no campo merchant_status_postback_url nas configurações do merchant. Cada submerchant pode ter a sua própria URL.

Status de aprovação

Os status abaixo são os que disparam este webhook:
O estado inicial pending (conta recém-criada) e a inativação (inactive) fazem parte do ciclo de vida da conta, mas não geram notificação por este canal — apenas as cinco transições acima disparam o webhook.

Ciclo de vida da aprovação

O fluxo comum de aprovação é: pending → pre_approved → active. Caso a equipe de compliance solicite ajustes, o status vai para correcting e retorna a pending quando o merchant reenviar os dados corrigidos. Uma conta pode ser rejected em qualquer ponto anterior à ativação. Contas active podem ser blocked temporariamente e desbloqueadas; ou inactive quando encerradas.

Corrigindo os dados (status correcting)

Ao solicitar correções para um submerchant, ele é notificado com o status correcting (o motivo vem no campo rejectionReason). A correção, porém, não é feita via API — só é possível corrigir os dados pelo painel, em:
FastConnect → Gestão de subcontas → Correções pendentes → Ações (⋯) → Corrigir Dados
Após o reenvio dos dados pelo painel, a conta retorna ao fluxo de análise (pending).

Payload

O payload é enviado via POST para a merchant_status_postback_url configurada. Não há envelope externo — o body é diretamente o objeto de notificação.

Payload com rejectionReason

O campo rejectionReason é incluído somente quando o status é rejected ou correcting.

Campos do payload

Exemplo de implementação

Sua aplicação deve responder com qualquer status inferior a 400 (2xx ou 3xx) — é assim que o gateway considera a entrega como bem-sucedida. Falhas de entrega podem ser retentadas. Implemente idempotência usando o par merchantId + date como chave de deduplicação, pois o mesmo evento pode ser entregue mais de uma vez.