Aller au contenu principal

Remboursement

Cette section décrit le fonctionnement du remboursement via l’API. Le remboursement est strictement encadré pour garantir la sécurité et la cohérence des flux financiers.

Qu’est-ce qu’un remboursement ?​

Un remboursement correspond à la restitution totale ou partielle d’un montant précédemment payé par un utilisateur. Il intervient généralement lorsqu’une commande est annulée, un service non rendu, ou dans le cadre d’un geste commercial.

Conditions pour effectuer un remboursement​

Un remboursement peut être initié uniquement si toutes les conditions suivantes sont remplies :

  1. Origine de la transaction Le remboursement doit concerner une transaction de type money-in, encaissée via la page de checkout.

  2. Transaction confirmée La transaction d'origine doit être au statut success. Une transaction encore en pending, en error ou annulée n'est pas remboursable.

  3. Moyen de paiement remboursable Les transactions issues d'un transfert P2P, d'un remboursement ou d'un retrait ne sont pas remboursables. Seuls les encaissements clients le sont.

  4. Montant du remboursement Le montant ne doit pas excéder le montant initial de la transaction, déduction faite des remboursements déjà effectués dessus. Il reste par ailleurs soumis aux bornes générales : minimum 300 MGA, maximum 20 000 000 MGA.

  5. Solde du portefeuille virtuel Le portefeuille débité doit disposer d'un solde suffisant pour couvrir le montant et les frais de remboursement, sorties en attente déduites.

  6. Remboursements partiels Vous pouvez enchaîner plusieurs remboursements partiels tant que le total cumulé reste inférieur ou égal au montant initial et que le solde le permet.

Portefeuille débité​

Par défaut, le remboursement est prélevé sur le portefeuille qui a encaissé la transaction. Vous pouvez en désigner un autre avec le champ debited_wallet_id, à condition qu'il appartienne au même compte.

Cycle de vie​

Un remboursement est créé en pending, avec une transaction money-out associée. Son statut évolue ensuite vers success ou error, et chaque étape émet un évènement (refund.create, refund.completed, refund.failed, refund.canceled) vers votre webhook.

Destination du webhook

Si la transaction d'origine a été créée par une application, les évènements de remboursement partent vers le webhook de cette application — même si le remboursement a été déclenché depuis le tableau de bord.

Points d’attention​

  • Frais : un remboursement génère des frais (plateforme + moyen de paiement) prélevés en plus du montant remboursé. Simulez-les avec POST /transaction/calc-fee.
  • Traçabilité : chaque remboursement crée une transaction consultable via l'API Transaction.
  • Asynchrone : la réponse 201 signifie « demande enregistrée », pas « fonds restitués ».