Mode de paiement tokenisé
Présentation
Un mode de paiement tokenisé est un mode d'intégration des paiements dans la plate-forme de paiement. Pour qu'un utilisateur puisse effectuer un paiement avec ce mode de paiement, Google et l'intégrateur de paiements doivent procéder à un échange unique des identifiants d'identité du compte. Cette opération passe à son tour par l'établissement d'un jeton, qui représente ce mode de paiement pour cet utilisateur particulier. Ce jeton peut ensuite être utilisé pour effectuer des paiements à l'infini. Il existe actuellement deux versions de ces API. La version 2 est compatible avec les opérateurs mobiles et les fournisseurs de numéros de référence. Tous les autres fournisseurs de mode de paiement tokenisés doivent implémenter la version 1. Le reste de ce document porte sur la version 1.
Google utilise deux flux pour établir l'identité et créer ce jeton:
- Flux d'authentification: identifie et vérifie (authentifie) l'utilisateur.
- Flux d'association: établit un jeton pour un utilisateur (nouveau ou précédemment identifié et authentifié). Ce jeton représente un mode de paiement particulier appliqué à un utilisateur particulier. Le jeton pourra ensuite être utilisé pour de futurs achats.
Une fois le jeton établi, Google l'utilise tout au long du parcours d'achat pour offrir à l'utilisateur une expérience de paiement rapide et fluide. Google utilise ce jeton pour représenter une instance de mode de paiement appliquée par un client. On parle également d'instrument. Un client Google peut disposer de plusieurs modes de paiement pour des produits et services.
Enfin, tout le transfert d'argent entre la banque de l'intégrateur et celle de Google s'effectue au cours du flux de paiement.
|
|
|
|
|
Ce schéma présente une vue d'ensemble des flux:
Présentation du mode de paiement tokenisé
De manière générale, pour ajouter votre service comme mode de paiement dans les produits Google, procédez comme suit:
- Flux d'authentification
- Procédure d'association
- Parcours d'achat
- Procédure de remboursement
- Flux de paiement
Ces procédures sont décrites plus en détail dans les sections ci-dessous, et encore plus en détail dans les guides.
Concepts et terminologie
Symboles et conventions
Les mots clés "DOIT", "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS", "DOIT", "NE DOIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" utilisés dans ces documents doivent être interprétés tel que décrit dans le document RFC 2119.
Codes temporels
Tous les codes temporels sont exprimés en millisecondes écoulées depuis l'epoch Unix (1er janvier 1970) au format UTC.
Exemple :
- 23 avril 2019 20:23:25 GMT = 1556051005000 millisecondes
- 16 août 2018 12:28:35 GMT = 1534422515000 millisecondes
Montants
Dans cette API, les valeurs monétaires sont dans un format appelé "micros", la norme de Google. Les micros sont un format à précision fixe basé sur des nombres entiers. Pour représenter une valeur monétaire en micros, multipliez la valeur de la devise standard par 1 000 000.
Exemple :
- 1,23 USD = 1 230 000 microUSD
- 0,01 USD = 10 000 microUSD
Idempotence
Tous les appels de méthode dans cette API doivent avoir un comportement idempotent. Google relance sporadiquement les requêtes pour s'assurer que les transactions sont dans le même état des deux côtés. Les intégrateurs ne doivent pas tenter de traiter à nouveau une demande déjà traitée avec succès. La réponse en cas de réussite du traitement doit être indiquée à la place. Toutes les méthodes ont un RequestHeader commun, qui contient un requestId. Ce requestId est la clé d'idempotence de tous les appels.
Toute réponse non terminale (un succès non HTTP de type 200) ne doit pas être traitée de manière idempotente. Ainsi, une requête ayant précédemment reçu un code 400 (requête incorrecte ou condition préalable ayant échoué), lorsqu'elle est appelée une deuxième fois, ne doit pas renvoyer idempotemment la valeur 400. Elle doit donc être réévaluée. Lors de la réévaluation, la valeur peut renvoyer un code 400 ou être traitée correctement.
Pour en savoir plus sur l'idempotence, consultez ce guide détaillé.
Intégrateur
Une entreprise qui utilise la plate-forme de paiement Google pour son activité. Il peut s'agir d'une entreprise interne (propriétaire), comme YouTube ou AdWords, ou d'une entreprise externe (3P) souhaitant intégrer ses services pour fonctionner avec l'écosystème de Google.
Mode de paiement
Mode de paiement. C'est plus général qu'un instrument. Les modes de paiement Visa, MasterCard et PayPal sont tous des modes de paiement acceptés.
Instrument
Un mode de paiement donné par un client spécifique. Il peut s'agir, par exemple, de la carte de crédit d'un utilisateur ou de son compte PayPal. Un mode de paiement tokenisé pour un client spécifique est également un mode de paiement, car il s'agit d'une instance d'un mode de paiement pour ce client, stocké de manière sécurisée sur notre système.
Jeton
Représentation, sur le système de Google, du mode de paiement d'un utilisateur spécifique. Étant donné qu'il contient toutes les informations nécessaires pour effectuer un achat, un jeton est également un instrument. Il peut s'agir d'un numéro de compte dont dispose l'utilisateur auprès de son intégrateur.
Flux clés
Flux d'authentification
L'authentification est le premier flux qui doit avoir lieu. L'objectif du flux d'authentification est d'identifier l'utilisateur et de l'authentifier auprès de l'intégrateur. L'authentification peut se faire de plusieurs façons. Les modes de paiement tokenisés permettent d'identifier et d'authentifier l'utilisateur de deux façons:
- Authentification OTP par SMS-MT (terminée par SMS via un mobile, mot de passe à usage unique)
- Authentification de redirection
Lors de leur intégration, les intégrateurs collaborent avec Google pour choisir les mécanismes d'authentification les mieux adaptés à leur produit.
Les flux d'authentification peuvent être utilisés dans deux contextes: premièrement, pour identifier un nouveau client afin de procéder à une association, et deuxièmement, pour demander à un utilisateur de récupérer les identifiants d'un instrument existant. Le résultat du flux d'authentification peut être utilisé comme entrée dans plusieurs flux, tels que le flux d'association, le flux de jeton d'actualisation, le parcours d'achat contesté, etc. De plus, le flux d'authentification peut être utilisé en mode autonome, sans être lié à un flux ultérieur.
Authentification OTP par SMS-MT
Ce mécanisme d'authentification permet à l'utilisateur de saisir un numéro de téléphone dans une interface utilisateur Google. Google envoie ce numéro de téléphone à l'intégrateur (via la méthode sendOtp). L'intégrateur envoie un mot de passe à usage unique à l'utilisateur. L'utilisateur saisit le mot de passe dans l'interface utilisateur Google, qui l'envoie à l'intégrateur. L'intégrateur de paiements envoie alors une réponse positive.
Lorsque l'authentification OTP par SMS-MT est utilisée en mode autonome, la valeur du mot de passe à usage unique est envoyée à l'intégrateur à l'aide de la méthode verifyOtp. Cette méthode permet de vérifier que l'OTP fourni est bien celui qui a été envoyé.
Authentification de redirection
L'authentification de redirection se produit lorsque Google redirige l'utilisateur vers une application appartenant à un intégrateur. Il peut s'agir d'une application Web ou Android.
Les redirections Android et Web se comportent de la même manière. Google redirige l'utilisateur vers l'application de l'intégrateur. Celui-ci identifie et authentifie l'utilisateur sous la forme qui lui convient le mieux. Une fois authentifié, l'intégrateur redirige l'utilisateur vers l'interface utilisateur de Google pour terminer l'association. Lors de la redirection, Google fournit un requestId permettant d'identifier cette session d'authentification. Cet identifiant est ensuite utilisé comme preuve d'authentification de l'identité pendant l'association.
Les intégrateurs qui choisissent cette procédure doivent fournir une URL d'authentification Web, car il s'agit du dénominateur le plus courant sur toutes les surfaces (ordinateur de bureau ou mobile). Cependant, l'authentification Android est vivement recommandée, car elle offre la meilleure expérience utilisateur possible sur mobile.
En fonction du contexte de l'appareil et des applications installées, les interfaces utilisateur Google choisiront le Web ou la redirection des applications Android.
Ce mécanisme d'authentification offre à l'intégrateur le plus de liberté. Il existe de nombreuses façons d'authentifier et d'identifier un utilisateur. Un nom d'utilisateur et un mot de passe, ou des informations biométriques et des questions de sécurité, sont deux solutions viables. Google n'a pas l'intention de déterminer la façon dont un intégrateur valide un utilisateur. L'intégrateur se charge d'authentifier l'utilisateur. De cette façon, Google compte exploiter les différentes interfaces utilisateur de l'intégrateur pour authentifier l'utilisateur et simplement lui fournir une preuve d'authentification.
Pour en savoir plus sur l'authentification, consultez ce guide détaillé.
Processus d'association
Après le flux d'authentification via l'un des mécanismes mentionnés ci-dessus, l'utilisateur passe dans le flux d'association. Le flux d'association a pour but d'établir un jeton de paiement Google (GPT) afin de créer un mode de paiement. Ce flux effectue les opérations suivantes:
- Négocie une identité appelée "jeton" pour représenter cet utilisateur.
- Fournit des informations sur le compte afin d'informer le moteur de gestion des risques de Google.
- Il rassemble les informations nécessaires à la première configuration pour créer et établir le
GPT.
En conséquence, la GPT établie est approuvée par Google et l'intégrateur.
Deux utilisateurs Google peuvent partager le même compte utilisateur avec l'intégrateur. Dans ce cas, chaque utilisateur dispose d'un instrument différent. Pour chaque instrument, il existe un flux d'association indépendant, et donc un GPT unique.
Cette illustration vous présente un faux mode de paiement tokenisé appelé InvisiCash. Ce schéma montre les étapes à suivre par un utilisateur pour le flux d'authentification et le flux d'association.
Présentation du flux d'association
- Une utilisatrice Google dont l'adresse e-mail est sf@gmail.com souhaite ajouter son compte InvisiCash au Google Play Store afin de pouvoir l'utiliser pour effectuer des achats.
- Le Google Play Store ouvre l'application InvisiCash pour s'authentifier.
L'utilisateur se connecte à son compte InvisiCash avec l'adresse e-mail sally@otheremail.com. Il se peut qu'elle utilise son adresse Gmail dans les deux cas, s'il s'agit de l'adresse de connexion de son compte InvisiCash.
L'application InvisiCash renvoie l'ID d'authentification au Google Play Store.
Le Google Play Store envoie l'ID d'authentification aux serveurs Google.
Le serveur Google envoie un message au serveur InvisiCash afin d'associer le compte. Cette association inclut un identifiant d'authentification, un jeton de paiement Google (
GPT) et un identifiant d'association.Les serveurs InvisiCash stockent le jeton de paiement Google (
GPT) et l'ID d'association. Ils sont désormais associés au compte InvisiCash de Sally.InvisiCash approuve cette association. Les serveurs de Google créent ensuite un mode de paiement que vous pourrez utiliser pour vos futurs achats.