Présentation des paiements standards Google pour les opérateurs

Dans l'univers des paiements standards de Google, la facturation par l'opérateur est considérée comme un mode de paiement tokenisé, ce qui signifie que Google et l'intégrateur de paiements effectuent un échange unique des identifiants de compte pour établir un jeton. Par la suite, ce jeton est présenté à l'intégrateur de paiements afin d'identifier le compte à facturer.

D'autres modes de paiement utilisent également la tokenisation. Voici donc une présentation générale des modes de paiement tokenisés, qui s'appliquent principalement à la facturation par l'opérateur. Le flux d'authentification, d'association, d'achat et de versement est décrit plus en détail dans cette présentation. Cette page fournit plus d'informations concernant la facturation par l'opérateur.

Les opérateurs intègrent Google Standard Payments en implémentant les API des flux suivants:

Procédure Description Équivalent avec la spécification DCB3
Authentification Identifie et authentifie le compte de l'utilisateur dans le système de l'intégrateur de paiement qui sera utilisé pour effectuer des paiements via la facturation directe par l'opérateur. SMS-MO avec GoogleUserToken
Association Échange un jeton de longue durée que Google et l'intégrateur de paiement peuvent utiliser pour effectuer des paiements à l'aide du compte de l'intégrateur de paiement de l'utilisateur. approuver le rappel avec OperatorUserToken et GetProvisioning()
FundsTransfer Transfert synchrone des fonds du compte de l'intégrateur de paiements de l'utilisateur. cède la responsabilité à l'intégrateur de paiements Lignes Auth() et CHARGE dans les fichiers de requêtes par lot
Remboursement Renvoie de manière synchrone tout ou partie des fonds associés à un transfert de fonds précédent vers le compte de l'intégrateur de paiement de l'utilisateur. Transfère la responsabilité à Google Lignes REFUND dans les fichiers de requêtes par lot
Versement Règlement basé sur des API, de préférence quotidien Facture mensuelle au format PDF, fichier contenant les détails de la facture mensuelle, fichier de rapprochement quotidien
UpdateAssociatedAccount Informe Google des modifications apportées au compte de l'intégrateur de paiement d'un utilisateur (par exemple, limites de transactions ou état de provisionnement) Sondage GetProvisioning()
Fraude Informe Google des transactions annulées en raison d'un litige avec un utilisateur. Cela permet d'améliorer le moteur de gestion des risques de Google, mais n'a aucune incidence sur la responsabilité financière. Aucun

Comparaison globale avec la spécification DCB3

La spécification Google Payments standard résout les mêmes problèmes que la spécification DCB3. Cependant, différentes technologies et conceptions d'API différentes améliorent la solution. Voici un résumé des principales différences:

Comparaison des technologies de pile

Toutes les communications d'API sont effectuées à l'aide de requêtes HTTPS POST avec un fichier JSON signé et chiffré par PGP. Cela signifie que Google et l'intégrateur de paiements n'ont chacun qu'une seule clé PGP à alterner. Ces technologies offrent également une meilleure prise en charge du protocole SOAP. Pour en savoir plus sur la pile de communication, cliquez ici.

Comparaison de la philosophie des API

DCB3 s'appuie beaucoup sur les fichiers pour rapprocher l'état des paiements. Google Payments Standard ne contient aucun fichier. Les appels d'API font l'objet de nouvelles tentatives idempotentes et indéfiniment jusqu'à ce qu'un état final soit déterminé.

Les états finaux sont vraiment finaux pour une clé d'idempotence particulière. Les bugs et les états indéterminés ne sont pas modélisés comme des refus, mais plutôt comme des réponses HTTP non 200. Cela nous permet d'identifier les bugs plus rapidement et d'éviter de les masquer en tant que refus.

Nouvelles fonctionnalités

Le paiement standard Google est compatible avec de nouvelles fonctionnalités, y compris:

  • API Fraud pour informer le moteur de gestion des risques de fraudes de Google
  • Mettre à jour l'API Associated Account pour informer Google des changements de provisionnement, de limites de transactions et d'état du compte
  • Meilleure prise en charge des questions d'authentification lors des achats (codes USSD, par exemple)
  • Cycle de paiement quotidien

Carte terminologique des paiements standard de Google entre DCB3 et Google

Dans cette documentation et dans la spécification elle-même, vous verrez une terminologie nouvelle, mais celle-ci ne correspond qu'à des mots différents pour décrire des concepts existants.

  • Opérateur -> Intégrateur de paiement

AVERTISSEMENT: Pour éviter toute confusion avec le concept d'intégrateur de facturation directe par l'opérateur, ce document tente d'utiliser les termes "intégrateur de paiement" et "intégrateur de facturation directe par l'opérateur" plutôt que de simples "intégrateurs". Cependant, la documentation générale de Google Standard Payments utilise généreusement le terme "intégrateur de paiement" comme raccourci pour "intégrateur de paiement".

  • ID de contrat de facturation -> ID de compte de l'intégrateur de paiement
  • OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
  • correlation_id -> requestId
  • Partage des revenus -> frais

Flux d'authentification

Pour obtenir une présentation générale du flux d'authentification pour les modes de paiement tokenisés, consultez cette page.

Caractéristiques de la facturation par l'opérateur

Pour la facturation par l'opérateur, l'objectif du flux d'authentification est de prouver que l'utilisateur contrôle la carte SIM associée au compte de son opérateur. Les utilisateurs de la facturation par l'opérateur peuvent être authentifiés à l'aide de l'un des trois mécanismes suivants:

Les intégrateurs de paiements peuvent collaborer avec Google pour choisir les mécanismes d'authentification les mieux adaptés à leur produit.

Comparaison avec la facturation directe par l'opérateur 3

Le flux d'authentification remplace le rappel approveuser à Google par OUT de la spécification DCB3.

Dans DCB3, l'authentification et l'association ont été combinées en un seul flux. Dans Google Standard Payments, l'authentification est une préoccupation distincte de l'association de compte.

Processus d'association

Pour obtenir une présentation générale du flux d'association pour les modes de paiement tokenisés, consultez cette page.

La principale différence entre le flux d'association utilisé pour les instruments de facturation par l'opérateur et le flux général de modes de paiement tokenisés est que la preuve d'authentification fournie dans la méthode associateAccount varie selon que l'intégrateur de paiement a demandé ou non une question d'authentification supplémentaire à l'utilisateur.

Si l'intégrateur de paiements répond qu'il souhaite relever un défi supplémentaire pour les utilisateurs, la preuve d'authentification sera la preuve d'identité fournie par le mécanisme d'authentification particulier utilisé par Google pour la vérification supplémentaire. Par exemple, la preuve d'authentification produite par le mécanisme OTP SMS-MT est le requestId d'une méthode sendOtp plus l'OTP lui-même.

Attributs de l'instrument

La section "Attributs d'instrument" de la présentation générale du mode de paiement tokenisé aborde le concept de accountAlias, accountNickname et fullAccountNickname.

Caractéristiques de la facturation par l'opérateur

  • accountAlias devrait être le numéro de téléphone de l'utilisateur. Il permettra d'identifier le mode de paiement si l'utilisateur appelle l'assistance Google au sujet de son compte.
  • accountNickname et fullAccountNickname sont des noms à afficher permettant d'identifier l'instrument dans l'interface utilisateur.

Comparaison avec la spécification DCB3

Le flux d'association remplace les composants suivants de la spécification DCB3:

  • Appel SOAP GetProvisioning
  • Appel SOAP GetSubscriberAddress
  • Sortie générée par l'opérateur

La grande différence réside dans le fait que Google génère le jeton de paiement Google (GPT) lors du flux d'association au lieu de le faire par l'opérateur.

Il est également important de noter que contrairement à DCB3, où les sorties sont limitées à un BillingAgreementId particulier, GPT ne s'applique pas à un PaymentIntegratorAccountID particulier.

Flux d'actualisation des jetons

Pour obtenir une présentation générale du flux des jetons d'actualisation pour les modes de paiement tokenisés, consultez cette page.

Caractéristiques de la facturation par l'opérateur

Pour les instruments de facturation par l'opérateur, nous déconseillons vivement l'expiration des jetons de paiement Google, car cela entraîne l'annulation des commandes d'abonnement. Plutôt que d'expirer les jetons et de compter sur le flux de jetons d'actualisation pour les résoudre, vous pouvez souvent réaliser votre cas d'utilisation en utilisant le flux de mise à jour de compte décrit ci-dessous.

Processus de mise à jour du compte

Le flux de mise à jour du compte permet à l'intégrateur de paiements d'informer Google des modifications apportées au compte d'intégrateur de l'utilisateur. Ces champs sont initialement fournis à Google lors du flux d'association. Voici quelques exemples de données de compte que l'intégrateur de paiements peut souhaiter mettre à jour:

  • Les limites de transaction mensuelles, quotidiennes et par article de l'utilisateur
  • l'état de provisionnement du compte d'intégrateur de l'utilisateur
  • Type de compte d'intégrateur de l'utilisateur (prépayé, post-payé, entreprise, etc.)
  • "accountAlias", "accountPickname" ou "fullAccountPickname" de l'utilisateur
  • si l'utilisateur a configuré, supprimé ou modifié un code PIN statique pré-partagé ;
  • si l'utilisateur a clôturé son compte ou modifié son numéro de téléphone, ce qui invalide le mode de paiement de l'utilisateur dans le système de Google.
  • flux de suppression de jetons

Comparaison avec la spécification DCB3

Le flux de mise à jour du compte remplace les composants suivants de la spécification DCB3:

  • Interrogation de l'appel SOAP GetProvisioning
  • Invalidation périodique des jetons

Parcours d'achat

Pour obtenir une présentation générale du parcours d'achat pour les modes de paiement tokenisés, consultez cette page.

Caractéristiques de la facturation par l'opérateur

Certains opérateurs utilisent USSD ou une autre technologie pour collecter le code de leurs utilisateurs à chaque achat. Pour ces opérateurs, au lieu d'appeler capture(), nous appelons asynchroneCapture(). L'opérateur laisse 30 secondes à l'opérateur pour demander son code PIN à l'utilisateur et finaliser la capture. Une fois l'état final du paiement déterminé, l'opérateur en informe Google en appelant captureResultNotification().

Comparaison avec la spécification DCB3

Il y a des changements majeurs.

  • Appel de méthode synchrone unique -- capture() au lieu de auth() + fichier par lot
  • Aucun fichier de lot
  • Aucune méthode cancel() (capture + remboursement au lieu d'authentification + annulation)
  • Aucun champ "user_message" en réponse. Les codes de refus sont mappés sur les messages appartenant à Google et localisés dans la langue du compte de l'utilisateur.
  • Changements de terminologie clés :
    • CorrelationId -> requestId
    • BillingAgreementId -> paymentIntegratorAccountId (ID de compte de paiement intégré)
    • OperatorUserToken -> googlePaymentToken

Processus d'achat en cas de contestation

Nous sommes en cours de développement afin de prendre en charge un parcours d'achat incluant une question d'authentification à l'utilisateur avant chaque achat. La plupart des méthodes d'authentification pouvant être utilisées avant le flux d'association peuvent également l'être avant le parcours d'achat contesté afin de fournir une authentification supplémentaire aux utilisateurs.

Procédure de remboursement

Pour obtenir une présentation générale du parcours de remboursement pour les modes de paiement tokenisés, consultez cette page.

Le mode de paiement tokenisé n'accepte qu'un seul flux de remboursement correspondant à un message. La méthode de remboursement permet de rembourser intégralement ou partiellement un achat. Plusieurs remboursements partiels permettent de rembourser un seul achat.

Caractéristiques de la facturation par l'opérateur

Les modes de facturation par l'opérateur n'ont rien de spécial dans le flux de remboursement.

Comparaison avec la spécification DCB3

Les remboursements sont déclenchés par un appel d'API synchrone au lieu d'un fichier. En outre, plusieurs remboursements partiels peuvent être créés pour un seul paiement initial, au lieu de prendre en charge un seul remboursement intégral.

Flux de versement

Pour obtenir une présentation générale du flux de paiement pour les modes de paiement tokenisés, consultez cette page.

Le flux de paiement correspond à la façon dont Google et l'intégrateur de paiements effectuent le règlement. Google est le système de comptabilité et prend en compte les transferts de fonds. Google envoie régulièrement un relevé de paiement à l'intégrateur de paiements. Le relevé récapitule le montant que l'intégrateur de paiement doit à Google, ainsi que des instructions pour payer Google. Pour effectuer un rapprochement, l'intégrateur des paiements peut interroger Google pour obtenir les informations au niveau de la transaction qui constituent le relevé de paiement.

Caractéristiques de la facturation par l'opérateur

Les remittanceStatementDetails de facturation par l'opérateur incluent des champs supplémentaires qui ne figurent pas encore dans les définitions d'API du flux de paiement. comprend les étapes ci-dessous :

  • revshareCategory
  • itemPrice
  • tax
  • timestamp

Pour les opérateurs ayant conclu un accord de partage des revenus 50/50 avec Google, les frais indiqués dans la remittanceStatementDetails sont agrégés par revshareCategory, et non plus par événement.

Comparaison avec la spécification DCB3

Le flux de versement remplace les concepts suivants dans la spécification DCB3:

  • Rapport de facturation mensuel/rapport de paiement au format PDF
  • Fichier CSV contenant les détails de la facture mensuelle
  • Fichiers CSV de rapprochement quotidiens

Les principales différences sont la suppression de tous les fichiers et la prise en charge des envois de fonds quotidiens. Au lieu de fichiers, le montant à reverser est envoyé via une API synchrone, et une autre API accepte l'interrogation de détails sur l'instruction de paiement.

Flux de rapports sur les fraudes

Le flux de signalement de fraude permet à un intégrateur de paiement d'informer Google d'une transaction potentiellement frauduleuse en appelant la méthode fraudNotification. Ce flux permet de mettre à jour le moteur de gestion des risques interne de Google et n'initie aucun transfert d'argent.

Caractéristiques de la facturation par l'opérateur

Les modes de facturation par l'opérateur n'ont rien de spécial dans le flux des notifications d'annulation de paiement.