Transactions initiées par le marchand (MIT)

Présentation de l'assistance MIT

Les transactions initiées par le marchand (MIT) sont des transactions traitées sans que l'utilisateur soit activement connecté. Cette mise à jour de l'API Google Pay Online offre une meilleure visibilité pour ces types de transactions, une expérience utilisateur améliorée grâce à une UX dédiée aux informations de facturation et une meilleure continuité des paiements.

Principaux cas d'utilisation

  • Paiements récurrents : services de streaming numérique, abonnements ou services publics.
  • Paiements différés : réservations d'hôtel, précommandes ou frais de non-présentation
  • Recharges automatiques : recharges de valeur stockée pour les cartes de transport ou les cartes cadeaux.

Implémentation de l'API MIT

L'API MIT est une extension de l'API LoadPaymentData existante. Les intégrateurs doivent inclure exactement un objet *TransactionInfo pour spécifier l'intention de facturation. Google propose trois options en fonction du type de transaction initiée par le marchand :

Type de transaction Nom de l'objet Description
Récurrence RecurringTransactionInfo Utilisé pour les frais à fréquence fixe. Compatible avec les essais, ainsi qu'avec la facturation prépayée et postpayée.
Différé DeferredTransactionInfo Utilisé pour un seul débit à une date future prédéterminée.
Rechargement automatique AutomaticReloadTransactionInfo Utilisé pour recharger un compte à valeur stockée lorsque le solde est inférieur à un seuil minimal.

Procédure d'intégration

  1. Documentation : accédez au site pour les développeurs pendant le programme d'accès anticipé. Les trois nouvelles définitions d'objet se trouvent dans la section "Référence des objets" et sont directement liées dans la liste précédente.
  2. Implémentation : utilisez le ou les objets *TransactionInfo appropriés pour votre système dans votre requête API.
    • Notez qu'un seul objet peut être transmis par requête à l'API. Il incombe à chaque marchand de déterminer l'objet à utiliser et de renseigner les champs.
  3. Test : utilisez l'environnement de test pour vérifier que les informations de facturation s'affichent correctement dans la fiche de paie.
  4. Lancement : mettez en ligne votre application une fois les paramètres validés.

Gestion du cycle de vie des jetons (TLM)

La gestion du cycle de vie des jetons assure la continuité des paiements en fournissant des notifications en temps réel lorsque des jetons de paiement sécurisés sont mis à jour ou désactivés. Pour en savoir plus, consultez la documentation sur la gestion du cycle de vie des jetons :,,,.

Événements clés des jetons

  • Désactivation/Suppression : envoie une notification lorsqu'un jeton n'est plus utilisable.
  • Mise à jour du suffixe du FPAN : se produit lorsque le numéro de compte principal de financement sous-jacent est mis à jour.

Conditions requises pour la configuration du serveur

Les marchands directs et les fournisseurs de services de paiement (PSP) doivent établir un système permettant de recevoir, de déchiffrer et de traiter ces messages.

Exigence Description
Point de terminaison Point de terminaison HTTPS sécurisé pour recevoir les appels POST.
Authentification Doit gérer la validation de la signature et le déchiffrement des messages.
Réponse Renvoie SUCCESS pour continuer à recevoir les notifications, ou TOKEN_NOT_FOUND/TOKEN_NOT_IN_USE pour les arrêter.
Notification au marchand Les PSP devront communiquer l'état du jeton à leurs marchands.

Remarques sur l'implémentation

Le point de terminaison tokenUpdateUrl doit être transmis avec la transaction pour recevoir les mises à jour du jeton. Pour les PSP, il leur incombe de déterminer comment les marchands recevront et renseigneront cette URL dans l'objet *TransactionInfo concerné.

Notez également que la charge utile chiffrée renverra un champ facultatif supplémentaire, merchantTokenId, pour les MIT. Pour en savoir plus, consultez la documentation Cryptographie des données de paiement (pour les marchands) ou Structure de la charge utile (pour les PSP).