Marketplace : paiements, commissions et remboursements avant le code

Sur une boutique classique, le flux paraît simple : un client paie, le marchand reçoit l’argent, la commande part. Une marketplace ajoute au moins un vendeur, une commission et une question structurante : qui encaisse pour le compte de qui ?

Cette question influence les écrans d’inscription, le contrat avec les vendeurs, le relevé bancaire de l’acheteur, la date des versements, les remboursements, les litiges, la comptabilité et la responsabilité fiscale. Si elle arrive après les maquettes, une partie du produit est déjà dessinée autour d’une hypothèse invisible.

Stripe Connect et les solutions comparables rendent les mouvements d’argent techniquement accessibles. Elles ne choisissent pas votre modèle économique à votre place. Le bon flux dépend du nombre de vendeurs par panier, de la prestation vendue, du moment où elle est considérée comme réalisée et de la personne qui porte la relation commerciale.

En résumé : avant de coder, dessinez le trajet de 100 € depuis l’acheteur jusqu’au vendeur, puis dessinez les trajets inverses en cas d’annulation, remboursement et litige. Définissez qui vend, qui facture, qui paie les frais, quand la commission est acquise et qui supporte un solde négatif. Ensuite seulement, choisissez le type de paiement et l’onboarding technique adaptés.

Une marketplace n’est pas une boutique avec plusieurs catalogues

La différence n’est pas visuelle. Elle tient au nombre de parties dans la transaction.

• L’acheteur choisit, paie et peut demander assistance ou remboursement.
• Le vendeur ou prestataire fournit le bien ou le service et attend son versement.
• La plateforme organise la rencontre, définit des règles, perçoit éventuellement une commission et arbitre certains incidents.
• Le prestataire de paiement encaisse, vérifie les acteurs, déplace les fonds et applique les contraintes des réseaux financiers.

Selon votre modèle, la plateforme peut être simple intermédiaire ou assumer une part beaucoup plus grande de la vente. Ce n’est pas une étiquette marketing. Les contrats, factures, taxes, obligations d’information et responsabilités doivent être validés avec des professionnels du droit et de la comptabilité qui connaissent votre activité et les pays concernés.

La technique doit refléter cette décision, pas la contourner. Un développeur peut configurer un flux ; il ne peut pas transformer par code un vendeur juridiquement responsable en simple bénéficiaire invisible.

Commencez par le schéma des 100 €

Prenez un exemple volontairement concret : un client paie 100 € pour une prestation vendue sur votre plateforme. Écrivez chaque montant :

• prix payé par le client : 100 € ;
• taxe incluse ou ajoutée : selon le modèle ;
• frais du prestataire de paiement : qui les supporte ?
• commission de la plateforme : montant fixe, pourcentage ou combinaison ;
• part du vendeur : quand devient-elle disponible ?
• éventuels frais de service côté acheteur ;
• réserve ou retenue prévue par les conditions ;
• montant finalement versé.

Puis rejouez le même dessin dans six scénarios :

1. le paiement échoue ;
2. le client annule avant exécution ;
3. le vendeur annule ;
4. un remboursement partiel est accordé ;
5. le client conteste le paiement ;
6. le vendeur a déjà reçu les fonds quand le remboursement survient.

Si l’équipe ne sait pas où reprendre les 100 € dans le dernier cas, le modèle n’est pas cadré. Le problème apparaîtra tôt ou tard, mais cette fois avec de vrais soldes.

Qui apparaît comme vendeur aux yeux du client ?

Le client doit comprendre à qui il achète, qui le débite et qui répond en cas de problème. Le libellé présent sur son relevé bancaire participe à cette clarté. S’il ne reconnaît ni la plateforme ni le vendeur, il peut croire à une fraude et contester le paiement.

Décidez :

• le nom affiché au checkout ;
• l’entité mentionnée sur la confirmation ;
• l’émetteur de la facture ;
• le libellé bancaire ;
• le contact support ;
• la personne qui décide un remboursement ;
• les conditions applicables à la vente.

Ces éléments doivent raconter la même relation. Une page qui promet « achetez auprès de nos artisans » tandis que tous les documents présentent la plateforme comme vendeur crée une ambiguïté commerciale et comptable.

Dans une plateforme e-commerce sur mesure, le parcours, les documents et les flux techniques sont conçus ensemble précisément pour éviter ce décalage.

Un vendeur doit devenir un compte de paiement

Vous ne pouvez pas simplement collecter un IBAN dans votre base et envoyer de l’argent. Le prestataire de paiement doit connaître le bénéficiaire, vérifier son identité ou son entreprise et s’assurer qu’il est autorisé à recevoir des fonds. C’est le principe des contrôles de connaissance client, souvent regroupés sous l’acronyme KYC.

Le vendeur devra fournir selon sa situation et son pays des informations sur sa structure, ses représentants, son activité et son compte bancaire. Certaines pièces peuvent être demandées immédiatement, d’autres plus tard. Les exigences évoluent avec la réglementation et le niveau d’activité.

L’onboarding vendeur doit donc gérer plusieurs états :

• inscription commencée ;
• informations manquantes ;
• vérification en cours ;
• capacité à encaisser active ou inactive ;
• versements autorisés ou bloqués ;
• nouvelle information demandée ;
• compte suspendu ou à corriger.

Ne traduisez pas tout par « compte créé ». Un vendeur peut accéder à son catalogue mais ne pas encore pouvoir recevoir de paiement. L’interface doit expliquer l’étape, proposer l’action correcte et empêcher une mise en vente incohérente avec votre politique.

Héberger soi-même le KYC est rarement une bonne idée

Stripe propose des parcours d’onboarding hébergés ou intégrés qui déterminent les informations nécessaires, valident les données et collectent les documents. Les utiliser réduit la quantité de données sensibles que votre plateforme manipule et suit automatiquement davantage d’évolutions réglementaires. C’est une application très concrète du principe expliqué dans notre guide RGPD sans migraine : ne collecter et ne conserver que ce dont le service a réellement besoin.

Un formulaire entièrement personnalisé donne plus de contrôle visuel, mais transfère aussi plus de maintenance : nouveaux champs, pays, types d’entreprise, exigences futures, erreurs de vérification. Ce travail n’apporte généralement aucune différence métier visible à l’acheteur.

La bonne personnalisation se situe autour du parcours : expliquer pourquoi les informations sont demandées, montrer la progression, sauvegarder les étapes, relancer avec mesure et ramener le vendeur sur l’action précise. La collecte réglementaire elle-même gagne souvent à rester gérée par le spécialiste.

Écoutez les événements de mise à jour des comptes. Un vendeur valide aujourd’hui peut recevoir une nouvelle exigence demain ; votre plateforme doit le prévenir avant que paiements ou versements soient bloqués.

Un vendeur par paiement : le flux le plus lisible

Quand chaque commande concerne un seul vendeur, un paiement avec destination permet généralement à la plateforme d’encaisser côté client puis d’affecter la part prévue au compte connecté. La commission peut être prélevée dans le même mouvement.

Ce modèle convient par exemple à :

• une réservation avec un seul professionnel ;
• une course avec un seul conducteur ;
• une commande passée dans une seule boutique ;
• une prestation réalisée par un seul expert.

Il faut toujours décider qui supporte les frais, remboursements et contestations. Dans les flux marketplace où la charge est créée au niveau de la plateforme, le solde de la plateforme est souvent directement exposé aux frais et retours. La commission ne doit donc pas être calculée comme si aucun incident ne pouvait survenir.

Gardez une référence commune entre paiement, commande, vendeur et transfert. Le support doit pouvoir reconstruire le trajet sans ouvrir plusieurs tableaux de bord.

Plusieurs vendeurs dans un panier : le problème change

Un panier de 100 € peut contenir 60 € chez un vendeur et 40 € chez un autre. Il faut alors séparer le paiement client des transferts vers les bénéficiaires. Stripe Connect prévoit le modèle de charges séparées et transferts pour répartir un paiement entre plusieurs comptes, ou différer l’affectation.

Cette souplesse ajoute des décisions :

• la commission se calcule-t-elle par ligne, vendeur ou commande ?
• les frais de port appartiennent-ils à chaque vendeur ou à la plateforme ?
• une remise plateforme réduit-elle la part du vendeur ?
• une remise vendeur réduit-elle la commission ?
• quand transfère-t-on chaque part ?
• que se passe-t-il si un seul vendeur annule ?
• comment répartir un remboursement de frais communs ?

Le modèle de données doit conserver la ventilation d’origine. Ne stockez pas seulement « total 100 €, commission 15 € ». Conservez les lignes, vendeurs, taxes, remises, frais, commissions et transferts associés. Sans ce détail, un remboursement partiel devient un calcul manuel et le rapprochement comptable une enquête.

Le versement n’est pas le transfert

Il faut distinguer deux mouvements. Le transfert déplace une part du solde de la plateforme vers le solde du compte connecté. Le versement envoie ensuite l’argent disponible de ce compte vers le compte bancaire du vendeur selon son calendrier.

Pour l’utilisateur, tout ressemble à « quand serai-je payé ? ». Votre interface doit pourtant afficher des états précis :

• paiement client confirmé ;
• fonds en cours de disponibilité ;
• part affectée au vendeur ;
• versement programmé ;
• versement envoyé ;
• versement échoué.

Évitez de promettre un jour exact si le prestataire peut appliquer des délais bancaires, contrôles ou réserves. Donnez une estimation, le montant concerné et la raison d’un blocage.

Ne présentez pas non plus un simple décalage de transfert comme un service d’entiercement réglementé. Retenir ou différer des fonds obéit au cadre du prestataire et à votre contrat ; le vocabulaire commercial doit rester exact.

Quand la commission est-elle réellement acquise ?

Une commission prélevée au paiement peut devoir être restituée si la commande est intégralement remboursée. Pour un remboursement partiel, plusieurs politiques sont possibles :

• commission remboursée au prorata ;
• part fixe conservée, part variable remboursée ;
• commission conservée si le vendeur est responsable ;
• frais de service acheteur non remboursables dans certains cadres explicitement acceptés.

La décision doit être commerciale, contractuelle et techniquement calculable. Écrivez des exemples chiffrés dans les conditions vendeurs et dans les tests.

Votre marge réelle n’est pas seulement le pourcentage affiché. Elle doit absorber :

• frais de paiement ;
• coût des remboursements et litiges selon le modèle choisi ;
• support acheteurs et vendeurs ;
• fraude ;
• échecs de versement ;
• promotions financées par la plateforme ;
• taxes applicables à votre propre service ;
• coût d’exploitation du produit.

L’article e-commerce : arrêtez de payer un loyer sur vos ventes critique les coûts subis d’une plateforme tierce. Si vous construisez votre propre marketplace, la transparence doit s’appliquer à vous aussi : vos vendeurs doivent comprendre chaque retenue et ce qu’elle finance.

Rembourser un paiement simple

Le bouton « rembourser » doit demander plus qu’un montant. Qui est responsable ? Quelle part de commission restituer ? Le transfert vendeur doit-il être inversé ? Les frais de port sont-ils inclus ? Le vendeur possède-t-il encore un solde suffisant ?

Conservez :

• le motif ;
• l’auteur de la décision ;
• les lignes concernées ;
• la part client remboursée ;
• la commission rendue ou conservée ;
• le transfert repris au vendeur ;
• les frais absorbés par la plateforme ;
• les identifiants du prestataire de paiement.

Un remboursement peut réussir côté paiement et échouer dans votre mise à jour interne, ou l’inverse. Utilisez une opération idempotente et des événements pour réconcilier l’état final. Le client ne doit jamais recevoir deux remboursements parce qu’un administrateur a cliqué deux fois après une page lente.

Remboursement partiel et panier multi-vendeurs

Le cas difficile n’est pas « rendre 20 € ». C’est savoir à quoi correspondent les 20 €.

Imaginez une commande avec deux vendeurs, une remise globale, deux frais de livraison et une commission différente par catégorie. Une ligne du vendeur A est retournée. Le remboursement doit redistribuer ou conserver chaque composant selon les règles initiales.

La méthode robuste consiste à calculer et enregistrer l’allocation au moment de la commande. Chaque ligne connaît :

• son prix brut ;
• sa remise ;
• sa taxe ;
• ses frais ;
• la commission plateforme ;
• la part vendeur ;
• le transfert correspondant.

Le remboursement sélectionne les allocations à inverser, totalement ou au prorata. Il ne tente pas de reconstituer six mois plus tard une promotion qui n’existe plus.

Testez aussi les arrondis. Répartir 10 € sur trois bénéficiaires produit des centimes restants. Définissez une règle stable et assurez-vous que la somme des parts égale toujours le montant encaissé.

Litige bancaire : le remboursement que vous ne décidez pas

Une contestation survient quand le titulaire demande à sa banque d’annuler le paiement. Les fonds peuvent être débités pendant l’instruction et des preuves doivent être fournies dans un délai donné. Selon le type de charge, la plateforme ou le compte connecté porte directement le débit et les frais.

Votre produit doit savoir :

• recevoir l’événement de litige ;
• geler les actions incompatibles avec son traitement ;
• retrouver commande, vendeur, livraison et échanges ;
• rassembler les preuves pertinentes ;
• respecter le délai de réponse ;
• enregistrer l’issue ;
• appliquer la répartition financière prévue.

Décidez contractuellement qui supporte la perte selon la cause : fraude au paiement, prestation non réalisée, produit non conforme, erreur de la plateforme. Prélever automatiquement un vendeur sans règle claire crée un conflit au pire moment.

La prévention commence avant le litige : libellé bancaire reconnaissable, confirmation détaillée, preuve de livraison, conditions visibles, support joignable et remboursement simple quand il est légitime.

Le solde négatif n’est pas un cas théorique

Si un vendeur a reçu 80 € puis qu’un remboursement ou un litige reprend 100 €, son compte peut ne plus contenir assez d’argent. Qui couvre la différence en attendant de futurs revenus ou un recouvrement ?

Définissez :

• la responsabilité financière selon le flux de paiement ;
• le droit de compenser sur les ventes futures ;
• un seuil de réserve pour les activités risquées ;
• les conditions de suspension ;
• le traitement d’un vendeur qui quitte la plateforme ;
• la visibilité du solde et des mouvements.

Votre plateforme doit elle-même conserver une marge de trésorerie adaptée aux retours possibles. Un tableau de chiffre d’affaires ne montre pas l’argent réellement acquis si les délais de remboursement et de contestation sont encore ouverts.

Taxes et factures : décider qui doit quoi

Une marketplace génère au minimum deux relations économiques : vente au client et service de plateforme au vendeur. Selon le modèle, le pays et la nature des biens ou services, l’entité responsable de collecter et déclarer les taxes peut varier.

La solution de paiement peut calculer ou fournir des rapports, mais la première étape reste de déterminer qui est redevable. Faites valider :

• l’entité qui vend au client ;
• l’émetteur de la facture client ;
• la facture ou note de commission de la plateforme ;
• le traitement de la TVA sur la commission ;
• les règles selon le pays du vendeur et de l’acheteur ;
• les obligations de déclaration propres aux opérateurs de plateforme ;
• la conservation des pièces.

Ne mélangez pas le reçu de paiement, la facture commerciale et le relevé vendeur. Ils répondent à des fonctions différentes. Votre back-office doit pouvoir les retrouver et les relier à la même transaction.

Cet article expose des choix de conception, pas un avis juridique ou fiscal. Faites confirmer votre montage avant le développement : changer l’entité vendeuse après le lancement touche chaque paiement, contrat et document.

Un relevé vendeur doit raconter chaque centime

Le vendeur ne devrait pas avoir à ouvrir un ticket pour comprendre pourquoi une commande de 100 € produit un versement de 76,42 €. Donnez-lui un relevé détaillé :

• montant de la vente ;
• taxes et frais de livraison ;
• commission et base de calcul ;
• frais éventuels ;
• remboursements ;
• litiges ;
• ajustements ;
• solde en attente ;
• prochain versement estimé.

Permettez l’export dans un format exploitable par sa comptabilité. Le total du relevé doit se rapprocher du solde du prestataire de paiement et de vos propres écritures.

La transparence réduit le support, mais surtout elle rend la plateforme digne de confiance. Vous demandez à des entreprises de vous confier une partie de leur chiffre d’affaires ; une ligne « ajustement -12,30 € » sans explication ne suffit pas.

Le rapprochement financier, tous les jours

Trois sources doivent rester cohérentes :

1. vos commandes et remboursements ;
2. les paiements, transferts et versements du prestataire ;
3. les écritures comptables et relevés bancaires.

Les événements webhooks alimentent le système en continu, mais un rapprochement périodique détecte ce qui a été perdu, corrigé manuellement ou reçu dans un ordre inattendu. Les tests, alertes et procédures de reprise relèvent du même soin invisible qui fait durer un logiciel : le paiement ne bénéficie d’aucune dispense parce que son intégration portait un logo rassurant.

Contrôlez au minimum :

• chaque commande payée possède un paiement confirmé ;
• chaque transfert correspond à une allocation vendeur ;
• chaque remboursement possède son mouvement inverse ;
• les commissions enregistrées égalent les commissions attendues ;
• les soldes en attente expliquent les montants non versés ;
• aucun événement critique ne reste sans traitement.

Un tableau d’anomalies doit prioriser par montant et ancienneté. Le but n’est pas seulement de produire la comptabilité de fin de mois ; c’est de détecter rapidement une règle cassée avant qu’elle touche des centaines de transactions.

Webhooks et idempotence : les garde-fous invisibles

Le client peut fermer la page juste après son paiement. La confirmation affichée dans le navigateur n’est donc pas la preuve fiable. Votre serveur écoute les événements signés du prestataire et met à jour la commande.

Ces événements peuvent arriver plusieurs fois ou dans un ordre différent de celui imaginé. Chaque traitement doit être idempotent : le même événement rejoué ne crée ni seconde commande, ni second transfert, ni second email.

Conservez l’identifiant de l’événement, vérifiez sa signature et répondez rapidement avant d’exécuter les traitements lourds dans une file. Surveillez les échecs et permettez la reprise.

Les principes de notre guide pour connecter des outils par API deviennent ici critiques : un doublon de contact gêne ; un doublon de remboursement coûte de l’argent.

Concevoir le support avant le premier incident

Le support marketplace navigue entre deux récits. L’acheteur affirme ne pas avoir reçu sa commande ; le vendeur montre une preuve d’envoi. L’outil doit réunir les faits sans exposer inutilement les données de l’autre partie.

Construisez une chronologie :

• commande et conditions acceptées ;
• paiement ;
• messages importants ;
• validation ou expédition ;
• preuve de réalisation ;
• demande d’annulation ;
• décision de support ;
• mouvements financiers.

Définissez les droits. Qui peut rembourser ? Jusqu’à quel montant sans validation ? Qui peut inverser un transfert ? Une action sensible exige-t-elle une confirmation renforcée ? Toutes les décisions doivent être tracées.

Un bon back-office n’est pas le catalogue vu de l’intérieur. C’est l’outil qui permet de résoudre les exceptions avec le contexte, les permissions et les garde-fous nécessaires.

Les scénarios à tester avant la production

Ne vous contentez pas du paiement réussi. Testez au minimum :

• carte refusée puis nouveau moyen de paiement ;
• authentification bancaire abandonnée puis reprise ;
• double clic et rechargement de page ;
• webhook en retard, dupliqué et reçu dans le désordre ;
• vendeur incomplet ou versements désactivés ;
• panier avec un et plusieurs vendeurs ;
• remise plateforme et remise vendeur ;
• remboursement total et partiel ;
• remboursement après transfert ;
• vendeur sans solde suffisant ;
• litige gagné et perdu ;
• versement bancaire échoué ;
• devise ou arrondi problématique ;
• annulation d’un seul vendeur dans un panier mixte ;
• indisponibilité temporaire du prestataire.

Vérifiez à chaque fois l’état visible par l’acheteur, le vendeur, le support et la comptabilité. Un flux n’est terminé que quand ces quatre vues racontent la même histoire.

Construire ou rester sur une plateforme existante ?

Une marketplace sur mesure n’est pas automatiquement plus rentable qu’une solution existante. Si votre modèle suit un catalogue, une commission et un checkout standards, commencez peut-être avec un outil éprouvé. Notre comparatif Wix, Shopify ou sur-mesure pose la ligne de décision sans dogme.

Le sur-mesure devient pertinent quand vos règles font le produit : réservation complexe, répartition entre plusieurs rôles, validation métier, tarification spécifique, expérience vendeurs différenciante, connexion à un écosystème existant. C’est ce qui a motivé notre travail sur Perpignan Marketplace, plateforme locale dont les parcours ne se réduisent pas à un thème de boutique.

La checklist avant la première ligne de code

Vous êtes prêt à concevoir la marketplace si :

• l’entité vendeuse et les responsabilités ont été validées ;
• le schéma des 100 € existe pour vente, annulation, remboursement et litige ;
• la commission et son remboursement sont définis par des exemples ;
• le panier contient un ou plusieurs vendeurs de façon explicite ;
• le moment du transfert et du versement est distingué ;
• l’onboarding KYC possède des états et relances ;
• la source des taxes et factures est décidée ;
• le solde négatif et la responsabilité des pertes sont prévus ;
• chaque ligne de commande conserve sa ventilation financière ;
• les événements sont signés, tracés et idempotents ;
• un rapprochement compare commandes et mouvements financiers ;
• le vendeur dispose d’un relevé compréhensible ;
• le support possède une chronologie et des permissions ;
• les scénarios d’échec ont été testés avant les vrais paiements.

Le paiement est l’architecture du produit

Sur une marketplace, le checkout n’est pas une fonctionnalité qu’on branche à la fin. Il traduit votre modèle économique et organise la confiance entre trois parties. Un choix approximatif sur la répartition des fonds se retrouve partout : base de données, interface vendeur, support, contrats et comptabilité.

Cadrer ces flux tôt ne ralentit pas le projet. Cela évite de refaire le cœur du système après les premiers remboursements. Notre service e-commerce et marketplace sur mesure commence donc par les règles de vente, d’encaissement et d’exception avant de dessiner les écrans.

Vous préparez une plateforme avec commission, abonnements vendeurs ou panier multi-prestataires ? Dessinez-nous le trajet des 100 €. C’est la conversation la plus utile à avoir avant le premier bouton « Payer ».