Agents d’achat : quel panier votre marketplace peut-elle exécuter ?

Un acheteur demande à son assistant de trouver deux accessoires compatibles, livrés avant vendredi, pour moins de 150 euros. L’agent identifie une offre et prépare un panier. Entre cette sélection et le paiement, un vendeur devient indisponible, le transport change et une référence de remplacement apparaît. Le total reste inférieur au plafond. Votre marketplace peut-elle encore commander sans demander un nouvel accord ?

Le risque est de croire qu’un plafond respecté autorise n’importe quelle modification de l’offre. Cette confusion peut produire un achat contesté, puis une reprise manuelle entre support, vendeur et finance. Elle dépasse la capacité à exposer un catalogue ou à recevoir un jeton de paiement. Il faut savoir quelle décision l’acheteur a déléguée, à quelle offre cette décision s’applique et comment la plateforme constate qu’elle reste valable au moment de l’exécution.

La conception d’une marketplace opérateur doit conserver les responsabilités des vendeurs, les règles du prestataire de paiement et une commande compréhensible après l’achat. Une interface conversationnelle ajoute un intermédiaire à cette chaîne. Elle ne supprime ni la livraison, ni le service client, ni les arbitrages lorsqu’une partie du panier échoue.

Nous proposons ici un contrat de décision pour un premier parcours d’achat délégué. Les références ACP sont vérifiées au 23 octobre 2026 ; les montants, identifiants et politiques du scénario sont fictifs. La méthode sert à préparer une recette avec votre équipe et votre PSP. Aucun connecteur ACP n’a été exécuté et aucun paiement réel n’a été effectué pour cet exemple ; aucun résultat commercial n’est revendiqué. La sécurité du paiement marketplace doit relier la permission donnée à ce panier précis, à son vendeur et à ses conditions de validité.

Trouver une offre, préparer un panier et acheter sont trois pouvoirs

Le premier pouvoir consiste à rechercher : comparer les articles, lire leurs caractéristiques et proposer des vendeurs. Le deuxième consiste à préparer : renseigner une adresse, demander des frais de port et construire une proposition complète. Le troisième consiste à engager l’achat. Une équipe produit doit pouvoir autoriser les deux premiers sans accorder automatiquement le troisième.

Cette séparation permet un lancement progressif. Un assistant peut produire une sélection utile et remettre la confirmation à un écran connu de la marketplace. Le parcours reste intéressant même si le paiement exige une intervention. Mesurer uniquement les commandes entièrement autonomes ferait disparaître la valeur des recherches qualifiées et des paniers préparés correctement.

Décrire les libertés réellement accordées

« Acheter le moins cher » laisse beaucoup de questions ouvertes. Le produit peut-il être reconditionné ? Un autre vendeur est-il acceptable ? Une livraison en deux colis convient-elle ? La réponse doit devenir une règle explicite ou une demande de précision, avant qu’une ambiguïté soit transformée en commande.

Pour le pilote, conservez une politique lisible : références autorisées, variantes interdites, budget total, destination et date limite. Ajoutez la personne ou le système habilité à confirmer un changement. Cette fiche est une proposition d’organisation ; elle ne remplace pas la qualification juridique des autorisations ni les mécanismes de votre prestataire.

Ce qu’ACP décrit, et ce que votre modèle marketplace doit encore décider

La documentation d’architecture ACP distingue acheteur, agent, vendeur et prestataire de paiement. Le vendeur y conserve le rôle de marchand responsable de la vente, avec les calculs de prix, la disponibilité et l’exécution. Deux échanges sont séparés : le checkout et la délégation de paiement. Cette répartition ne détermine pas à elle seule le montage contractuel d’une marketplace multi-vendeur.

Dans votre projet, « vendeur » peut désigner un professionnel visible sur une fiche, tandis que le destinataire du paiement dépend du modèle validé avec le PSP. Établissez la correspondance entre ces identités. Ne déduisez pas du nom commercial de la plateforme qu’elle devient automatiquement le marchand de chaque transaction ou le bénéficiaire de chaque jeton.

La présentation officielle du protocole précise également que l’implémentation ne garantit pas une présence dans toutes les interfaces d’agents. Les modalités de participation appartiennent aux plateformes concernées. Un projet technique doit donc séparer capacité de transaction, accès à un canal et acquisition réellement mesurée.

Figez enfin une version de spécification et les fonctionnalités de votre intégration. Un exemple trouvé dans une documentation ne constitue pas un contrat complet : schéma, environnement, PSP compatible et restrictions de compte doivent être vérifiés ensemble. Le pilote peut volontairement exclure le multi-devise, les abonnements et les commandes à devis.

Un panier fictif à 142 euros, puis trois changements différents

Prenons une marketplace d’accessoires d’atelier. L’acheteur accepte un kit de fixation vendu par Atelier A à 80 euros et une protection vendue par Atelier B à 50 euros. La livraison totale coûte 12 euros. Tous les montants de cet exercice sont TTC déjà fournis : nous ne calculons pas de taxe. Le total confirmé est donc de 142 euros, sous un plafond délégué de 150 euros.

Le panier confirmé porte la révision P7. Il exige ces deux références, ces deux vendeurs et une arrivée avant vendredi. Il n’autorise pas les substitutions. Ces restrictions sont celles de notre scénario ; elles illustrent un contrat produit possible, pas une règle imposée par ACP.

Le passage à 147 euros respecte encore la limite monétaire. Il échoue pourtant à la règle de référence. Le passage à 152 euros dépasse le plafond de deux euros. Le changement de vendeur ne change aucun montant, mais modifie une condition expressément acceptée. Un contrôle limité au total laisserait passer deux engagements non autorisés.

La décision doit conserver son motif. « Budget disponible » explique seulement une partie du verdict. Le support doit aussi voir référence, vendeur, destination et livraison comparés à P7. Cette lecture réduit les demandes de justification lorsque l’agent présente une nouvelle proposition au client.

Un jeton de paiement borné ne valide pas tout le contenu du panier

La référence Delegate Payment décrit une autorisation technique associant notamment montant maximal, devise, expiration, session de checkout et marchand. La raison d’usage documentée est ponctuelle. Ces contraintes encadrent l’utilisation du moyen de paiement ; elles ne constituent pas une description de toutes les préférences d’achat du client.

Stripe présente ses Shared Payment Tokens comme un mécanisme limitant l’usage du moyen de paiement à un vendeur, un montant et une fenêtre de temps, sans exposer les informations de paiement sous-jacentes à l’agent. La compatibilité avec le parcours exact de votre marketplace reste à confirmer avec le prestataire.

Rapprocher deux autorisations différentes

Conservez, d’un côté, l’accord sur l’achat et, de l’autre, la permission technique de paiement. Le serveur doit constater que les deux couvrent la même opération. Une permission de 150 euros n’autorise pas nécessairement un produit différent à 147 euros. Un accord sur P7 ne suffit pas non plus si le moyen de paiement a expiré.

Le renouvellement d’un jeton ne doit pas modifier silencieusement l’accord commercial. Inversement, un accord sur P8 ne prolonge pas automatiquement une capacité de paiement ancienne. Les deux vérifications peuvent être rapprochées dans un même écran, mais leur preuve et leur motif d’échec doivent rester distincts dans l’exploitation.

Identifier le marchand avant de promettre un panier multi-vendeur

Un panier unique peut cacher plusieurs ventes et plusieurs exécutions logistiques. Le contrat doit préciser quelles commandes seront créées, quel acteur encaissera selon le montage retenu, comment les montants rejoindront les vendeurs et qui répondra à l’acheteur. Cette décision précède la conception de l’interface agent.

Trois vendeurs dans une liste ne prouvent pas qu’un seul paiement délégué suffit. Un identifiant de marchand accepté par un mécanisme donné ne doit pas être réutilisé pour un autre bénéficiaire sans validation explicite du parcours. Les choix de paiement et de PSP marketplace doivent être éprouvés sur vos contrats, vos pays et vos comptes.

Limiter le premier parcours pour obtenir une preuve exploitable

Une première version peut accepter uniquement les paniers dont le montage de paiement est déjà qualifié, avec une devise et un mode de livraison maîtrisés. Si le panier sort de ce périmètre, elle prépare les éléments puis propose un parcours assisté. L’interface doit annoncer ce passage avant de laisser croire que l’achat est terminé.

Ce choix conserve un coût d’intégration mesurable. Il permet surtout de comprendre les échecs : indisponibilité commerciale, permission insuffisante, moyen de paiement incompatible ou incident technique. Un taux global de réussite cacherait ces causes alors qu’elles demandent des responsables et des corrections différents.

Lier l’accord à une révision lisible et vérifiée côté serveur

Dans le modèle proposé, une révision de panier contient les références, quantités, vendeurs, prix, frais, devise, destination et engagements de livraison. La confirmation renvoie à cette révision. Si un champ déterminant change, le serveur produit une nouvelle proposition et applique la politique prévue pour obtenir ou vérifier l’accord nécessaire.

Il n’est pas indispensable d’exposer un numéro technique à l’acheteur. En revanche, l’écran doit expliquer la différence : « protection remplacée », « vendeur modifié » ou « livraison lundi au lieu de vendredi ». Une simple demande de confirmer le nouveau total est insuffisante lorsque le montant n’a pas changé.

Empêcher l’écart entre vérification et commande

Une comparaison correcte peut devenir obsolète avant l’écriture de la commande. Le prix ou le stock peut changer pendant le paiement. L’architecture doit traiter cette concurrence avec les capacités réellement offertes par ses composants : réservation, contrôle de version, verrouillage limité ou nouvelle vérification au point d’engagement.

La stratégie retenue doit produire une issue précise si la réservation échoue. Pour P7, la disparition de la protection ne permet pas de vendre seulement le kit si l’accord exige les deux. On propose un nouveau choix ou on arrête selon la politique. La disponibilité d’une ligne ne vaut pas permission d’exécuter un achat partiel.

Prévoir une intervention sans perdre la proposition

La négociation de capacités ACP prévoit les interventions que l’agent et le vendeur peuvent prendre en charge. Les possibilités communes ne suppriment pas les exigences du vendeur. Si une authentification requise n’est pas disponible dans l’environnement de l’agent, le parcours doit traiter cette incompatibilité. Les contrôles de sécurité restent appliqués côté serveur.

Concevez ce moment comme une étape normale. L’utilisateur retrouve le panier, les conditions à confirmer et la raison de son intervention. Il ne doit pas devoir reconstruire son achat à partir d’un lien générique ni croire qu’un refus de capacité signifie que sa carte a été débitée.

Le retour d’intervention exige une nouvelle lecture des conditions encore valables. Une adresse corrigée peut modifier le port ; une longue attente peut dépasser une réservation. La reprise présente le nouvel état et demande les décisions manquantes. Elle ne transforme pas la présence d’un retour navigateur en preuve de paiement.

Pour les utilisateurs qui ne poursuivent pas, rendez visible la sortie : proposition conservée sans commande, panier expiré ou action encore attendue. Le support doit pouvoir expliquer cette différence sans accéder aux secrets de paiement ni au contenu intégral d’une conversation privée.

Une réponse perdue ne permet pas de recommencer l’achat

La description du cycle ACP sépare notamment session prête, traitement en cours et session terminée avec paiement réussi et commande créée. Une session prête n’est donc pas une commande payée. Après une coupure réseau, l’état observé par l’agent peut être plus ancien que celui du système vendeur.

La référence Checkout fournit une opération de lecture de session et prévoit une clé d’idempotence. Votre implémentation doit vérifier leurs garanties pour la version choisie, puis définir comment retrouver l’opération initiale. Il serait dangereux de créer immédiatement une nouvelle session et une nouvelle demande de paiement après chaque délai dépassé.

Reprendre P7 à partir de sa trace, sans multiplier les effets

Dans notre scénario, le serveur crée la commande C71 pour 142 euros, puis la réponse n’atteint pas l’agent. Celui-ci conserve l’identifiant de session et la référence de sa tentative. La reprise recherche C71 et l’état du paiement associé. Si les deux sont confirmés, elle restitue cette commande au lieu d’en ouvrir une seconde.

Si le PSP confirme un paiement mais que la commande manque, le dossier devient une exception à traiter. Il ne faut ni afficher une réussite complète ni débiter une nouvelle fois pour « débloquer ». La procédure doit rapprocher les preuves disponibles et appliquer la compensation ou la reprise approuvée pour ce montage.

Mise en œuvre : quatre responsabilités à rendre observables

Le contrat d’entrée réunit session, révision, identité de l’agent, identité acheteur autorisée, lignes, conditions et références de décision. La sortie contient une commande confirmée, une intervention attendue, un refus motivé ou un traitement à réconcilier. Le propriétaire du checkout décrit les dépendances catalogue, stock, PSP et OMS, ainsi que les limites de chaque transaction.

La journalisation relie les identifiants sans recopier les secrets. Le monitoring suit les sessions bloquées, les réponses incertaines, les révisions refusées et les paiements sans commande rapprochée. Une file d’exception désigne une responsabilité opérationnelle et une prochaine action. Le repli permet de suspendre la finalisation par agent tout en conservant la consultation et l’accès aux commandes existantes.

• Produit : définit les changements exigeant un accord et les cas autorisés au lancement.
• Équipe plateforme : protège les écritures, contrôle les versions et construit la reprise.
• Finance et PSP : qualifient les identités de paiement, les rapprochements et les compensations.
• Support : explique l’état acheteur et retrouve les preuves avec ses droits ordinaires.

Le pilotage doit mesurer les sessions éligibles, puis les propositions acceptées, les interventions, les commandes confirmées et les dossiers incertains. Gardez le même dénominateur quand vous comparez deux versions. Une ouverture à de nouveaux vendeurs peut modifier la population et faire varier le taux de succès sans dégradation technique.

Recette : les neuf situations à faire décider avant le pilote

La matrice suivante est une recette proposée, non le compte rendu d’un test ACP exécuté. Chaque ligne doit être reproduite dans votre environnement qualifié, avec les capacités exactes du PSP. Le résultat attendu comporte l’état acheteur, les effets financiers et la trace permettant de reprendre.

L’annulation mérite une preuve séparée : avant la vente, on peut abandonner une proposition ; après, des engagements existent déjà. La procédure doit tenir compte du paiement et de l’exécution réelle. Un bouton portant le même mot ne doit pas produire une promesse identique dans ces deux moments.

Sur ce pilote, tout achat exécuté hors des conditions acceptées constitue un seuil d’arrêt immédiat. Ce choix vise la validité de l’engagement, pas une moyenne de performance. Les erreurs de disponibilité ou les abandons peuvent être analysés progressivement ; un achat non autorisé exige d’abord de suspendre le chemin concerné.

Erreurs fréquentes : optimiser l’autonomie avant la confiance

Prendre une phrase de l’agent pour une preuve complète

« Le client a confirmé » ne suffit pas si l’on ne sait pas ce qu’il a vu. Un historique conversationnel peut aider à comprendre le contexte, mais le système d’exécution a besoin de conditions structurées et d’une autorité vérifiable. Le serveur ne doit pas accepter une permission parce qu’elle apparaît dans une description produit ou une réponse textuelle.

La correction consiste à définir une voie dédiée à la confirmation et à traiter les contenus vendeurs comme des données commerciales. Les caractéristiques et les conditions peuvent alimenter une proposition. Elles ne doivent pas augmenter les droits de l’agent, changer le destinataire d’un paiement ou neutraliser un contrôle d’identité.

Promettre une croissance immédiate parce que le protocole fonctionne

Un connecteur conforme ne prouve ni la distribution, ni la qualité de la demande, ni la rentabilité de ce canal. Le pilote doit comparer ses coûts de développement et de support aux commandes effectivement attribuables. Une démonstration spectaculaire n’est pas une prévision de trafic.

Mesurez aussi les mauvaises sélections évitées, les demandes nécessitant une clarification et les sorties assistées réussies. Une intervention utile peut améliorer l’expérience. La supprimer uniquement pour afficher davantage d’autonomie peut augmenter les retours et dégrader la confiance sans créer de valeur supplémentaire.

Pour qui ouvrir ce parcours : arbitrer les limites du pilote

Ce chantier convient à un opérateur disposant déjà de données produit fiables, d’une commande traçable et d’un paiement exploitable. Il devient pertinent lorsque des agents ou partenaires identifiés apportent une demande qualifiée et peuvent respecter un contrat d’intégration. Il reste prématuré si le checkout habituel ne sait pas expliquer ses propres écarts.

• À faire : sélectionner un périmètre connu, nommer l’autorité acheteur et tester les changements de conditions.
• À différer : les substitutions, paniers internationaux et ventes complexes dont le consentement ou le paiement ne sont pas stabilisés.
• À refuser : un accès autonome sans plafond défini, identité de marchand vérifiée ni procédure de reprise des issues incertaines.

Le sponsor doit arbitrer sur la capacité à tenir une promesse complète. Si une seule famille d’articles possède les données nécessaires, commencez par elle. Une ouverture étroite, compréhensible pour les utilisateurs et exploitable par les équipes, donnera des informations plus utiles qu’un catalogue entier dont les exceptions restent invisibles.

Plan d’action : de la première délégation à un pilote maîtrisé

Définir l’autorité et le parcours éligible

Commencez par une séance produit consacrée à l’autorité de l’acheteur. Reprenez une demande réelle anonymisée et écrivez les décisions que l’agent peut prendre seul. Listez ensuite les changements qui imposent une nouvelle confirmation. Livrable attendu : une politique courte que produit, support et finance interprètent de la même manière sur le scénario P7.

Cartographiez ensuite les acteurs de la vente et du paiement. Reliez chaque vendeur visible au montage financier qualifié avec le PSP. Vérifiez les pays, devises, mécanismes de délégation et interventions disponibles. Cette étape doit fermer les cas non pris en charge ; elle ne doit pas laisser une hypothèse de compatibilité devenir une promesse dans l’interface acheteur.

Construisez la proposition versionnée à partir des systèmes existants. Le catalogue fournit les références, le stock la disponibilité, la logistique les options et le checkout les montants. Documentez le point où une offre devient exécutable et la conduite à tenir si l’une de ces sources change. Le résultat doit être relisible sans connaissance du modèle de langage utilisé.

Vérifier la compréhension et la reprise

Préparez ensuite les écrans de changement et d’intervention. Montrez une référence remplacée, un vendeur différent et un délai dépassé à des personnes qui ne connaissent pas l’architecture. Demandez-leur ce qui sera acheté et ce qui reste à confirmer. Si leurs réponses divergent, corrigez les formulations avant de rendre le paiement autonome.

Exécutez la matrice de recette avec les droits opérationnels habituels. Simulez les réponses perdues, retrouvez la commande et vérifiez les effets financiers. Faites reprendre un dossier par le support sans assistance du développeur auteur. Conservez les preuves utiles, leurs limites et les corrections demandées ; une capture de l’écran final ne couvre pas les transitions intermédiaires.

Enfin, ouvrez un pilote limité avec un responsable capable de suspendre la finalisation. Suivez les sessions éligibles, les décisions hors périmètre, les achats confirmés et les dossiers incertains. L’extension exige une revue de ces résultats et des coûts de support. Si une nouvelle catégorie change les règles de livraison ou le modèle de paiement, elle mérite sa propre qualification avant de rejoindre le périmètre.

Guides complémentaires : panier, offre acceptée et support

Le choix entre panier unique et multi-panier fixe la promesse que l’agent présentera. Une interface commune doit conserver les différences de vendeurs, de frais et d’exécution. Décidez cette structure avant de transformer le checkout existant en service consommable par un assistant.

La conversion du devis accepté en commande approfondit la conservation des prix, versions et approbations. Pour traiter les situations qui restent incertaines, la chronologie du support acheteur décrit les informations à réunir dans une vue exploitable. Ces deux capacités doivent rester disponibles après la fermeture de la conversation avec l’agent.

Conclusion : exécuter l’achat accepté, même quand l’interface change

Le commerce par agent apporte une nouvelle manière de rechercher et de préparer un achat. Pour une marketplace, la difficulté décisive se situe au moment de l’engagement : retrouver les conditions acceptées, vérifier qu’elles sont encore valables et faire correspondre la permission de paiement à la bonne opération.

Le scénario à 142 euros montre pourquoi un plafond ne suffit pas. Une référence à 147 euros ou un vendeur différent au même prix peut sortir de l’accord. Le contrôle doit porter sur l’achat complet. La réponse perdue après C71 rappelle ensuite qu’une reprise doit retrouver l’effet initial avant d’autoriser une nouvelle tentative.

Pour approfondir les engagements liés à une offre évolutive, consultez le dossier sur le devis de livraison et l’autorisation carte. Il complète le sujet sur la durée de validité des conditions, tandis que les ressources recommandées détaillent panier, conversion de devis et reprise par le support. La conception du paiement et de la sécurité marketplace traduit cet accord en contrôles entre panier, autorisation et exécution.

L’accompagnement marketplace de Dawap relie ces décisions au catalogue, au checkout, au PSP et à l’exploitation. Le premier résultat attendu est un parcours dont chacun peut expliquer l’autorité, le contenu et l’issue. C’est cette capacité vérifiée qui permet ensuite d’élargir les usages des agents.