Aller au contenu principal
Tous les articles
Guide12 min de lecture

Paiement marketplace au Maroc : encaisser pour les vendeurs d'une place de marché

Paiement marketplace au Maroc : chaque vendeur devient un sous-marchand vérifié avec son wallet, une session par commande, l'argent identifié à l'encaissement.

Pour organiser le paiement marketplace au Maroc sans mêler l'argent de vos vendeurs, déclarez chaque vendeur comme sous-marchand : il est vérifié comme tout marchand, reçoit son propre wallet, et chaque commande payée sur votre plateforme devient une session de paiement qui désigne le wallet à créditer. L'argent de chacun est identifié dès l'encaissement, au lieu d'être démêlé après coup depuis un compte commun. Ce guide décrit le modèle de bout en bout — vérification des vendeurs, sessions, identification des fonds, collecte, reversements, remboursements —, son application aux plateformes de services, puis ce qu'il faut préparer avec l'équipe d'intégration.

Paiement marketplace au Maroc : pourquoi un pot commun complique tout

Le réflexe, quand on lance une place de marché, est d'encaisser toutes les ventes sur un seul compte — celui de la plateforme — puis de reverser à chaque vendeur ce qui lui revient. Au lancement, avec peu de vendeurs, un tableur suffit. Dès que le catalogue s'élargit, le pot commun devient une dette de travail :

  • retrouver, pour chaque paiement reçu, la commande et le vendeur auxquels il correspond ;
  • calculer ce qui est dû à chacun, période par période, en tenant compte des annulations ;
  • décider sur quel argent imputer un remboursement quand un client renvoie un article ;
  • expliquer à un vendeur pourquoi son reversement ne correspond pas à ce qu'il croit avoir vendu.

Chaque correction se fait a posteriori, à la main, et chaque erreur se paie en confiance perdue auprès des vendeurs — ceux-là mêmes qui font vivre votre catalogue. Le modèle de la distribution ChariPay prend le problème à l'envers : rien n'est mutualisé dans un pot commun. Chaque vendeur a son wallet, et la session de paiement de chaque commande désigne celui à créditer.

Encaisser l'argent d'autres commerçants soulève aussi une question de droit, que nous traitons à part : l'article encaisser pour le compte de tiers cite ce que dit la loi 103-12, et votre conseil reste seul à pouvoir se prononcer sur votre montage. Et si vous avez d'abord regardé du côté des outils étrangers pour places de marché, comme Stripe Connect, l'article Stripe au Maroc fait le point sur leur disponibilité ; ce guide-ci part d'une solution opérée au Maroc.

Le modèle : chaque vendeur est un sous-marchand vérifié, avec son wallet

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Son espace distribution s'adresse aux agrégateurs, franchises et réseaux d'agents. Une place de marché s'y décrit simplement : votre plateforme est le partenaire, et chaque vendeur devient un sous-marchand de votre espace distribution.

Ce que le modèle vous donne, concrètement :

  • Des vendeurs créés un par un ou par lot, chacun avec son wallet dédié.
  • Un KYC intégré : un sous-marchand est vérifié comme tout marchand — documents et registre de commerce — avant d'encaisser en production.
  • Des plafonds de solde, fixés wallet par wallet, avec une alerte quand un sous-marchand approche du sien.
  • Des encaissements qui suivent la répartition définie à la mise en place du partenariat ; rien n'est mutualisé dans un pot commun.

La vérification des vendeurs n'est donc pas une formalité que vous inventez : c'est le même parcours que pour tout marchand, intégré à l'outil. Un vendeur non encore vérifié peut figurer dans votre catalogue, mais il n'encaisse pas en production tant que sa vérification n'est pas validée. Prévoyez ce statut intermédiaire dans votre plateforme, plutôt que de le découvrir le jour où un client veut payer. L'offre complète est décrite sur la page distribution et sous-marchands.

Avant même le montage, vous pouvez voir ce que verront vos acheteurs : Commencer en mode test. Trois champs — nom, e-mail professionnel, entreprise —, un lien d'activation reçu par e-mail pour choisir votre mot de passe, puis le portail, où vous créez vous-même votre clé de test après une ré-authentification. Vous pouvez alors créer des sessions de paiement et les régler avec la carte de test sur le checkout hébergé, sans argent réel. C'est gratuit, sans limite de durée et sans validation à attendre : la vérification de votre entreprise (KYB) ne conditionne que le passage en production. L'espace distribution, lui, se prépare avec l'équipe d'intégration.

Une commande, une session, un wallet à créditer

Sur une place de marché, la session de paiement est l'unité de travail. Une commande devient une session : vous créez la session côté serveur, vous redirigez l'acheteur vers le checkout hébergé — carte avec 3-D Secure —, et vous recevez le résultat par webhook signé. Ce qui distingue cette session de celle d'un marchand classique tient dans un paramètre : config.settlement, qui désigne le wallet du sous-marchand à créditer.

Le parcours d'une commande, pas à pas :

  1. 1L'acheteur valide son panier chez un vendeur de votre plateforme.
  2. 2Votre serveur crée la session avec le montant, votre orderId, les coordonnées de l'acheteur et, dans config.settlement, l'identifiant du vendeur : walletId (l'identifiant de son wallet) ou subMerchantReference (sa référence de sous-marchand).
  3. 3L'acheteur est redirigé vers la page hébergée et paie par carte : le porteur confirme auprès de sa banque.
  4. 4Le paiement réussi est rattaché au vendeur désigné : c'est son wallet que la session crédite.
  5. 5Votre serveur reçoit le webhook signé ; vous confirmez la commande à ce moment-là.

Confirmez la commande sur réception du webhook, jamais sur la seule redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis. Chaque session a une durée de vie limitée — 72 heures par défaut, expiresAt pour la raccourcir — et n'est consommée qu'une seule fois.

Deux limites à connaître dès la conception. D'abord, une session n'encaisse que la carte ; les espèces en agence passent par un lien de paiement à usage unique, dont le rattachement au wallet d'un vendeur n'est pas décrit publiquement : seule une session désigne ce wallet, par config.settlement. Ensuite, nous ne publions pas de mécanisme pour répartir un paiement unique entre plusieurs vendeurs : le cas du panier qui réunit plusieurs vendeurs est une question à examiner au montage, avec l'équipe d'intégration. Le détail des appels, avec un exemple de requête, les erreurs et les événements à écouter, est dans sous-marchands par l'API.

L'argent de chaque vendeur identifié dès l'encaissement

Dans un pot commun, identifier l'argent est un travail de fin de mois. Ici, cela se fait à la transaction : les encaissements de chaque sous-marchand sont identifiés dès ce moment, chacun rattaché à son vendeur, et suivent la répartition définie à la mise en place du partenariat.

Côté système, deux repères vous permettent de rattacher chaque paiement à votre propre base :

  • votre metadata, un objet plat que vous joignez à la session — par exemple { "sellerId": "v_204", "orderNumber": "1042" } — et qui revient tel quel dans l'événement de paiement ;
  • votre orderId, que l'événement d'une session porte aussi.

Retrouvez donc votre commande par ces deux valeurs : l'externalId d'une session, lui, ne revient pas dans l'événement. Gardez dans votre metadata des identifiants techniques — vendeur, commande, panier — plutôt que des données personnelles de l'acheteur.

Ce que cela change au quotidien : quand un vendeur demande où en sont ses ventes, la réponse ne dépend plus d'un rapprochement manuel ; quand un client réclame au sujet d'une commande, vous savez immédiatement à quel vendeur elle appartient ; quand votre comptable clôture le mois, chaque mouvement porte déjà la référence qui l'explique.

Collecte, reversements et remboursements

Une fois l'argent identifié, il reste à le faire circuler. L'espace distribution fournit quatre briques :

BriqueCe qu'elle faitCe que vous y gagnez
Collecte automatiqueRassemble les fonds sur votre compte de collecte, chaque jour ou chaque semaineUne trésorerie centralisée sans geste quotidien
Reversements à double validationLe demandeur et l'approbateur sont toujours distinctsAucun reversement ne part sur la décision d'une seule personne
Campagnes de remboursement en masseRemboursent de nombreux clients dans une même campagneUne annulation d'ampleur traitée en bloc
Relevé mensuel par sous-marchandRetrace la seule activité de chaque vendeurUn justificatif propre à chaque vendeur

Les reversements suivent la règle des quatre yeux : celui qui demande n'est jamais celui qui approuve, et votre système est prévenu du résultat par webhook signé — payout.completed quand le reversement est exécuté, payout.failed quand il échoue. Désignez donc dès le départ, dans votre équipe, qui prépare et qui approuve.

Le pilotage de ces flux — choix de la fréquence de collecte, plafonds et alertes, reversements, rapprochement — est détaillé dans collecte et reversements d'un réseau.

Plateformes de services : le même modèle pour des prestataires

Une plateforme de services ne vend pas d'objets : elle met en relation des clients et des prestataires indépendants — réparations à domicile, cours, coaching, traduction, entretien. Le modèle est le même : chaque prestataire est déclaré comme sous-marchand, et l'argent de chacun est identifié dès l'encaissement, au lieu d'être démêlé a posteriori depuis un compte commun.

Prenez une plateforme qui met en relation des particuliers de Casablanca et de Rabat avec des entreprises de réparation à domicile. Le client réserve une intervention et paie sur le checkout hébergé ; la session désigne le wallet de l'entreprise retenue ; le metadata porte l'identifiant de l'intervention. Le jour où une entreprise demande le détail de ses encaissements, son relevé mensuel ne retrace que sa propre activité.

Trois points d'attention propres aux services :

  • L'éligibilité des prestataires : chacun est vérifié comme tout marchand — documents et registre de commerce — avant d'encaisser en production. Vérifiez dès le recrutement qu'ils peuvent fournir ces pièces.
  • Le moment du paiement : une session vit 72 heures par défaut. Faites payer à la réservation plutôt qu'après l'intervention, et raccourcissez expiresAt si le créneau doit être libéré plus tôt.
  • Les annulations en série : si une journée entière d'interventions est annulée, les campagnes de remboursement en masse évitent de traiter chaque client à la main.

La mise en place avec l'équipe d'intégration

Le montage d'une place de marché se prépare avec l'équipe d'intégration : c'est là que se définissent la répartition, les plafonds, la fréquence de collecte et les approbateurs. Pour arriver avec un dossier exploitable, rassemblez :

  • la liste de vos vendeurs et, pour chacun, ses documents et son registre de commerce ;
  • l'endroit de votre parcours de commande où votre serveur créera la session ;
  • les identifiants de vendeur et de commande que vous mettrez dans le metadata ;
  • l'URL HTTPS publique de votre endpoint de webhooks ;
  • les personnes qui demanderont et celles qui approuveront les reversements — jamais les mêmes ;
  • la fréquence de collecte que vous visez, quotidienne ou hebdomadaire.

Le passage en production suit le parcours de tout marchand : une fois le KYB validé — documents d'identité et registre de commerce, avec double validation humaine —, votre dossier est étudié et vous recevez une proposition chiffrée. Côté code, vous ne changez que la clé et le secret de webhook : les URL, les payloads et les codes d'erreur sont identiques à ceux du mode test. Pour ouvrir la discussion sur votre place de marché : contacter l'équipe.

Questions fréquentes

Comment encaisser pour plusieurs vendeurs sur une place de marché au Maroc ?

En déclarant chaque vendeur comme sous-marchand, vérifié comme tout marchand et doté de son propre wallet. Chaque commande devient une session de paiement créée par votre serveur, dont le paramètre config.settlement désigne le wallet du vendeur à créditer. L'acheteur paie par carte sur le checkout hébergé, et l'argent de chaque vendeur est identifié dès l'encaissement, sans pot commun à redistribuer.

Chaque vendeur doit-il être vérifié avant de vendre ?

Oui : un sous-marchand est vérifié comme tout marchand — documents et registre de commerce — avant d'encaisser en production. Le KYC est intégré à l'espace distribution et nous ne publions pas de durée. L'événement wallet.activated vous signale l'activation d'un wallet, wallet.rejected un refus : prévoyez un statut « en vérification » dans votre plateforme et branchez-le sur ces deux événements.

Peut-on ajouter des vendeurs en masse ?

Oui : les sous-marchands se créent un par un ou par lot, chacun avec son wallet dédié. L'ajout par lot sert au lancement, quand vous reprenez une base de vendeurs existante ; l'ajout unitaire sert ensuite, au fil des inscriptions. Dans les deux cas, chaque vendeur passe la même vérification avant d'encaisser en production.

Comment l'acheteur paie-t-il sa commande ?

Par carte, sur le checkout hébergé par ChariPay, avec 3-D Secure : le porteur confirme auprès de sa banque. Par défaut, Visa, Mastercard et Maroc Pay sont acceptés. Votre serveur crée la session, redirige l'acheteur, puis confirme la commande à réception du webhook signé. Une session n'encaisse que la carte ; les espèces en agence passent par un autre outil, le lien de paiement à usage unique.

Quel justificatif chaque vendeur reçoit-il ?

Son justificatif est le relevé mensuel établi pour chaque sous-marchand : il ne retrace que sa propre activité. Côté plateforme, l'argent de chaque vendeur est identifié dès l'encaissement, sans pot commun à démêler en fin de mois. Pour vos propres rapprochements, votre metadata — identifiant de vendeur, numéro de commande — revient tel quel dans l'événement de paiement.

Faut-il un développeur pour connecter une place de marché ?

Oui, pour la partie paiement : la session qui désigne le wallet du vendeur se crée côté serveur, par l'API, et les résultats arrivent par webhook signé sur un endpoint que vous déclarez. Le montage d'ensemble — vendeurs, répartition, approbateurs — se prépare avec l'équipe d'intégration, et le mode test permet de développer les sessions sans argent réel.

Une plateforme de services peut-elle appliquer le même modèle à ses prestataires ?

Oui : une plateforme qui met en relation clients et prestataires déclare chaque prestataire comme sous-marchand, et l'argent de chacun est identifié dès l'encaissement, au lieu d'être démêlé a posteriori depuis un compte commun. Chaque prestataire est vérifié comme tout marchand — documents et registre de commerce — avant d'encaisser en production : assurez-vous en amont qu'il peut fournir ces pièces.

Prochaine étape

Commencez par l'expérience de vos acheteurs : Commencer en mode test, créez une session et réglez-la avec la carte de test. Préparez ensuite le montage de votre place de marché — vendeurs, plafonds, fréquence de collecte, approbateurs — en vous appuyant sur la page distribution et sous-marchands. Pour passer à la mise en place : contacter l'équipe.

Écrit par Équipe ChariPay.

À lire ensuite

Prêt à essayer par vous-même ?

Créez votre compte et encaissez en mode test dès aujourd'hui : c'est gratuit, sans validation à attendre. Une question ? Notre équipe répond aux commerçants comme aux développeurs.

  • Gratuit, sans engagement
  • Mode test dès l'inscription
  • Aucune validation à attendre