## Entrega e processamento são problemas diferentes

Uma entrega pode falhar, repetir ou chegar atrasada. O contrato prevê estados de entrega como `retry_pending` e `failed`; não presuma um intervalo fixo de repetição ou entrega exatamente uma vez. Consulte as condições operacionais da sua integração.

1. Valide assinatura e envelope antes de confiar no evento.
2. Persista a aceitação com `event_id` único, evitando corrida entre receptores.
3. Processe a continuidade de negócio de forma idempotente.
4. Consulte o GET da transação para reconciliar o estado atual.

Se seu receptor confirmar antes de persistir e cair em seguida, o trabalho pode se perder. Se persistir e a resposta de confirmação se perder, a entrega pode se repetir. Seu desenho precisa lidar com os dois casos.

## Não use a ordem de chegada como verdade

Um evento `created` atrasado não deve substituir um estado final já conhecido. O identificador da transação serve para localizar a jornada; `event_id` identifica cada evento. Consulte `GET /v1/face-auth/transactions/{transaction_id}` com a chave do Tenant e ambiente corretos.

## Prepare recuperação operacional

Registre identificador, tipo do evento, resultado do processamento e falha sanitizada. Não copie corpos pessoais ou credenciais para logs abertos. Defina como sua equipe identifica pendências, executa nova consulta e evita repetir liberações, cobranças ou outras ações.

Teste um evento duplicado, dois eventos fora de ordem, uma falha antes da persistência e outra depois dela. O [simulador](/pt-BR/desenvolvedores/kyc/simulador) ajuda a compreender cenários; sua infraestrutura de filas e armazenamento precisa de testes próprios.