ID de compte
L'ID de compte est renvoyé par le serveur de l'intégrateur lors du flux d'association. Il permet à Google d'identifier le compte sous-jacent de deux manières. Tout d'abord, identifiez plusieurs instruments qui utilisent le même compte utilisateur sous-jacent afin d'évaluer les risques et les fraudes. Ensuite, les agents du service client de Google l'utilisent pour identifier ce compte. Cette valeur doit identifier de manière unique le compte utilisateur dans les demandes d'association. Elle doit être immuable sur le compte concerné et l'utilisateur doit l'identifier.
Par exemple, si un intégrateur utilise une adresse e-mail pour l'identité, il peut s'agir de l'adresse e-mail. Toutefois, si l'intégrateur utilise une adresse e-mail pour se connecter, mais que cette adresse peut être modifiée, l'adresse e-mail n'est pas un bon choix pour l'ID de compte. Quelle que soit l'identité choisie, sa valeur doit être la même pour plusieurs tentatives d'association avec la même identité d'utilisateur de l'intégrateur de paiement.
Package d'application Android (APK)
Format de fichier de package utilisé par le système d'exploitation Android pour la distribution et l'installation d'applications mobiles.
Gestion des versions de l'API
Cette spécification est compatible avec la gestion des versions. Les versions compatibles sont configurées sur le serveur Google. Lors du passage de la version N à la version M (où M est une version majeure supérieure à N), l'intégrateur doit prendre en charge à la fois N et M jusqu'à ce que Google vérifie que tout le trafic a été migré vers M. Les versions sont identifiées différemment en fonction du contexte. Les API Android et WebRedirect transmettent la version de l'API en tant que paramètre à la requête. Les appels de serveur à serveur transmettent la version en tant que partie du chemin de l'URL.
Les versions ne sont pas fixes par le flux. Ainsi, lors de la migration de N vers M, un intégrateur peut voir une capture avec la version M et un remboursement avec la version N pour la même transaction. Pendant l'association, l'intégrateur peut recevoir une requête d'authentification de la version M avec une requête d'association de la version N.
ID d'association
Le champ associationID identifie l'association entre le compte du client et l'instrument Google. associationId est très semblable à GPT. En fait, il a la même durée de vie qu'un tag GPT et a une cardinalité individuelle par rapport à un tag GPT. La sensibilité associationId diffère du GPT sur le plan de la sensibilité. GPT est un jeton sensible utilisé pour les paiements. associationId est un identifiant public qui représente la même relation, mais qui n'est pas aussi sensible par nature.
Le associationId est transmis à l'intégrateur de paiement au cours de la associateAccount. Cette même valeur est transmise à l'intégrateur lors de la réauthentification. Cela permet à l'intégrateur d'obtenir du contexte sur le compte à authentifier. Si l'ID d'association est transmis, le compte identifié lors de l'association d'origine doit être prérempli et authentifié.
L'intégrateur de paiements doit stocker tous les ID d'association et les associer à un compte d'intégrateur particulier pendant toute la durée du contrat conclu entre l'intégrateur et Google.
ID de la demande d'authentification
Les méthodes refreshToken, associateAccount et (éventuellement) capture utilisent une référence à une authentification. Cette référence se présente sous la forme du requestId de l'authentification spécifique à laquelle Google fait référence. Ce champ doit être utilisé par l'intégrateur de paiement pour vérifier que la méthode a bien été exécutée par une authentification réussie.
Une requestId d'authentification peut être renseignée pour les méthodes de capture. Cela se produit
dans deux cas. Si Google authentifie l'utilisateur juste avant une capture, il remplit le champ requestId d'authentification. De plus, Google authentifie souvent l'utilisateur au moment de la configuration, lorsqu'un échéancier des paiements automatique est mis en place. Google écrit l'requestId d'authentification selon cette programmation et envoie l'requestId avec chaque capture associée à cette programmation particulière.
Les intégrateurs de paiements sont censés stocker toutes les requestIds d'authentification pendant 30 jours. Si un intégrateur de paiement souhaite auditer les requestIds d'authentification qui peuvent être présentes sur une demande de capture, y compris celles incluses dans les échéanciers de paiement, il doit stocker toutes les requestId d'authentification pendant toute la durée de vie du contrat conclu entre l'intégrateur et Google.
Entreprise
Une entreprise est un concept défini dans la configuration et le contrat de Google. Une entreprise définit la relation entre l'intégrateur et Google. Les clés PGP et (éventuellement) les CA racine SSL sont associées à l'entreprise. Plus important encore, une entreprise est associée à un ou plusieurs ID de compte d'intégrateur de paiement. Les GPT créés au sein d'une entreprise fonctionnent principalement pour tous les ID de compte d'intégrateur de paiement de l'entreprise. Certaines exceptions s'appliquent. C'est le cas, par exemple, si le GPT est associé à un compte libellé dans une devise (et qu'il n'accepte pas les frais de change) et qu'il tente d'effectuer un achat avec un ID de compte d'intégrateur de paiement dans une autre devise.
Mode de paiement
Toutes les transactions incluent un ou plusieurs modes de paiement, tels qu'une carte de crédit ou un transfert électronique de fonds. Ceux-ci permettent aux utilisateurs de payer des produits ou services à Google, ou de payer les utilisateurs (dans le cas d'utilisateurs d'AdSense et de développeurs Google Play). Les modes de paiement sont aussi souvent appelés "Modes de paiement", "Modes" et "Modes de paiement".
Jeton de paiement Google (GPT)
GPT est une valeur aléatoire et encodée au format base64 adapté au Web qui est générée par le serveur Google au moment de l'association et transmise au serveur de l'intégrateur. GPT est un identifiant privé qui représente le lien entre le compte de l'utilisateur, l'intégrateur et l'instrument Google. Un GPT est un jeton qui remplace les identifiants de l'utilisateur ou un ID de compte. Ce jeton est utilisé lors des parcours d'achat pour identifier le compte à crédit ou débit. Il est secret pour les deux parties. GPT ne doit jamais être envoyé en texte clair et doit être chiffré pour garantir la confidentialité.
GPT est différent de associationId, car associationId n'est pas protégé et est transmis librement par des moyens publics (URL, connexions non sécurisées). GPT n'est connu que de Google et de l'intégrateur.
L'intégrateur de paiement doit stocker tous les GPT S et les associer à un compte d'intégrateur particulier pendant toute la durée du contrat conclu entre l'intégrateur et Google.
Idempotence
Une opération idempotente peut être appliquée plusieurs fois sans modifier le résultat ni avoir de nouveaux effets secondaires au-delà de l'application initiale de l'opération. Généralement, l'idempotence utilise une "clé" pour identifier une même requête. Toutes les requêtes définies entre les deux serveurs utilisent une clé d'idempotence définie dans l'en-tête de requête. L'en-tête de requête comporte un ID de requête qui sert de clé d'idempotence. L'ID de requête est unique. Les requêtes idempotentes doivent correspondre exactement au même corps JSON, à une exception près. La valeur requestTimestamp sera différente pour chaque requête. C'est une
distinction importante. requestTimestamp correspond à l'heure à laquelle le serveur a envoyé cette requête. Il est unique pour chaque tentative. Cela permet de réduire le risque d'attaques par rejeu.
De même, une réponse idempotente doit être exactement le même corps JSON, sauf que responseTimestamp sera différent pour chaque réponse.
Toutes les méthodes de serveur à serveur, à l'exception de la méthode Echo, doivent être idempotentes. Les requêtes d'authentification envoyées à l'interface utilisateur de l'intégrateur (Android ou Web) ne sont pas idempotentes.
Pour obtenir des exemples de comportement idempotent, consultez la documentation de référence.
Identifiant (ID)
Les identifiants représentent une transaction ou une communication entre l'intégrateur de paiement et Google.
Instrument
L'instrument représente un mode de paiement stocké associé à un seul client Google. Voici quelques exemples d'instruments:
- Un numéro de carte de crédit enregistré
- Un compte bancaire et un numéro d'acheminement
Plusieurs instruments peuvent être associés à leur identité Google.
Micros
Dans cette API, les valeurs monétaires sont représentées à l'aide d'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
Intégrateur de paiements
Intégrateur externe qui traite les paiements pour une transaction utilisateur.
ID de compte de l'intégrateur de paiement
Cet identifiant représente les contraintes liées au contrat entre Google et l'intégrateur. L'ID de compte de l'intégrateur est généré par Google et attribué à l'intégrateur lors de la configuration. On parle généralement de "MID". Toutes les requêtes et réponses doivent inclure cet ID. Cet identifiant est opaque et ne doit jamais être analysé. Le format de cet identifiant peut ne pas être le même entre toutes les pièces d'identité.
Cet identifiant ne change jamais pendant toute la durée de vie d'une transaction. Dans le cas d'une capture et d'un remboursement, le même identifiant est utilisé.
Les contraintes de l'ID de compte de l'intégrateur sont définies par le contrat lui-même. En général, les contraintes concernent la facturation. Par exemple, un intégrateur accepte que les dollars CAD et MXN soient facturés en USD, mais exige que les transactions en EUR soient facturées en EUR. Dans ce cas, deux ID de compte d'intégrateur de paiement différents seront utilisés, l'un pour la facturation en USD et l'autre pour la facturation en euros.
Les identifiants peuvent être supprimés au profit de nouveaux. Si un identifiant est obsolète, Google cesse de lancer des captures pour cet identifiant. Cependant, l'intégrateur doit accepter les remboursements pour les transactions effectuées avec cet identifiant pendant un an à compter de la dernière initiation de la capture (lancement de la capture défini comme le requestTimestamp trouvé dans le requestHeader).
INFORMATIONS PERSONNELLES
Les informations permettant d'identifier personnellement l'utilisateur sont des informations qui identifient personnellement un individu et toute autre donnée pouvant être raisonnablement associée à ces informations par Google, telles que le nom, l'adresse e-mail, l'adresse postale ou le numéro de téléphone d'un utilisateur, seuls ou combinés.
Numéro de la demande
Le champ requestId identifie toutes les communications entre Google et l'intégrateur de paiement.
informations personnelles sensibles
Les informations personnelles sensibles (SPII) sont un sous-ensemble d'informations personnelles qui présentent un risque élevé pour l'utilisateur si elles sont compromises ou utilisées de manière abusive. Les informations sensibles permettant d'identifier personnellement l'utilisateur présentent souvent des exigences de traitement et de stockage restrictives imposées par des entités légales, réglementaires ou de conformité.
Jeton
Les jetons ajoutent un niveau de sécurité supplémentaire lorsque des identifiants sensibles, tels que des informations permettant d'identifier personnellement l'utilisateur ou de celles-ci, sont échangés entre Google et l'intégrateur.
Adresse de l'utilisateur
Au moment de la création de l'instrument, Google vérifie si l'utilisateur est un client Google Payments. Cela ne dépend pas du statut de client Google. Pour être un client Google Payments, nous avons besoin de l'adresse de facturation de l'utilisateur. Certaines agences de réglementation exigent que nous connaissions l'adresse complète de l'utilisateur, tandis que d'autres exigent un sous-ensemble de cette adresse.
Si l'intégrateur de paiements possède une adresse enregistrée pour cet utilisateur, Google souhaite l'obtenir lors du processus d'association afin de préremplir le formulaire d'adresse de l'utilisateur. L'utilisateur a la possibilité de modifier cette adresse préremplie. Préremplir l'adresse utilisateur facilite l'ajout d'un instrument et augmente le taux de conversion des utilisateurs qui l'ajoutent.
Si l'adresse est partagée, Google l'utilise également comme calcul dans son modèle de gestion des risques. Cela permet au moteur de gestion des risques de Google de comprendre l'adresse à laquelle l'utilisateur indique qu'il est facturé, en la comparant à l'emplacement IP actuel de l'utilisateur.
Le partage d'adresse est simplement une optimisation. Il est normal que certains intégrateurs n'aient pas d'adresse de facturation pour l'utilisateur ou ne puissent pas la partager.
Encodage Base64 adapté au Web
Norme d'encodage spécifiée dans la section 5 de la norme RFC 4648, "Encodage Base64 avec URL" et "Filename Safe Alphabet", également parfois appelé "encodage Base64 adapté au Web" ou "base64url". (Identique à l'encodage base64 avec alphabet sécurisé pour les URL et les noms de fichier de la section 4 de la norme RFC 3548). Toutes les valeurs chiffrées et signées doivent être encodées à l'aide de cette norme.