À déterminer:ajoutez une brève description de l'e-portefeuille (comme pour la monnaie électronique).
À déterminer:Regardez une démonstration du flux d'e-portefeuille après avoir intégré votre mode de paiement aux entités Google.
Les principaux flux de paiement standard Google impliqués dans une transaction d'e-portefeuille sont décrits ci-dessous.
Processus d'association
Google Standard Payments permet aux intégrateurs de créer un flux de création d'instrument et de parcours d'achat afin d'offrir une expérience de paiement rapide et fluide à leurs utilisateurs.
Un client Google possède un ou plusieurs modes de paiement. Un instrument est un moyen de payer des services et des biens dans les différents écosystèmes et places de marché de Google. Pour ajouter un instrument, l'utilisateur doit l'associer à des identifiants externes et les authentifier. Une carte de crédit en est un bon exemple. Une carte de crédit est associée à un numéro de carte (PAN) enregistré par Google et à un cryptogramme utilisé pour l'authentification. L'utilisateur ajoute un instrument en saisissant le PAN et le CVN dans une interface utilisateur Google. Google stocke le PAN de manière sécurisée une fois que la société de traitement des cartes de crédit a validé les numéros PAN et CVN. De même, dans cette spécification, nous allons associer la preuve d'authentification à un instrument du côté de Google. Nous appelons cette association du compte à un instrument le flux d'association.
Le résultat du flux d'association correspond à l'échange du Google Payment Token (GPT), qui est convenu entre Google et l'intégrateur. Lors de la capture, le tag GPT est transmis à l'intégrateur de paiement (qui détient le compte utilisateur) pour identifier le compte utilisateur à facturer.
Il existe de nombreuses façons d'authentifier un utilisateur afin de prouver qu'il est le propriétaire d'un compte. Les noms d'utilisateur et les mots de passe sont à sens unique, mais les mots de passe à usage unique, les informations biométriques et les questions de sécurité sont également des solutions viables. Google n'a pas l'intention de déterminer la façon dont un intégrateur de paiements valide un utilisateur. Nous pensons que c'est l'intégrateur de paiement qui est le mieux placé. Dans le cadre de cette spécification, Google souhaite donc exploiter les différentes interfaces utilisateur de l'intégrateur de paiement pour authentifier l'utilisateur et simplement fournir à Google une preuve d'authentification. Nous appelons cela le flux d'authentification.
Le résultat du flux d'authentification est une preuve d'authentification.
Le flux d'association nécessite que Google fournisse une preuve d'authentification par l'intégrateur de paiement. Avant le flux d'association, Google appelle le flux d'authentification pour obtenir cette preuve.
L'exemple ci-dessous montre les étapes par lesquelles un utilisateur suivra le flux d'authentification et le flux d'association. L'exemple ci-dessous vous présente un faux portefeuille électronique appelé InvisiCash.
Remarques sur ce diagramme:
- Aux étapes 1 et 3, notez que l'identité de l'utilisateur (adresse e-mail) est différente entre Google et InvisiCash.
sf@gmail.cometsally@otheremail.com, respectivement. C'est normal et attendu. - Entre les étapes 3 et 4, l'application InvisiCash (ou l'UI Web si l'utilisateur ne l'a pas installée) peut effectuer toutes les opérations nécessaires pour authentifier l'utilisateur, y compris communiquer avec le serveur InvisiCash.
Parcours d'achat
Une fois l'association terminée et que l'utilisateur dispose d'un nouvel instrument, il peut l'utiliser pour acheter des biens et des services via Google. Au moment de l'achat, l'utilisateur peut être en session ou non. Tout dépend du contexte de l'achat. Par exemple, pour un achat via un abonnement, l'utilisateur ne sera probablement pas en session. Au moment de l'achat, Google présente le tag GPT à l'intégrateur de paiement. L'intégrateur de paiements utilisera ce GPT pour identifier le compte correct à débiter. C'est ce qu'on appelle le parcours d'achat.
L'exemple ci-dessous continue une fois que l'utilisateur sf@gmail.com a effectué l'association et qu'un instrument a été créé. L'utilisateur veut maintenant
acheter des produits.
Parfois, l'intégrateur de paiement ou Google peuvent exiger que l'utilisateur s'authentifie avant d'effectuer un achat. Il y a plusieurs raisons à cela. Exemple :
- Le moteur de gestion des risques de Google détermine qu'un paiement semble suspect
- Conformément aux exigences réglementaires, un OTP est exigé lors de chaque achat
Dans ce cas, Google associe le flux d'authentification au parcours d'achat. L'utilisateur est redirigé vers l'UI de l'intégrateur pour s'authentifier. Le résultat du flux d'authentification est une preuve de l'identité et de l'authentification de l'utilisateur. Cette preuve est ensuite envoyée avec les informations d'achat lors du parcours d'achat.
Dans l'exemple ci-dessous, l'utilisateur sf@gmail.com a effectué l'association et un instrument a été créé. Au cours du parcours d'achat, le serveur Google invite l'utilisateur à se prémunir contre la fraude:
Flux d'actualisation des jetons
Au cours du flux d'association, l'intégrateur de paiements peut indiquer à Google que ce GPT expire dans X mois. Bien que Google préfère les jetons sans date d'expiration, il reconnaît que ce ne peut pas toujours être le cas et prend donc en charge l'expiration des jetons. Lorsqu'un jeton est sur le point d'expirer, Google redirige l'utilisateur via un flux d'authentification. L'utilisateur est redirigé vers l'interface utilisateur de l'intégrateur pour s'authentifier. Le résultat du flux d'authentification est une preuve de l'identité et de l'authentification de l'utilisateur. Cette preuve est ensuite envoyée à l'intégrateur pour prolonger le délai d'expiration de GPT. C'est ce qu'on appelle le flux "refreshToken".
L'exemple ci-dessous continue une fois que l'utilisateur sf@gmail.com a effectué l'association et qu'un instrument a été créé. Le jeton de l'utilisateur expire bientôt. Google demande donc à l'utilisateur d'actualiser son instrument:
Le flux d'authentification est utilisé dans deux modalités différentes. La première consiste à essayer d'authentifier un utilisateur au moment de l'association. Pour le moment, l'identité de l'utilisateur est inconnue et il appartient à l'utilisateur de la saisir. L'identité peut prendre la forme d'un nom d'utilisateur, d'une adresse e-mail ou d'un numéro de téléphone. La deuxième modalité consiste à essayer d'authentifier l'utilisateur pour vérifier qu'il connaît les identifiants d'un instrument existant. Dans ce cas, l'utilisateur a déjà ajouté le mode de paiement et associé le compte de son intégrateur de paiement. Dans cette modalité, nous voulons vérifier que la personne possède des informations d'identification pour une identité d'utilisateur particulière. L'utilisateur ne doit pas pouvoir modifier l'identité du compte en cours de validation. Pour ce faire, nous envoyons à l'intégrateur de paiement un ID d'association au moment de l'association. Au moment de l'authentification, Google envoie le même ID d'association à l'intégrateur. L'intégrateur utilise l'ID d'association pour rechercher le compte qui doit être authentifié.
Flux de versement
Google est le système de comptabilité et tient compte des transferts de fonds. Google envoie quotidiennement un relevé de paiement à l'intégrateur de paiements. Le relevé fournit un récapitulatif du montant que l'intégrateur de paiement doit à Google, ainsi que des instructions sur la manière de payer Google. Pour rapprocher l'intégrateur des paiements, il peut interroger Google sur les détails du niveau de transaction qui constituent le relevé de paiement.
Voici l'exemple de flux: 