## Configure um receptor no seu backend

Informe `callback_url` na criação para definir o destino daquela transação. Sem esse campo, utiliza-se o webhook configurado no Tenant. O receptor deve aceitar o formato documentado e preservar os bytes recebidos antes de interpretar JSON.

O payload inclui `api_version`, `event_id`, `event_type`, `created_at` e `transaction`. Os headers `X-Face-Auth-Event-Id`, `X-Face-Auth-Event-Type`, `X-Face-Auth-Timestamp` e `X-Face-Auth-Signature` permitem identificar e validar a entrega. Veja a [referência completa](/pt-BR/desenvolvedores/kyc/referencia) para os enums de evento.

## Uma entrega pode se repetir

Deduplicar por `transaction_id` descartaria eventos diferentes da mesma jornada. Use `event_id` com armazenamento durável e protegido contra concorrência. Verifique a assinatura antes de confiar no evento e confirme a consistência dos identificadores de evento do envelope e do header.

O receptor pode guardar o evento validado em uma fila durável e processá-lo separadamente. Responda com sucesso apenas depois de aceitar o trabalho de forma persistente; uma confirmação não deve esconder uma perda de dados.

## Não dependa da ordem de chegada

Uma repetição ou atraso pode fazer um evento antigo chegar depois de outro mais recente. Consulte o GET da transação para reconciliar seu estado antes de liberar efeitos de negócio. Faça esses efeitos também idempotentes, para que uma nova tentativa não gere duas liberações.

Continue em [validação HMAC](/pt-BR/desenvolvedores/kyc/validar-assinatura-hmac) e [reentrega e reconciliação](/pt-BR/desenvolvedores/kyc/reentrega-e-reconciliacao). Uma integração pronta trata também assinatura inválida, indisponibilidade temporária e eventos recebidos fora de ordem.