Ajouter le stationnement à une application client commence par l'interface prise en charge et un plan clair pour paiement, reçus, assistance et maintenance.
Cela dépend de l'interface réellement proposée : une API documentée, des composants de développement ou une page hébergée. Ces livrables diffèrent ; le parcours client proposé doit donc être démontré avec les outils et l'authentification pris en charge.
Une offre en marque blanche doit aussi être lue attentivement. Elle n'inclut pas automatiquement toutes les interfaces, les modifications de marque demandées ou la maintenance de l'application dans les boutiques.
Ajouter le stationnement à une application existante transpose le parcours de l'ancien terminal de paiement dans une interface déjà utilisée par les clients. Il faut toujours retrouver la visite, expliquer le prix, afficher l'état du paiement et fournir un reçu.
Une API échange des données, un SDK fournit des composants de développement et une page hébergée déporte une plus grande partie de l'interface. Chaque approche laisse à l'équipe de développement des tâches différentes d'hébergement, de suivi des versions et de maintenance.
L'intégration peut convenir aux utilisateurs qui gèrent déjà leur location ou leurs visites dans une application. Pour les visiteurs occasionnels, une page de paiement distincte et accessible peut suffire. Imposer un autre compte peut ajouter une étape inutile à une courte visite.
Quel que soit le parcours choisi, une assistance reste nécessaire lorsque le téléphone, le navigateur ou la recherche d'immatriculation empêchent de terminer. L'accessibilité et le rattachement de la session doivent être prévus dès la conception.
Dans un environnement de test, suivez la recherche de session, la confirmation du prix, le paiement, l'accès au reçu et la correction. Passez l'application en arrière-plan, puis revenez après une modification de la session. Elle doit récupérer l'état confirmé de la transaction plutôt que se fier à un écran mémorisé par le téléphone.
Un parcours de paiement annulé doit lui aussi avoir un état distinct. Précisez qui héberge chaque composant et comment les changements incompatibles sont annoncés. Les secrets de paiement doivent rester dans le serveur approuvé ou le service de paiement ; le code mobile n'est pas un coffre protégé pour les identifiants.
Aero Ranger CORE décrit des échanges de données pris en charge grâce à des intégrations configurables. Cela est pertinent lorsque le contexte opérationnel du stationnement doit rejoindre un autre service, à condition de convenir de l'interface nécessaire et des données échangées.
La description publique n'établit pas l'existence d'un SDK mobile ouvert, d'un paiement intégré ou d'un forfait de maintenance d'application. Ces livrables, ainsi que l'authentification, le suivi des versions et la responsabilité du développement, doivent être définis avant de commander l'interface client.
Aero Ranger: Intégrations sans code
Les sources ont été examinées à la date de publication.
