Nesta página
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.
- Valide assinatura e envelope antes de confiar no evento.
- Persista a aceitação com
event_idúnico, evitando corrida entre receptores. - Processe a continuidade de negócio de forma idempotente.
- 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 ajuda a compreender cenários; sua infraestrutura de filas e armazenamento precisa de testes próprios.