Skip to main content
La collecte d’un paiement se déroule en cinq étapes :
  1. Créer une intention de paiement (PaymentIntent).
  2. Effectuer une tentative de paiement.
  3. (Optionnel) Côté client, authentifier la tentative de paiement.
  4. HUB2 traite le paiement auprès du fournisseur.
  5. Récupérer le statut de l’intention de paiement (PaymentIntent).

Créer une intention de paiement

L’objet PaymentIntent représente l’intention de collecter un paiement auprès d’un client. Il conserve la trace des frais et de chaque tentative de paiement tout au long du traitement. L’intention de paiement doit être créée sur le serveur du marchand avec un montant (amount), une devise (currency), la référence du client final (customerReference) et la référence de l’achat (purchaseReference). Créer une intention de paiement Exemple de requête :
Conservez l’id et le token renvoyés dans la réponse côté marchand : ils sont nécessaires aux étapes suivantes.
  • L’id est la référence unique de l’intention de paiement. Il sert lors des tentatives de paiement.
  • Le token est un JSON Web Token (JWT) qui authentifie les requêtes de paiement. Il expire 30 minutes après la création de l’intention de paiement : une tentative de paiement ou une authentification envoyée avec un jeton expiré est refusée avec une erreur 401 (bad_payment_intent_token).

Tentative de paiement sur une intention de paiement

Une fois l’intention de paiement créée, collectez les informations de paiement auprès du client final et effectuez une tentative de paiement (Payment). Pour cela, indiquez la méthode de paiement (paymentMethod) ainsi que tous les champs requis décrits dans la référence de l’API. Tenter un paiement Ce point de terminaison accepte le jeton JWT (token) à la place de votre clé API privée : la requête de paiement peut donc être envoyée directement côté client (par l’application du client), avec le token récupéré précédemment.
Si la requête réussit, l’API renvoie un code HTTP 201 avec l’objet PaymentIntent complet dans le corps de la réponse. Le statut est désormais processing et le tableau payments contient la nouvelle tentative de paiement. Enregistrez l’id du paiement pour identifier cette tentative dans la liste : plusieurs tentatives de paiement peuvent être effectuées sur une seule intention de paiement.

Récupérer le statut du paiement

Après une tentative de paiement, HUB2 contacte le fournisseur et met à jour l’objet de paiement selon sa réponse. À partir de là, le statut du paiement peut être récupéré de deux façons.

1. Enregistrer un webhook pour les événements de paiement (méthode recommandée)

Utilisez les webhooks plutôt que d’interroger régulièrement (polling) le PaymentIntent pour détecter un changement de statut. Consultez la page Intégration des webhooks pour les mettre en place. Abonnez-vous aux événements payment.* ou payment_intent.*. Avec cette méthode, le serveur du marchand est notifié dès que le Payment ou le PaymentIntent est mis à jour. Aucun mécanisme de polling n’est alors nécessaire, aucune limite de débit ne s’applique et les problèmes de latence sont évités. En cas de trafic élevé, la charge est aussi réduite, tant sur les serveurs du marchand que sur ceux de HUB2.

2. Polling du statut

Interrogez le statut du paiement avec le point de terminaison dédié. Récupérer le statut d’un paiement
Ce point de terminaison est soumis à une limite de débit (5 requêtes par tranche de 5 secondes pour un même paiement) afin de prévenir les attaques par déni de service. Au-delà, l’API renvoie HTTP 429 - Too Many Requests. Tenez-en compte lors de l’implémentation du polling.
Exemple de requête :
Cette requête renvoie le statut d’un paiement. Un autre point de terminaison renvoie le statut d’une intention de paiement. Récupérer le statut d’une intention de paiement

Important

N’interrogez le statut que tant que PaymentIntent.status vaut processing ou action_required. Interroger en continu une intention de paiement au statut payment_required, successful, failed ou canceled entraîne la limitation, voire le bannissement temporaire, de l’adresse IP source.
Dans la plupart des cas, le statut suivant du PaymentIntent est action_required. Ce statut indique que le client final doit effectuer une action manuelle pour authentifier ou valider le paiement.

Gérer l’action du client

L’objet Payment contient un objet nextAction qui décrit l’action attendue du client final.

Important

La partie utile est la suivante : "nextAction": { "type": "otp", "message": "Mode Sandbox : Entrez un numéro à 4 chiffres pour authentifier le paiement." }.
Affichez nextAction.message au client final pour lui indiquer comment valider le paiement. Le type d’action est l’un des suivants :
  • redirection : fournit les informations nécessaires pour rediriger le client vers une page externe.
  • ussd : indique la procédure USSD à suivre pour valider le paiement.
  • otp : indique au client comment générer un code à usage unique (OTP). Le client saisit l’OTP dans un champ, que vous envoyez au point de terminaison dédié. Certains fournisseurs acceptent l’OTP directement dans la requête de tentative de paiement (voir le champ otp de l’objet mobileMoney).

Paiement par virement (bank collection)

La fonctionnalité de paiement par virement permet à un marchand de proposer à ses clients une option de paiement par virement bancaire. Le client reçoit une référence unique pour effectuer le virement.

Prérequis

Ce moyen de paiement nécessite un enregistrement KYB (Know Your Business) préalable. Effectuer une déclaration KYB

Processus de paiement

  1. Le marchand crée une intention de paiement (PaymentIntent) comme décrit plus haut.
  2. Pour la tentative de paiement, le marchand indique bank_transfer comme méthode de paiement et fournit l’objet bankTransfer :
    • kybName (obligatoire) : le nom déclaré lors de l’enregistrement KYB.
    • expirationDelay (facultatif) : nombre de secondes avant l’expiration du paiement. Minimum 3600, valeur par défaut 1296000 (15 jours).
  3. HUB2 génère une référence unique pour le virement.
  4. Le client reçoit cette référence et effectue le virement.
  5. Le statut du paiement est mis à jour une fois le virement reçu. Si aucun virement n’est reçu avant la fin du délai d’expiration, le paiement échoue avec le motif expired.
Tenter un paiement

Réponse de l’API

En cas de succès, l’API renvoie un objet PaymentIntent contenant les détails du paiement par virement, y compris la référence unique générée pour le virement.
Important : communiquez la référence au client final pour qu’il puisse effectuer le virement. Le statut du paiement est mis à jour une fois le virement reçu et traité.