Manejo de Errores¶

La aplicación de Pagos registra el estado de la transacción, que puede ser consultado posteriormente, de modo que la aplicación que se integra a través del SDK conoce el estado actual de la transacción y toma alguna acción, si es necesario.

Durante el flujo transaccional, pueden ocurrir fallas inesperadas, como el apagado del terminal o el cierre repentino de la aplicación debido a un error no controlado. Esto puede generar inconsistencias en la resolución de transacciones y, a veces, la aplicación que se integra a través del SDK debe tomar alguna medida para resolver esta inconsistencia.

El siguiente diagrama describe el flujo de estado de la aplicación y luego se presentan sugerencias sobre cómo corregir posibles errores.

En situaciones de falla inesperada (cierre de la aplicación por parte del operador del terminal, por ejemplo, o Fatal Exception), tanto en la aplicación de Pagos como en la aplicación que se integra vía SDK, recomendamos adoptar algunas estrategias para asegurar que las transacciones pendientes se resuelvan consistentemente:

1. Inmediatamente antes de llamar a startPaymentV2() (u otras funciones del SDK), la aplicación debe registrar de forma persistente la hora actual, appTransactionId, y los datos que tiene de la transacción a iniciar, así como un estado que indica que llamará a startPaymentV2();
2. Inmediatamente después de recibir el callback (onSuccess o onError), la aplicación debe registrar de forma persistente la hora actual, appTransactionId, los datos devueltos y un estado que indique que recibió el callback;
3. Si el flujo se interrumpe durante un pago, no se llamará a los métodos de callback (onSuccess o onError). a. La aplicación que llamó a startPaymentV2() puede identificar esto de dos maneras: i. Cuando la aplicación integrada inicia su ejecución, debe verificar si existe un registro de la llamada startPaymentV2(), sin que se registre el callback correspondiente. En este caso, hube una interrupción inesperada de la aplicación misma, y puede haber o no una interrupción inesperada de la aplicación de Pagos; ii. Al detectar mucho tiempo (por ejemplo, 10 minutos) después de la llamada startPaymentV2(), sin callback. En este caso, puede haber habido una interrupción inesperada de la aplicación de Pagos; b. En estos casos, para operaciones de pago con tarjeta, el comportamiento recomendado es el siguiente: i. Realice una consulta (vea Query), pasando el appTransactionId de la transacción; ii. Si paymentStatus es igual a CANCELLED, la aplicación de Pagos deshizo la transacción y ya está finalizada. La applicación integrada debe considerar que la transacción no se llevó a cabo. No se requiere ninguna acción para resolver pendientes con la aplicación de Pagos; iii. Si paymentStatus es igual a PENDING, la aplicación integrada debe llamar a cancelPayment(). Si la situación se identificó como se describe en “i”, es posible que la aplicación de Pagos no se hayan interrumpido y el pago aún se esté ejecutando, por lo que la aplicación integrada debe esperar al menos 10 minutos (desde el tiempo registrado en “1”) antes de llamar a cancelPayment(); iv. Si paymentStatus es igual a UNREACHABLE o PROCESSING, la transacción se interrumpió incluso antes de enviarse al autorizador. La applicación integrada debe considerar que la transacción no se llevó a cabo. No se requiere ninguna acción para resolver pendientes con la aplicación de Pagos; v. Si paymentStatus es igual a DENIED, la transacción fue denegada. La applicación integrada debe considerar que la transacción no se llevó a cabo. No se requiere ninguna acción para resolver pendientes con la aplicación de Pagos; c. En estos casos, para operaciones de pago con QR el comportamiento recomendado es el siguiente: i. La aplicación integrada debe llamar al método resolveQRCodePendencyV2(), pasando el appTransactionId de la intención; ii. Si el qrCodeIntentStatus es igual a PENDING o CREATED, la aplicación integrada debe aguardar un tiempo y seguir consultando (llamada a resolveQRCodePendencyV2()) hasta recibir un estado final; iii. Si el qrCodeIntentStatus es igual a CANCELLED, EXPIRED o DENIED, la aplicación integrada debe considerar que la transacción no se realizó. No se requiere ninguna acción para resolver pendientes con la aplicación de Pagos; iv. Si qrCodeIntentStatus es igual a APPROVED, la aplicación recibirá los datos de la transacción y deberá procesarlos. La aplicación integrada debe considerar que la transacción se realizó con éxito. No se requiere ninguna acción para resolver pendientes con la aplicación de Pagos.