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 campomerchant_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
pending).
Payload
O payload é enviado viaPOST 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.