PaymentIntent
PaymentIntent
PaymentIntent
est utilisé pour représenter l’intention de collecter un paiement auprès d’un client. Il conserve une trace des frais et des différentes tentatives de paiement tout au long du traitement.
L’intention de paiement PaymentIntent
doit être créée sur le serveur du marchand avec un amount
, une currency
, la référence du client final et la référence de l’achat.
Créer une intention de paiement
id
est la référence unique de l’intention de paiement PaymentIntent
, il sera utilisé lors des tentatives de paiementtoken
est un JSON Web Token (JWT) qui sera utilisé pour authentifier les requêtes de paiementPaymentIntent
) créée, il sera possible de collecter les informations de paiement des client et de faire une tentative de Payment
.
Pour ce faire Payment
, vous devez spécifier une paymentMethod
ainsi que tout les champs requis décris dans la référence de notre api.
Tenter un paiement
Puisque ce point de terminaison ne nécessite pas de clé api privée API_KEY
, la requête de paiement peut être faite directement côté client en utilisant le JWT token
enregistré au préalable pour authentifier la requête.
HTTP 201
sera retourné avec le PaymentIntent
dans la réponse de la requête.
Constatez que le statut est maintenant processing
et que le tableau payments
contient la nouvelle tentative de paiement Payment
.
L’ID du paiement peut maintenant être enregistré pour identifier cette tentative de paiement dans la liste, puisque plus d’une tentative de paiement peut être effectuée pour une seule intention de paiement PaymentIntent
.
PaymentIntent
, il est recommandé d’utiliser les webhooks.
Veuillez regarder à la page Intégration webhooks pour voir comment les implémenter.
Souscrivez aux événements payment
ou payment_intents
.
En utilisant cette méthode, le serveur du marchand sera notifié dès que le Payment
ou le PaymentIntent
sera mis à jour.
De cette manière, l’implémentation de mécanismes de polling est inutile, les limites de flux ne sont pas subies, et une charge potentielle due à des problèmes de temps de réponse est ainsi évitée.
Aussi, en cas de trafic élevé, la charge sur les serveurs sera réduite en conséquence, tant du côté du marchand que de celui d’HUB2.
HTTP 429 - Too Many Requests
seront effectués dans ce cas. Il faut prendre cela en considération lors de l’implémentation du polling.PaymentIntent
.status
est processing
ou action_required
. Continuer le polling lors de statut payment_required
, successful
ou failed
peut conclure par l’adresse IP du marchand limitée ou temporairement bannie.PaymentIntent
sera action_required
. Ce statut indique que la tentative de paiement est en attente d’une action manuelle du client final, qui doit authentifier ou valider le paiement.
Payment
contiendra un objet nextAction
qui décrit le type d’action que le client final doit effectuer.
"nextAction": { "type": "otp", "message": "Mode Sandbox. Entrez un numéro à 4 chiffres pour authentifier le paiement." }
.nextAction.message
devrait maintenant être affiché au client final pour lui indiquer les actions à entreprendre afin de valider le paiement. L’action spécifie les étapes que le client doit suivre:
redirection
fournit les informations de redirection à une page externe.ussd
indique la procédure USSD à suivre pour valider le paiement.otp
indique à l’utilisateur comment générer un OTP. Ce type d’action nécessite que le client saisisse le code OTP dans un champ qui sera envoyé au point de terminaison api. Veuillez noter que certains fournisseurs permettent de passer le code OTP directement dans la requête de paiement (voir champ otp
dans l’objet mobileMoney
).PaymentIntent
) comme décrit précédemmentbank_transfer
comme méthode de paiementPaymentIntent
contenant les détails du paiement par virement, y compris la référence unique générée pour le virement.