Payer les vendeurs

La façon dont un vendeur reçoit son argent dépend du mode de la connexion. Un marchand direct pilote son propre compte et retire lui-même : rien sur cette page ne le concerne. Un marchand lite n'a pas de dashboard pour retirer, c'est donc Wajub qui le paie. Une marketplace relay encaisse tout et paie ses vendeurs depuis son propre solde.

Lite : Wajub paie le marchand

Un marchand Lite est payé au rythme que vous fixez sur la connexion. Chaque versement est un balayage : ce qui est disponible sur son solde, moins la réserve, moins la place des frais du versement.

Définissez-le avec POST /accounts ou PUT /accounts/{id} à tout moment. Contrairement aux capacités et à la tarification, il change directement : le moment où un marchand reçoit son propre argent ne lui retire rien. Il n'existe que sur un compte lite — l'envoyer pour un compte direct ou relay est refusé avec 400, puisque Wajub n'y paie personne.

curl -X POST https://api.wajub.com/accounts/acc_7Yh2MpL4tRb3nP8sZcXv/payouts \
  -H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…"

Une connexion est balayée au plus une fois par jour, quel que soit le demandeur. Un second appel le même jour renvoie le versement déjà parti. Le montant n'est jamais le vôtre à choisir : c'est ce que le marchand peut recevoir.

Chaque versement part vers la destination que le marchand a déclarée dans son portail, et passe les mêmes contrôles que n'importe quel virement — y compris le délai de carence d'une destination tout juste déclarée ou modifiée.

La réserve

Un marchand Lite est payé sans rien demander : l'argent peut donc partir alors que l'acheteur peut encore être remboursé. La réserve retient une part de chaque vente jusqu'à ce que cette fenêtre se ferme : 10 % pendant 30 jours par défaut.

La réserve n'est ni un prélèvement ni un solde à part. L'argent reste celui du marchand ; la réserve dit seulement quelle part ne peut pas encore sortir. Le taux et la durée sont fixés par Wajub pour une connexion, pas par la plateforme.

Quand un marchand passe en négatif

Si un remboursement arrive après qu'un marchand a été payé et que la réserve ne suffit pas, son solde passe sous zéro. C'est vous qui couvrez. Le manque passe de votre solde à celui du marchand, au moment même où le remboursement est traité, et est enregistré contre ce remboursement.

Quand votre commission ne peut pas être prélevée tout de suite

Un marchand direct peut encaisser sur ses propres contrats de prestataire. Ces ventes ne passent jamais par un solde Wajub : il n'y a donc rien sur quoi prélever votre commission au moment de la vente. Elle devient une créance :

Le prélèvement ne fait jamais passer le marchand sous zéro : une commission impayée attend que l'argent arrive. GET /accounts/{id}/commission-receivables liste ce qu'une connexion vous doit et totalise ce qui reste à percevoir.

Relay : payer beaucoup de vendeurs d'un coup

Une marketplace Relay encaisse tous les paiements et paie ses vendeurs depuis son propre solde. Chaque vendeur est un bénéficiaire, et une campagne de versements tient en un appel.

curl -X POST https://api.wajub.com/transfers/batch \
  -H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -H "Idempotency-Key: payout-run-2026-09-30" \
  -H "Content-Type: application/json" \
  -d '{
    "transfers": [
      { "beneficiary": "ben_01JX…", "amount": 125000, "reference": "seller-42" },
      { "beneficiary": "ben_01JY…", "amount": 48000, "reference": "seller-43" }
    ]
  }'

La réponse liste chaque ligne avec accepted ou rejected et le motif. Chaque virement garde votre reference et le batch_reference de la campagne : c'est ce qui le relie à vos propres données.

Les vendeurs sont vérifiés avant leur premier versement

Wajub paie des vendeurs que vous avez recrutés : sur un compte Relay, le portefeuille de chaque nouveau bénéficiaire est donc comparé au nom que l'opérateur a enregistré, avant tout versement. Déclarez le nom complet du vendeur tel qu'il figure sur son portefeuille : au moins deux mots doivent correspondre.

verified vaut true ou false sur chaque bénéficiaire que vous lisez. Relancez une vérification avec POST /beneficiaries/{id}/verify — après une indisponibilité de l'opérateur, ou une fois le nom corrigé. Dans un lot, une ligne qui paie un vendeur non vérifié est refusée seule, et le reste du lot passe.

Quand un vendeur payé doit rendre de l'argent

Une vente est remboursée après que vous en avez payé le vendeur. Le remboursement sort de votre solde, et personne ne peut reprendre de l'argent sur un portefeuille Mobile Money : le vendeur vous le doit donc. Vous seul savez à quel vendeur appartenait la commande, c'est donc vous qui déclarez la dette :

curl -X POST https://api.wajub.com/beneficiaries/ben_01JX…/receivables \
  -H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 12500, "reference": "order-9981-refund" }'

Déclarer à nouveau la même reference renvoie la première dette. Wajub l'enregistre et envoie beneficiary.receivable_recorded. La suite dépend de votre compte :

Avec la compensation activée, chaque ligne du lot indique recovered. Une ligne dont le versement est inférieur à la dette n'envoie rien, répond status: recovered, et le reste reste dû. La compensation ne joue que dans POST /transfers/batch ; un POST /transfers seul envoie toujours ce que vous demandez. Demandez à Wajub d'activer la compensation pour votre compte.

Relevés

GET /beneficiaries/{id}/statement?from=2026-09-01&to=2026-09-30 renvoie tout ce qui a été versé à un vendeur sur une période, jusqu'à un an. Les totaux sont répartis entre paid, in_progress et failed : un versement échoué figure sur le relevé, mais n'est jamais compté comme payé.