Fonctionnement de l'API

​

Les APIs HUB2

Les APIs Pay-in & Pay-out développées par Hub2 sont différentes dans leur mode de fonctionnement.

​

API Pay-out

L’API Pay-out (transferts) permet de transférer des fonds à un tiers : la transaction est de type débit.

Les fonds sont automatiquement envoyés au destinataire sans nécessiter d’interaction de sa part.

Le compte de transfert doit être provisionné au préalable pour pouvoir effectuer des transferts sur l’API Hub2. Avant de procéder au transfert, Hub2 vérifie si le marchand possède les fonds nécessaires et les réserve le temps que l’opérateur confirme le transfert effectif des fonds au destinataire.

​

API Pay-in

L’API Pay-in (paiements) permet la collecte de fonds provenant d’un tiers (client final) : la transaction est de type crédit.

L’interaction du client est nécessaire ici, puisqu’il doit, selon le cas :

• confirmer la transaction avec son opérateur, lors de la réception d’un message PUSH ou de l’exécution d’un code USSD
• au préalable, générer un code d’authentification auprès de l’opérateur, à fournir au moment du paiement

Après avoir authentifié la transaction, le montant de la transaction est crédité sur le compte de collecte du marchand.

​

Comptes

Comme mentionné ci-dessus, les pay-ins (paiements) et les pay-outs (transferts) utilisent des comptes distincts. Tous les paiements en succès sont crédités sur le compte de collecte et tous les transferts en succès sont déduits du compte de transfert.

Important : Comme les transactions peuvent exister dans un environnement live ou sandbox, les comptes de collecte et de transfert existent également dans les deux environnements. Par conséquent, une transaction créée dans un environnement sandbox n’affectera que le compte sandbox et donc le solde sandbox. Il en va de même pour l’environnement live.

​

Asynchronicité

Toutes les transactions créées sur l’API Hub2, à l’exception des transactions créées sur le circuit synchrone, sont traités de façon asynchrone.

Une fois acceptée, les paramètres d’une requête de transaction sont enregistrés dans une pile de transactions à traiter et sont traitées dans un second temps par les autres composants de l’infrastructure Hub2.

Ce mode de fonctionnement a plusieurs avantages et notamment, il permet de répondre très rapidement à l’émetteur de la requête HTTP, diminuant ainsi le temps dédié à l’attente, côté plateforme marchand, réduisant ainsi sa charge.

​

Circuits

​

Circuit asynchrone

Toutes les transactions initiées dans ce circuit sont traitées de manière asynchrone par l’API Hub2. C’est le mode de fonctionnement par défaut des opérateurs, qui ne répondent pas directement aux requêtes de transaction mais les placent en attente de traitement. Les transactions sont ensuite mises à jour une fois traitées.

Le délai de traitement d’une transaction par un opérateur peut varier d’un opérateur à un autre.

La mise à jour du statut d’une transaction vers un état final chez Hub2 dépend donc de la mise à jour du statut de la transaction chez l’opérateur.

Une fois qu’un état final est attribué à une transaction, la mise à jour chez Hub2 peut être effectuée de deux manières :

• soit par une notification instantanée de paiement envoyée par l’opérateur
• soit par une interrogation régulière du statut de la transaction par Hub2 chez l’opérateur

​

Circuit synchrone

Certains opérateurs offrent la possibilité, soit par défaut, soit en tant que circuit supplémentaire, de fonctionner de manière synchrone. Dans ce mode de fonctionnement, la requête de transaction est traitée immédiatement au moment de son appel, sans être placée dans une pile de transactions à traiter ultérieurement.

Le statut final d’une transaction est obtenu directement lors de la réponse de l’opérateur, bien qu’un délai non-négligeable puisse survenir entre l’envoi de la requête par Hub2 et la réponse de l’opérateur.

Les fournisseurs pour lesquels le circuit synchrone est disponible sont les suivants :

• Wave (tous les pays)