Mode de paiement tokenisé
Présentation
Un mode de paiement tokenisé (FOP) est un type d'intégration de paiement 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 paiement doivent effectuer un échange unique des identifiants de l'identité du compte. Cette opération passe par l'établissement d'un jeton représentant le mode de paiement de cet utilisateur. Ce jeton peut ensuite être utilisé pour des paiements répétés. 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 modes 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 par un utilisateur donné. Ce jeton pourra ensuite être utilisé pour de futurs achats.
Une fois le jeton établi, Google l'utilisera pendant le parcours d'achat pour offrir à l'utilisateur une expérience de paiement rapide et fluide. Google utilise ce jeton pour représenter une instance d'un mode de paiement par un client. On parle également d'instrument. Un client Google peut disposer de plusieurs modes de paiement pour régler des produits et des services.
Enfin, tout transfert d'argent entre la banque de l'intégrateur et la banque de Google s'effectue via le flux de versement.
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
Ce schéma présente une vue d'ensemble des flux:
Présentation du mode de paiement tokenisé
De manière générale, l'ajout d'un service comme mode de paiement aux produits Google implique les flux suivants:
- Flux d'authentification
- Parcours d'association
- Parcours d'achat
- Processus de remboursement
- Flux de versement
Ces flux sont décrits plus en détail dans les sections ci-dessous, et encore plus en détail dans la section Guides.
Concepts et terminologie
Symboles et Conventions
Les mots clés « DOIT », "NE DOIT PAS", "OBLIGATOIRE" « SHALL », « NE DOIT PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « MAI », et "FACULTATIF" de ces documents doivent être interprétées conformément à la norme RFC 2119.
Codes temporels
Tous les codes temporels sont exprimés en millisecondes depuis l'epoch Unix (1er janvier 1970) dans le fuseau 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 au format "micros", une norme chez 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 € = 1 230 000 micro-USD
- 0,01 € = 10 000 micro-USD
Idempotence
Tous les appels de méthode dans cette API doivent avoir un comportement idempotent. Google réessaiera sporadiquement les requêtes pour s'assurer que les transactions se trouvent 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 indiquant que le traitement a réussi doit être indiquée à la place. Toutes les méthodes ont un élément RequestHeader commun qui contient un requestId. Cet requestId est la clé d'idempotence pour tous les appels.
Toute réponse non terminale (non HTTP 200-succès) ne doit pas être traitée de manière idempotente. Ainsi, une requête ayant précédemment reçu une réponse 400 (mauvaise requête/condition préalable ayant échoué), lorsqu'elle est appelée une seconde fois, ne doit pas renvoyer idempotente 400. Elle doit être réévaluée. Lors de la réévaluation, elle peut renvoyer un code 400 ou être traitée correctement.
Pour en savoir plus sur l'idempotence, consultez ce guide détaillé.
Intégrateur
Entreprise qui utilise la plate-forme de paiement de Google pour son activité. Il peut s'agir d'entreprises internes (propriétaires), comme YouTube ou AdWords, ou d'entreprises externes (tierces) souhaitant intégrer leurs services pour qu'ils fonctionnent avec l'écosystème de Google.
Mode de paiement
Mode de paiement. Ceci est plus général qu'un instrument. Les cartes Visa, MasterCard et PayPal sont toutes des modes de paiement acceptés.
Instrument
Instance particulière d'un mode de paiement par un client spécifique. (carte de crédit d'un utilisateur ou son compte PayPal, par exemple). Un mode de paiement tokenisé pour un client particulier constitue également un mode de paiement, car il s'agit d'une instance de 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 à un achat, un jeton joue également un rôle d'instrument. Il peut s'agir d'informations telles que le numéro de compte d'un utilisateur auprès de son intégrateur.
Principaux flux
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 s'effectuer de différentes manières. Les modes de paiement tokenisés prennent en charge deux méthodes pour identifier et authentifier l'utilisateur:
- Authentification OTP SMS-MT (arrêt mobile SMS, mot de passe à usage unique)
- Authentification par redirection
Lors du processus d'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: d'abord, pour identifier un nouveau client afin de créer une association, et d'autre part, pour demander à un utilisateur les identifiants d'un instrument existant. Le résultat du flux d'authentification peut être utilisé comme entrée pour plusieurs flux, tels que le flux d'association, le flux de jetons 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 SMS-MT
Avec ce mécanisme d'authentification, l'utilisateur saisit 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 paiement envoie alors une réponse positive.
Lorsque l'authentification OTP SMS-MT est utilisée en mode autonome, la valeur de l'OTP est envoyée à l'intégrateur à l'aide de la méthode verifyOtp. Cette méthode permet de vérifier que le mot de passe à usage unique fourni est bien celui qui a été envoyé.
Authentification par redirection
Pour cela, Google redirige l'utilisateur vers une application appartenant à l'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 semble la plus naturelle. 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 afin d'identifier cette session d'authentification. Cet identifiant est ensuite utilisé comme preuve d'authentification de l'identité lors de l'association.
Les intégrateurs qui choisissent ce flux doivent fournir une URL d'authentification Web, car il s'agit du dénominateur le plus courant sur toutes les surfaces (ordinateur ou mobile). Toutefois, l'authentification Android est vivement recommandée pour offrir une expérience utilisateur optimale sur mobile.
Selon le contexte de l'appareil et les applications installées, les interfaces utilisateur Google choisiront la redirection vers le Web ou l'application Android.
Ce mécanisme d'authentification offre le plus de liberté à l'intégrateur. Il existe de nombreuses façons d'authentifier et d'identifier un utilisateur. Le nom d'utilisateur et le mot de passe, ou les informations biométriques et les questions de sécurité, sont des solutions viables. Google n'a pas l'intention de dicter la façon dont un intégrateur valide un utilisateur. L'intégrateur se charge de l'authentification de l'utilisateur. Google a ainsi l'intention de tirer parti des différentes interfaces utilisateur de l'intégrateur pour authentifier l'utilisateur et simplement fournir à Google une preuve d'authentification.
Pour en savoir plus sur l'authentification, consultez ce guide détaillé.
Flux 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. L'objectif du flux d'association est d'établir un jeton Google Payment (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 au moteur de gestion des risques de Google.
- Regroupe les informations de configuration initiale nécessaires pour créer et établir le
GPT.
Il en résulte que le GPT établi est convenu à la fois entre 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 mode de paiement 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. Cela illustre les étapes qu'un utilisateur doit suivre 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 afin de vous authentifier.
L’utilisateur se connecte à son compte InvisiCash avec l’adresse e-mail sally@autreemail.com. Il se peut qu'elle utilise son adresse e-mail Gmail pour ces deux comptes s'il s'agit de ses informations de connexion à son compte InvisiCash.
L'application InvisiCash renvoie l'identifiant d'authentification au Google Play Store.
Le Google Play Store envoie l'identifiant d'authentification aux serveurs Google.
Le serveur Google envoie un message au serveur InvisiCash pour associer le compte. Cette association comprend un ID d'authentification,
GPT(jeton de paiement Google) et un ID d'association.Les serveurs InvisiCash stockent le jeton Google Payment (
GPT) et l'ID d'association. Tous deux sont désormais associés au compte InvisiCash de Sally.InvisiCash approuve cette association. Les serveurs de Google créent ensuite un instrument qui pourra être utilisé pour de futurs achats.