Chaque session App2App commence par une connexion, et une session peut être invalidée par des événements hors de votre contrôle. Bien gérer ce cycle de vie fait la différence entre une intégration qui "fonctionne sur ma machine" et une qui résiste à une utilisation réelle du terminal — redémarrages, mises à jour et coupures de connexion. Ce guide explique quand une session existe, ce qui l'invalide, et comment en maintenir une active.
Pourquoi la connexion vient en premier
Jusqu'à ce que vous receviez une réponse de connexion réussie, l'application de paiement considère chaque requête que vous envoyez comme non autorisée et l'ignore silencieusement. Il n'y a ni erreur, ni exception — votre demande de paiement, de statut ou d'administration ne produit simplement aucune réponse. Un développeur qui omet la connexion passe des heures à se demander pourquoi rien ne revient.
La règle est donc absolue : une RetailerLoginResponse réussie ouvre la session, et rien d'autre ne fonctionne avant cela.
viewModelScope.launch {
clientSDK.sendLoginRequest()
}
// Attendez SuccessRetailerLoginResponse dans votre intercepteur avant
// d'envoyer toute autre requête.
Ce qui invalide une session
Une session n'est pas permanente. Chacun de ces événements y met fin, et votre prochaine requête sera ignorée jusqu'à ce que vous vous reconnectiez :
- L'application de paiement est mise à jour — une nouvelle version de l'application de paiement réinitialise la session.
- L'application de paiement redémarre — pour n'importe quelle raison, y compris un redémarrage de l'appareil.
- Votre application redémarre — votre processus étant tué puis recréé perd la session.
- La connexion entre les deux applications est perdue — la liaison IPC a été interrompue.
-
Vous avez envoyé une requête de déconnexion — un
sendLogoutRequest()explicite met fin délibérément à la session.
L'idée unificatrice : une session lie ensemble deux instances spécifiques d'applications en cours d'exécution. Si l'une ou l'autre redémarre, ou si le lien entre elles se rompt, la session qu'elles partageaient n'existe plus — même si votre code détient toujours un objet SDK qui semble prêt à être utilisé.
Quand et comment se reconnecter
Vous ne pouvez pas prédire ces événements de manière fiable, alors n'essayez pas. Structurez plutôt votre application pour que la reconnexion soit peu coûteuse et automatique :
Connectez-vous au démarrage. Lancez sendLoginRequest() lorsque votre application démarre. Cela couvre gratuitement le cas "votre application a redémarré".
Reconnectez-vous lorsque les réponses cessent d'arriver. Si vous envoyez une requête et que la réponse attendue ne vient jamais (vous pouvez le détecter avec un délai d'attente, par exemple en mode bloquant), considérez cela comme une session potentiellement perdue et reconnectez-vous avant de réessayer. Une réponse de connexion réussie confirme que la session est à nouveau active.
La reconnexion est idempotente en pratique. Appeler la connexion alors qu'une session est déjà ouverte est sans risque — vous obtenez simplement une autre réponse de connexion réussie. Donc "connectez-vous dès que vous avez un doute" est une stratégie valide ; vous ne risquez rien à vous connecter plus souvent que strictement nécessaire.
Un schéma courant et robuste : encapsulez votre logique d'envoi pour que si une opération expire, vous envoyiez automatiquement une connexion, attendiez le succès, puis réessayiez l'opération initiale une fois. Cela permet de récupérer de manière transparente des cas d'invalidation les plus fréquents sans que l'utilisateur ne voie jamais d'échec.
La déconnexion est optionnelle
Vous n'êtes pas obligé de vous déconnecter. Une session persiste jusqu'à ce qu'un des événements d'invalidation ci-dessus se produise, donc la plupart des intégrations n'appellent jamais sendLogoutRequest() — elles laissent simplement la session vivre.
Déconnectez-vous uniquement lorsque vous souhaitez délibérément mettre fin à la session — par exemple, lors du changement d'opérateur sur un terminal partagé, ou pour forcer une reconnexion propre. Se déconnecter puis se reconnecter est aussi une manière valide de réinitialiser une session que vous soupçonnez d'être dans un mauvais état.
Articles connexes
- Démarrage rapide — où la connexion apparaît pour la première fois, dans son contexte.
- Comment fonctionne le modèle de message — pourquoi le résultat de la connexion arrive dans l'intercepteur plutôt que directement de l'appel.
- Dépannage : les requêtes sont ignorées / pas de réponse — le symptôme produit par une connexion manquante ou perdue.
- Dépannage : la connexion retourne BUSY — la seule erreur de connexion qui signifie "réessayez", pas "corrigez votre requête".