Cada sesión de App2App comienza con un inicio de sesión, y una sesión puede invalidarse por eventos fuera de tu control. Gestionar correctamente este ciclo de vida es la diferencia entre una integración que "funciona en mi máquina" y una que sobrevive al uso real del terminal — reinicios, actualizaciones y conexiones caídas. Esta guía explica cuándo existe una sesión, qué la invalida y cómo mantenerla activa.
Por qué el inicio de sesión es lo primero
Hasta que recibas una respuesta de inicio de sesión exitosa, la aplicación de pago trata cada solicitud que envías como no autorizada y la ignora silenciosamente. No hay error, ni excepción — tu solicitud de pago, estado o administración simplemente no produce respuesta. Un desarrollador que omite el inicio de sesión pasa horas preguntándose por qué no recibe nada.
Así que la regla es absoluta: una RetailerLoginResponse exitosa abre la sesión, y nada más funciona hasta que esto sucede.
viewModelScope.launch {
clientSDK.sendLoginRequest()
}
// Espera la SuccessRetailerLoginResponse en tu interceptor antes de
// enviar cualquier otra solicitud.
Qué invalida una sesión
Una sesión no es permanente. Cualquiera de estos eventos la termina, y tu próxima solicitud será ignorada hasta que inicies sesión nuevamente:
- La aplicación de pago se actualiza — una nueva versión de la aplicación de pago reinicia la sesión.
- La aplicación de pago se reinicia — por cualquier motivo, incluyendo un reinicio del dispositivo.
- Tu aplicación se reinicia — si tu proceso es terminado y recreado, se pierde la sesión.
- Se pierde la conexión entre las dos aplicaciones — la vinculación IPC se cayó.
-
Enviaste una solicitud de cierre de sesión — un
sendLogoutRequest()explícito termina la sesión deliberadamente.
La idea unificadora: una sesión une dos instancias específicas de aplicaciones en ejecución. Si alguna de las aplicaciones se reinicia, o se rompe el enlace entre ellas, la sesión que compartían ya no existe — aunque tu código aún tenga un objeto SDK que parece listo para usar.
Cuándo y cómo volver a iniciar sesión
No puedes predecir confiablemente estos eventos, así que no lo intentes. En cambio, estructura tu aplicación para que volver a iniciar sesión sea barato y automático:
Inicia sesión al arrancar. Dispara sendLoginRequest() cuando tu aplicación se inicie. Esto cubre el caso de "tu aplicación se reinició" sin costo adicional.
Vuelve a iniciar sesión cuando las respuestas dejen de llegar. Si envías una solicitud y nunca llega la respuesta esperada (puedes detectarlo con un tiempo de espera, por ejemplo, en modo bloqueante), trátalo como una posible sesión perdida y vuelve a iniciar sesión antes de reintentar. Una respuesta de inicio de sesión exitosa confirma que la sesión está activa nuevamente.
Volver a iniciar sesión es idempotente en la práctica. Llamar a iniciar sesión cuando una sesión ya está abierta es seguro — simplemente obtienes otra respuesta exitosa de inicio de sesión. Así que "inicia sesión siempre que tengas dudas" es una estrategia válida; no dañarás nada iniciando sesión más a menudo de lo estrictamente necesario.
Un patrón común y robusto: envuelve tu lógica de envío para que si una operación supera el tiempo de espera, automáticamente envíes un inicio de sesión, esperes el éxito y luego reintentes la operación original una vez. Esto recupera de forma transparente los casos más comunes de invalidación sin que el usuario vea nunca un fallo.
Cerrar sesión es opcional
No tienes que cerrar sesión. Una sesión persiste hasta que ocurre uno de los eventos de invalidación mencionados arriba, por lo que la mayoría de las integraciones nunca llaman a sendLogoutRequest() — simplemente dejan que la sesión continúe.
Cierra sesión solo cuando quieras terminar la sesión deliberadamente — por ejemplo, al cambiar de operador en un terminal compartido, o para forzar un reinicio limpio de sesión. Cerrar sesión y volver a iniciar sesión también es una forma válida de reiniciar una sesión que sospechas está en mal estado.
Relacionado
- Inicio rápido — donde el inicio de sesión aparece por primera vez, en contexto.
- Cómo funciona el modelo de mensajes — por qué el resultado del inicio de sesión llega en el interceptor y no desde la llamada.
- Solución de problemas: solicitudes ignoradas / sin respuesta — el síntoma que produce un inicio de sesión faltante o perdido.
- Solución de problemas: el inicio de sesión devuelve BUSY — el único error de inicio de sesión que significa "reintentar," no "corrige tu solicitud."