En esta página
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.
- Valide firma y envelope antes de confiar en el evento.
- Guarde la aceptación con
event_idúnico, evitando carreras entre receptores. - Haga idempotente la continuidad de negocio.
- 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 ayuda a comprender escenarios; sus colas y almacenamiento necesitan pruebas propias.