La figure 1 illustre l'architecture technique d'un processus de paiement en boucle ouverte et son interaction avec Google Wallet :
![](https://developers-dot-devsite-v2-prod.appspot.com/static/wallet/tickets/images/sys_arch_1.png?authuser=4&hl=fr)
Vous trouverez ci-dessous les définitions de chaque partie de l'architecture technique.
- Appareil mobile avec Google Wallet
Les appareils mobiles équipés de l'OS Android permettent aux utilisateurs d'ajouter leurs cartes à Google Wallet de manière sécurisée. Google Wallet facilite le processus de tokenisation, c'est-à-dire que les réseaux de paiement tokenisent la carte et ajoutent un jeton spécifique à l'appareil mobile. Pour en savoir plus sur la tokenisation, consultez Fonctionnement des paiements.
Google Wallet est compatible avec la majorité des appareils Android modernes, quels que soient leur fabricant ou leur format. Pour connaître les exigences minimales, consultez la section Conditions préalables.
- Lecteur de l'opérateur de transports en commun
Les lecteurs de l'opérateur de transports en commun sont généralement des lecteurs de cartes situés à un arrêt ou à l'entrée d'un bus. Les lecteurs et terminaux de l'opérateur de transports en commun reçoivent les identifiants de paiement de Google Wallet de la même manière que pour une carte de crédit ou de débit, physique ou sans contact. Pour accepter les paiements sans contact, le lecteur doit être conforme au protocole EMV. Pour en savoir plus, consultez Fonctionnalités principales requises.
Pour assurer la conformité des lecteurs afin qu'ils acceptent les paiements EMV mobiles, il est nécessaire d'effectuer des mises à niveau logicielles. Pour en savoir plus sur les exigences de Google pour les balises EMV, consultez la section Fonctionnalités principales requises.
Pour les lecteurs hors connexion ou ne disposant pas d'une connexion Internet haut débit suffisante, l'opérateur de transports en commun doit activer l'authentification hors connexion (ODA). Pour connaître les exigences minimales, consultez la section Conditions préalables.
- Serveur de l'opérateur de transports en commun
- Serveur backend. Ce sont généralement les opérateurs de transports en commun ou leurs intégrateurs de systèmes qui s'en servent. Les lecteurs de cartes se connectent souvent au serveur de manière intermittente et effectuent des transactions par lot. Les serveurs reçoivent des requêtes de traitement par lot et les transmettent à la société de traitement des paiements de l'opérateur de transports en commun.
- Société de traitement des paiements
- La société de traitement des paiements est l'entreprise qui gère les transactions. Elle détokenise les identifiants de paiement tokenisés et finalise la transaction avec la banque émettrice. Pour en savoir plus sur le traitement des paiements, consultez la page Fonctionnement des paiements.
- Fournisseur de jetons (TSP)
- Le TSP des réseaux de paiement fournit des services de tokenisation et de détokenisation des cartes de crédit et de débit. Les sous-traitants exploitent les TSP pour récupérer les identifiants de paiement en fonction des jetons que l'application Google Wallet leur envoie.
- Serveur Google
- Le serveur fournit un lien entre les partenaires de Google et l'appareil mobile Android de l'utilisateur. Le TSP envoie des notifications de transaction, telles que des notifications d'autorisation et de règlement, aux serveurs Google. Les serveurs Google utilisent ces informations pour présenter des notifications et des reçus de transaction à l'utilisateur.