Un acheteur ajoute trois produits vendus par deux marchands. Le checkout affiche « livraison vendredi » et débite 180 euros. Après confirmation, le premier vendeur refuse une ligne, le second expédie en deux colis et les frais sont recalculés. L’acheteur reçoit quatre emails, voit deux montants remboursés et ne sait plus combien sa commande lui coûtera réellement.
Le problème apparaît lorsque l’interface promet une commande unique alors que stock, contrat, logistique et reversement s’exécutent par vendeur. Masquer cette fragmentation ne la supprime pas. À l’inverse, exposer chaque détail technique transforme l’achat en parcours comptable et déplace la charge vers le support.
Le vrai enjeu du panier multi-vendeur dans une marketplace opérateur est de réunir une intention acheteur tout en conservant les engagements distincts de chaque vendeur. Contre-intuitivement, une promesse claire peut comporter plusieurs livraisons si prix, responsabilité et conséquences restent visibles avant paiement.
Vous allez comprendre comment modéliser le split, réserver stock et paiement, confirmer les vendeurs, puis traiter échecs, annulations et suivi. Entrées, sorties, owner, instrumentation, monitoring, dépendances, seuils, file, retry et rollback rendent chaque sous-commande cohérente avec la vision globale.
Définir la promesse acheteur
Afficher les séparations qui changent la décision
Le checkout groupe les lignes par livraison, vendeur ou contrat lorsque cela affecte délai, frais, minimum de commande, retour ou garantie. Il ne montre pas un split purement technique sans conséquence. Les libellés restent stables entre panier et confirmation.
L’acheteur voit montant total, nombre de livraisons, dates, frais et responsables avant de payer. Une promesse « entre jeudi et samedi » peut être correcte si chaque colis possède sa fenêtre et si le total ne change plus après confirmation.
Distinguer global et local
Coupon opérateur, moyen de paiement et adresse peuvent être globaux. Stock, expédition, politique de retour et minimum sont souvent locaux au vendeur. La matrice décrit le grain de chaque règle pour éviter un calcul appliqué au mauvais périmètre.
Une règle globale n’écrase pas une impossibilité locale. Si un vendeur ne livre pas l’adresse, alors ses lignes sont bloquées ou retirées avant paiement. Le système ne promet pas de résoudre ce conflit après commande.
La décision économique inclut la friction du split. Ajouter un vendeur peut rendre le panier plus riche tout en augmentant frais et risque d’échec. Le merchandising peut privilégier une offre légèrement plus chère qui réduit le nombre de livraisons, à condition d’expliquer le choix.
Séparer panier, commande et sous-commandes
Construire un agrégat acheteur
Le cart porte l’intention mutable. L’order fige prix, acheteur, paiement et promesse globale. Les seller_orders regroupent lignes, vendeur, expédition et obligations. Chaque objet possède identifiant, version et machine à états.
La commande acheteur ne devient pas « livrée » parce qu’une sous-commande l’est. Son état est une projection : partiellement confirmée, en cours, partiellement expédiée, terminée ou partiellement remboursée. Les détails restent accessibles.
Les transitions globales sont calculées depuis les sous-commandes, jamais saisies directement. Cette projection conserve un résumé lisible tout en permettant de revenir aux faits. Un recalcul après incident compare versions et détecte une sous-commande manquante au lieu de forcer artificiellement le statut attendu par le support.
Figer un manifeste de split
Le manifeste associe chaque ligne à seller_order_id, shipment_group_id, payment_allocation et tax_allocation. Il est créé lors de la confirmation et versionné pour les changements ultérieurs. Une annulation ne réécrit pas la composition initiale.
Les entrées sont cart_version, offres, vendeurs, adresses et règles ; les sorties sont order, sous-commandes, groupes, montants et réservations. Orders possède le manifeste. Les domaines consommateurs accusent réception.
Calculer prix, taxes et frais
Appliquer chaque règle au bon grain
Le prix vient de l’offre et de son contexte. Les frais de livraison suivent groupe et vendeur ; la remise peut être ligne, vendeur ou panier ; les taxes dépendent des faits pertinents. Le moteur produit une ventilation, pas seulement un total.
Chaque allocation cite source, base, taux, arrondi et bénéficiaire. Le total acheteur égale la somme des lignes, frais, taxes et remises. Les centimes résiduels sont attribués selon une règle déterministe conservée dans le snapshot.
Gérer promotions et minimums
Un coupon de 20 euros réparti sur deux vendeurs possède une clé d’allocation. Si une ligne est annulée, la remise n’est pas recalculée comme si la commande n’avait jamais existé ; la policy indique restitution, réallocation ou conservation.
Les minimums de commande sont vérifiés après promotions selon contrat. Retirer une ligne peut faire repasser une sous-commande sous le seuil. Dans ce cas, le checkout demande un choix avant paiement ou annule le groupe selon l’option acceptée.
Par exemple, un vendeur exige 50 euros hors frais et un autre 30 euros. Un coupon opérateur ne doit pas rendre le premier artificiellement inéligible si le minimum porte sur le prix catalogue. Le calcul expose les bases utilisées.
Réserver le stock de chaque vendeur
Créer des réservations bornées
Chaque ligne demande une réservation avec offer_id, quantity, expires_at et idempotency_key. Les réponses sont confirmée, partielle, refusée ou inconnue. Le panier ne confond pas une disponibilité affichée avec un engagement.
Les réservations partagent une échéance compatible avec le paiement. Un vendeur très lent ne bloque pas indéfiniment tous les autres. Le checkout affiche le groupe indisponible et conserve les lignes encore valides.
Éviter la survente et les fuites
Un retry retourne la même réservation. Une commande confirmée consomme la quantité ; une annulation la libère. Le worker d’expiration produit un événement idempotent et ne supprime jamais la trace.
Le monitoring suit taux de refus, expirations, latence et réservations orphelines par vendeur. Une hausse signale stock périmé ou intégration fragile avant que les annulations n’apparaissent dans les KPI acheteur.
Autoriser et répartir le paiement
Choisir une stratégie de capture
Une autorisation globale simplifie l’expérience, tandis que captures partielles suivent les confirmations ou expéditions. La stratégie dépend du moyen de paiement et du modèle. Elle est décidée avant checkout, pas au premier refus vendeur.
La payment_intent relie order_id et allocations. Chaque capture ou remboursement cite seller_order_id et lignes. Le ledger distingue argent acheteur, commission, vendeur, taxes et frais sans dériver depuis le seul total PSP.
Gérer expiration et échec partiel
Une autorisation peut expirer avant confirmation d’un vendeur. Le workflow définit délai, relance et alternative. Il ne capture pas un groupe déjà refusé pour préserver les autres sans consentement clair.
Si le moyen ne supporte pas les captures requises, alors la marketplace adapte la promesse ou sépare les paiements avant confirmation. Elle ne simule pas une capacité que le PSP ne garantit pas.
Les callbacks sont idempotents et comparés à payment_version. Un succès tardif après annulation ouvre une compensation immédiate, sans recréer la commande. Finance suit ces cas dans une file dédiée.
La réconciliation rapproche chaque jour allocations, captures, remboursements, commissions et sous-commandes. Elle cherche les montants sans objet métier, les lignes confirmées sans capture et les remboursements non reflétés. Une correction passe par un mouvement compensatoire approuvé, jamais par la modification directe du total affiché.
Construire les groupes de livraison
Regrouper selon une exécution réelle
Un groupe partage origine, vendeur, mode, fenêtre et contraintes. Deux lignes du même vendeur peuvent partir séparément si entrepôts ou températures diffèrent. Le grouping conserve la raison de séparation.
Les options sont calculées avec stock réservé et adresse. Le prix et la date sont figés dans le snapshot. Un transporteur indisponible déclenche une alternative avant paiement ou une revue après incident selon promesse.
Présenter un calendrier compréhensible
Le checkout affiche « deux livraisons » avec dates et montants. Il distingue expédition, retrait et service. La confirmation garde le même ordre visuel pour que l’acheteur retrouve ses choix.
Une date globale n’est affichée que si toutes les lignes la respectent. En revanche, le front peut résumer la dernière date attendue tout en montrant les groupes. Cette synthèse ne masque pas une ligne plus lente.
Orchestrer la confirmation distribuée
Utiliser une saga explicite
La saga vérifie panier, réserve stock, autorise paiement, crée les sous-commandes puis confirme les vendeurs. Chaque étape écrit état, tentative et compensation. Une base unique ne suffit pas à rendre atomiques les partenaires.
L’ordre dépend du coût d’irréversibilité. Un code numérique consommable peut être provisionné après paiement ; une réservation stock peut précéder. La saga choisit par type de ligne et conserve le plan appliqué.
Rendre les commandes idempotentes
Checkout_request_id devient la clé racine. Les sous-commandes dérivent une clé stable. Un double clic, timeout ou retry ne crée pas deux commandes vendeur. La réponse précédente est retrouvée par état.
Les messages utilisent outbox et consommateurs idempotents. Les callbacks hors ordre sont mis en attente ou ignorés selon version. Une confirmation ancienne ne peut pas annuler une décision plus récente.
Le runbook décrit files, seuils et reprise. Operations peut rejouer une étape sans répéter paiement ou notification. Une action manuelle passe par le même service que l’automatisation.
Traiter les échecs partiels
Décider avant l’incident
La policy choisit tout-ou-rien, meilleur effort ou consentement acheteur par scénario. Un panier de produits indépendants peut conserver les groupes confirmés ; un kit multi-vendeur peut exiger annulation complète.
Le checkout annonce cette règle. Lorsqu’un groupe échoue, le système calcule nouveau total, livraison et remise, puis demande confirmation si la promesse change matériellement. Il ne remplace pas silencieusement une ligne.
Le consentement porte une version et une échéance. Pendant l’attente, stock et autorisation peuvent expirer ; la reprise recalcule alors les éléments modifiés et les montre. L’acheteur ne confirme pas un panier devenu différent de celui présenté dans le premier message.
Compenser dans le bon ordre
La compensation annule sous-commande, libère stock, ajuste paiement, restaure coupon selon policy et informe. Chaque action possède idempotency_key. Une étape déjà réussie est reconnue lors du retry.
Si une compensation échoue, alors la commande passe NEEDS_RECONCILIATION et rejoint une file. L’acheteur reçoit un message borné. Le support ne promet pas un remboursement tant que l’intention n’est pas au moins enregistrée.
Annuler et rembourser au bon grain
Conserver le périmètre demandé
L’acheteur peut annuler ligne, sous-commande ou commande selon états. Le système montre les conséquences sur frais, remise et autres lignes avant validation. Une annulation partielle ne ferme pas les groupes déjà expédiés.
Le reason code, acteur et version restent liés au mouvement. Le vendeur ne peut annuler une ligne d’un autre marchand. L’opérateur peut intervenir avec droits et justification spécifiques.
Répartir remboursement et commission
Le calcul repart des allocations figées : prix, taxe, frais, coupon et commission. Il ne divise pas le total au prorata après coup si le contrat utilisait une autre base. Les arrondis compensent exactement les mouvements initiaux.
Le PSP, ledger et commande sont réconciliés. Un remboursement initié n’est pas encore reçu. L’acheteur voit montant et délai par mouvement, puis un total agrégé qui évite de compter deux fois.
Les frais de livraison déjà consommés suivent la policy du groupe, tandis qu’un coupon financé par l’opérateur ou le vendeur retrouve son financeur initial. Cette provenance empêche de faire supporter à un marchand l’annulation d’un autre et permet à Finance d’expliquer le coût complet du dossier.
Réunifier suivi et support
Construire une timeline acheteur
La page commande regroupe événements par livraison et sous-commande sous une référence globale. Elle montre confirmé, expédié, livré, annulé et remboursé avec dates. Les statuts techniques restent accessibles aux opérations.
Les notifications sont agrégées lorsqu’elles appartiennent au même moment. Une expédition génère son message ; quatre événements internes en cinq secondes ne doivent pas produire quatre emails. Le journal conserve tout.
Router le support sans perdre le contexte
Une demande part de order_id puis sélectionne ligne ou groupe. Le dossier charge vendeur, transport, paiement et historique. Le premier niveau ne demande pas à l’acheteur de connaître seller_order_id.
Les responsabilités et SLA varient, mais l’opérateur garde la vision. Une escalade transmet preuves et action attendue. Le niveau suivant ne recommence pas le diagnostic depuis un export.
Le dossier support autorise seulement les actions compatibles avec l’état : renvoyer une notification, demander une preuve, annuler une ligne encore ouverte ou relancer une compensation. Chaque action affiche son impact sur les autres groupes. Une personne ne peut pas fermer la commande globale pour résoudre un seul retard vendeur.
Mesurer qualité et coût complet
Suivre le funnel du panier distribué
Le tableau suit conversion, nombre de vendeurs, refus stock, autorisations, confirmations, échecs partiels, annulations, remboursements et contacts support. Les métriques sont segmentées par méthode et vendeur.
Le panier moyen peut augmenter pendant que marge baisse à cause des frais, du support et des compensations. Le cost-to-serve par combinaison aide à ajuster seuils de livraison gratuite ou merchandising.
Détecter les signaux faibles
Une hausse des paniers abandonnés après affichage des groupes signale une promesse ou un coût. Des réservations expirées révèlent une saga trop lente. Des remboursements fractionnés mal compris précèdent souvent les tickets.
Le monitoring couvre files, stock, PSP, sous-commandes, notifications et réconciliation. Chaque alerte possède owner, seuil, échantillon et runbook. Le rollback peut fermer un mode de split sans arrêter les commandes simples.
Adapter la méthode et éviter les erreurs
Pour qui le panier multi-vendeur convient
Il apporte de la valeur lorsque l’acheteur veut réunir plusieurs offres et que paiement ou navigation peuvent rester cohérents. Une marketplace avec contraintes très incompatibles peut préférer plusieurs paniers explicites.
Orders possède l’agrégat, Sellers les sous-commandes, Payments les mouvements, Logistics les groupes et Support la vision. Chaque règle cite son grain et son owner.
Erreurs fréquentes du panier multi-vendeur
Promettre une date unique fausse, capturer avant validation, recalculer les remises après annulation et utiliser un seul statut pour toute la commande sont les erreurs majeures. Masquer les vendeurs ne supprime pas les contrats.
Une autre erreur consiste à laisser chaque domaine notifier séparément. Enfin, une compensation manuelle hors saga crée des doubles remboursements. La reprise doit rester idempotente et réconciliée.
Plan d’action pour industrialiser le panier multi-vendeur
Semaines 1 à 4 : contrat et split
La première semaine ferme grains et états. La deuxième construit calcul et manifeste. La troisième branche réservations et paiement. La quatrième implémente saga, outbox et projection acheteur.
Les tests couvrent deux vendeurs, stock partiel, timeout PSP, retry, coupon, frais, livraison séparée, annulation et remboursement. Chaque cas attend états, montants, messages et compensations.
Le corpus inclut aussi panier modifié pendant autorisation, vendeur qui répond après expiration, promotion répartie avec arrondi et remboursement déjà reçu lors d’un retry. Chaque scénario est joué avec les mêmes identifiants deux fois pour prouver l’idempotence de toute la chaîne.
Semaines 5 à 8 : exploitation et pilote
La cinquième semaine outille suivi et support. La sixième construit monitoring et réconciliation. La septième ouvre un canary ; la huitième provoque refus, callback tardif, file morte et rollback.
Les entrées sont paniers, offres, règles et disponibilités ; les sorties sont commandes, groupes, allocations et événements. L’instrumentation suit latence, échecs, files et coût. Le runbook nomme owners.
Le go exige zéro double commande, montants réconciliés, promesse stable et reprise sans ressaisie. Une personne extérieure au projet doit expliquer le total, annuler une ligne et corriger une compensation échouée.
Si l’échec partiel dépasse 1 % ou si le support augmente de 20 % sur la cohorte, alors le trafic reste limité. L’équipe corrige la cause avant d’ajouter vendeurs ou moyens de paiement.
- À faire d’abord : fermer grains, promesse, calcul et stratégie d’échec.
- À tester ensuite : stock, paiement, split, compensation, suivi et réconciliation.
- À différer : les promotions complexes tant que les allocations restent fragiles.
- À refuser : tout split qui ne peut pas expliquer montant, responsable et prochaine action.
Ressources complémentaires opérateur
Borner le premier parcours
Le MVP marketplace avant ouverture aide à sélectionner le split réellement nécessaire.
La méthode pour ouvrir une première catégorie fournit une cohorte vendeurs cohérente.
Structurer catalogue et opérations
Le catalogue PIM marketplace stabilise offres, produits et attributs.
Les écrans du back-office opérateur réunissent sous-commandes, paiements et reprise.
Conclusion : une expérience, plusieurs exécutions
Un panier multi-vendeur fiable distingue intention acheteur, sous-commandes, groupes logistiques et allocations financières.
Réservations, saga et idempotence protègent chaque effet lorsque vendeurs et partenaires répondent à des rythmes différents. Les opérations disposent alors d’une reprise bornée et vérifiable.
Annulations, remboursements, timeline et support réunifient l’expérience sans effacer les responsabilités locales. Cette continuité permet à l’acheteur de comprendre immédiatement ce qui continue, ce qui s’arrête et quel montant reste engagé après chaque événement partiel.
Dawap peut vous accompagner pour concevoir un panier multi-vendeur dont chaque promesse, allocation et compensation reste explicable dans votre marketplace opérateur.
