## Entrega y procesamiento son problemas diferentes

Una entrega puede fallar, repetirse o llegar tarde. El contrato incluye estados como `retry_pending` y `failed`; no suponga intervalos fijos ni entrega exactamente una vez. Confirme las condiciones operativas de su integración.

1. Valide firma y envelope antes de confiar en el evento.
2. Guarde la aceptación con `event_id` único, evitando carreras entre receptores.
3. Haga idempotente la continuidad de negocio.
4. Consulte la transacción mediante GET para conciliar el estado actual.

Si confirma antes de persistir y luego falla, puede perderse el trabajo. Si persiste y se pierde la confirmación, puede repetirse la entrega. Su diseño debe tratar ambos casos.

## El orden de llegada no define el estado

Un evento `created` retrasado no debe sustituir un estado final ya conocido. El identificador de transacción localiza el recorrido; `event_id` identifica cada evento. Consulte `GET /v1/face-auth/transactions/{transaction_id}` con la clave del Tenant y entorno correctos.

## Prepare la recuperación operativa

Registre identificador, tipo de evento, resultado y fallo sanitizado. No copie cuerpos personales ni credenciales en logs abiertos. Defina cómo su equipo encuentra pendientes, realiza una nueva consulta y evita repetir liberaciones, cobros u otros efectos.

Pruebe duplicados, dos eventos fuera de orden, un fallo antes de persistir y otro después. El [simulador](/es/desarrolladores/kyc/simulador) ayuda a comprender escenarios; sus colas y almacenamiento necesitan pruebas propias.