Notre vérificateur de conformité intègre désormais la vérification du Règlement européen sur l'intelligence artificielle (AI Act) ! En savoir plus.

Dans les coulisses du protocole d'achat de Muse, et ce que votre serveur MCP doit exposer

01/11/2026

Tags: muse, protocole d'achat, commerce agentique, MCP, checkout

Jules Kovac

Jules Kovac

Business Analyst, Founder

Dans les coulisses du protocole d'achat de Muse, et ce que votre serveur MCP doit exposer

Muse, de Meta, peut trouver une veste, remplir l'adresse, calculer la taxe et rester incapable de payer, parce que Meta lui accorde la permission de dépenser depuis l'extérieur du modèle, liée à une commande et à une horloge. Ce verrou est la moitié consommateur de l'histoire. La moitié marchand est un contrat que la plupart des équipes prennent à l'envers : le panier d'abord, le checkout en dernier, et cinq surfaces MCP au lieu de trois. Cet article parcourt les deux moitiés une fois, avec les statuts, les paliers et les règles d'idempotence exacts que Shopify documente désormais.

 

23 h 47, Muse a une veste et aucune permission de payer

Un acheteur dit à Muse qu'il veut une coquille anti-pluie à moins de deux cents dollars. Muse cherche, compare quatre vestes, ouvre une page produit, choisit une taille, remplit l'adresse de livraison, arrive à l'écran de révision de la commande et s'arrête. Le total est à l'écran. La carte est enregistrée. Rien ne bouge.

Muse n'a pas été refusé. Il a atteint une frontière que l'architecture trace exprès, et tout ce qu'il y a d'intéressant dans le commerce agentique se trouve d'un côté ou de l'autre de cette frontière. La recherche est une opération de lecture, et une mauvaise réponse ne coûte rien. Le paiement est une opération d'écriture avec une conséquence financière, donc il lui faut son propre modèle de permission, son propre chemin d'échec et sa propre piste de preuve. Meta a construit Muse autour de cette distinction, et Shopify a construit le côté marchand de la même distinction dans un protocole qui est versionné, testable et assez peu indulgent.

Deux familles de sources soutiennent ce texte. Le flux consommateur, les règles d'approbation et les limites du portefeuille viennent d'une copie divulguée du corpus de prompts internes de l'agent Muse, publiée sur GitHub sous asgeirtj/system_prompts_leaks, recoupée avec les billets d'ingénierie de Meta, les annonces de Stripe et la couverture de presse autour. Le contrat marchand vient de la documentation de Shopify sur le commerce agentique et de la spécification Universal Commerce Protocol, que j'ai lue page par page plutôt qu'en extraits. Là où les deux se contredisent, le protocole gagne, et je le dis.

 

Les cinq étapes de Muse, et le mur à la deuxième étape

Meta a lancé Muse aux États-Unis le 8 septembre 2026, dans l'application Muse et à l'intérieur de WhatsApp. Stripe, qui fournit le rail de paiement, a rapporté trois semaines plus tard que les achats agentiques via Link avaient été multipliés par 38 en un seul mois. Quoi que vous pensiez du produit, le volume est assez réel pour que le protocole en dessous mérite une lecture.

Cinq étapes portent un achat.

Trouver et comparer. La recherche dans le catalogue n'a besoin d'aucune approbation d'achat. Meta Catalog a sa propre permission de recherche, réglée sur autoriser par défaut, donc la première recherche d'une tâche peut demander une fois et cette approbation couvre le reste de la tâche. Présenter des résultats ne déplace aucun argent.

Checkout. Une tâche de navigateur en arrière-plan pilote le checkout du marchand jusqu'à ce que les conditions finales soient prêtes pour révision ou, pour les produits de catalogue qui prennent en charge le checkout agentique, ouvre une session sur UCP sans navigateur actif. Créer un checkout ne déplace toujours aucun argent. S'il manque une taille, une couleur ou un modèle, Muse demande.

Révision. Articles finaux, options choisies, détails de livraison et de contact, total et moyen de paiement apparaissent ensemble. Pour un achat par portefeuille, la révision n'apparaît qu'une fois le portefeuille configuré.

Confirmation. Pour un achat par portefeuille, la carte d'approbation du fournisseur de paiement est la confirmation. Elle autorise cette commande révisée exacte, et Muse est prié de ne pas demander une seconde confirmation dans la conversation. Pour les autres méthodes par navigateur, l'acheteur confirme dans la conversation et un simple oui est accepté.

Achèvement. Après l'approbation, la tâche termine le checkout et soumet la commande. Shop Pay rend un jeton à usage unique. Stripe Link émet une carte virtuelle à usage unique approvisionnée pour cet achat.

C'est à la deuxième étape que le mur se dresse. Muse peut tout faire sauf dépenser, et la permission de dépenser arrive plus tard, de l'extérieur du modèle, liée à une transaction et à une expiration.

Shopper { # Shopper
  s1: circle label:"Ask for a jacket under 200 dollars"
  s2: rectangle label:"Approve one order one amount one method"
  s3: circle label:"Order confirmed"
  s4: circle label:"No order approval expired"
  s1.handle(right) -> Agent.a1.handle(left)
  a3.handle(bottom) -> s2.handle(top) [label="Approval card"]
  s2.handle(right) -> Agent.a4.handle(top) [label="Approved"]
  a4.handle(bottom) -> s4.handle(left) [label="Refused or late"]
}
Agent { # Agent
  a1: rectangle label:"Search and compare products"
  a2: rectangle label:"Prepare checkout and totals"
  a3: rectangle label:"Present reviewed order"
  a4: diamond label:"Approved within ten minutes"
  a5: rectangle label:"Pay with one-time credential"
  a6: circle label:"Submit order"
  a1.handle(right) -> a2.handle(left)
  a2.handle(right) -> a3.handle(left)
  a4.handle(right) -> a5.handle(left) [label="Yes"]
  a5.handle(right) -> a6.handle(left)
  a6.handle(bottom) -> Shopper.s3.handle(top) [label="Confirmation"]
}

 

Les quatre règles qui font tenir le verrou de Muse

Une approbation que Muse pourrait persuader de contourner ne serait pas un verrou. Quatre règles ferment cette porte, et trois d'entre elles s'appliquent hors de la conversation.

Chaque achat redemande. L'approbation se lie à ce checkout exact : même marchand, même montant, même sélection de paiement. Changez l'un des trois et une nouvelle carte se déclenche. La seule exception se trouve sur la carte elle-même, où l'acheteur peut choisir une autre carte enregistrée dans le portefeuille, et l'approbation couvre alors ce choix.

Les approbations ne peuvent pas être préaccordées, groupées ni automatisées. Un accord amical dans la conversation n'est pas une approbation, et le système rejette les autorisations de dépense stockées ou réutilisables. Une tâche planifiée peut aller jusqu'à une carte d'approbation en attente, puis elle attend. C'est toute l'histoire non surveillée, et le côté marchand dit maintenant la même chose dans son propre langage : un appel au palier jeton fait par un agent sans acheteur présent échoue, parce que Shopify n'a pas de valeur de remplacement pour l'adresse IP de l'acheteur et ne se rabattra pas sur l'adresse de l'agent.

Les approbations sont de courte durée. Un checkout en attente expire après une dizaine de minutes, après quoi le flux redémarre depuis la recherche. Séparément, atteindre une page de checkout pendant une tâche de navigateur peut lever sa propre carte de consentement, et une fois celle-ci approuvée, les pages de checkout suivantes dans la même tâche chez le même marchand ne redemandent rien pendant environ trois heures.

Navigation et dépense sont des mécanismes séparés. Un site peut obtenir un toujours-autoriser par site pour la navigation. La dépense ne le peut jamais. La documentation de Meta le dit clairement, et le protocole le reflète : la capacité qui permet à un agent de préparer un achat n'est pas celle qui lui permet de le conclure.

Derrière le verrou se trouvent les limites du portefeuille. Link expose une limite par achat, plus des fenêtres quotidiennes et sur trente jours, via wallet.get_user_info, et Muse les relit à chaque achat au lieu de citer un chiffre plus ancien. Les protections d'achat de Link s'appliquent aux commandes admissibles : jusqu'à 500 $ pour les dommages, le vol ou la perte, jusqu'à 500 $ pour une baisse de prix, jusqu'à 250 $ pour l'expédition de retour et la remise en stock, et jusqu'à 1 000 $ au titre d'une garantie de remboursement. Ces programmes appartiennent à Stripe, pas à Meta, et il est interdit à Muse de dire à un acheteur qu'un achat précis est couvert.

 

Côté marchand : quatre familles de capacités, cinq points de terminaison

Le protocole consommateur ne fonctionne que si le marchand publie une surface lisible par machine. Cette surface est l'Universal Commerce Protocol, codéveloppé pour le magasinage par Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta et Stripe, et il repose sur JSON-RPC 2.0 via MCP, avec REST comme autre transport sanctionné.

Shopify l'implémente en quatre familles de capacités servies par cinq points de terminaison. Si vous voulez la même poignée de main au niveau des séquences, la carte du flux UCP publiée plus tôt sur ce blogue tient toujours ; ce qu'elle précède, c'est la surface du panier, là où se trouve désormais l'essentiel du risque opérationnel. La distinction compte plus que le décompte, parce que les deux familles du milieu font des travaux différents et portent des limites différentes.

Famille Point de terminaison Outils Déplace de l'argent
Catalogue global catalog.shopify.com/api/ucp/mcp search_catalog, get_product, lookup_catalog Non
Catalogue de vitrine {shop}/api/ucp/mcp les trois mêmes noms d'outils, limités à un marchand Non
Panier point de terminaison MCP du marchand create_cart, get_cart, update_cart, cancel_cart Non
Checkout point de terminaison UCP du marchand, /api/ucp/mcp create_checkout, get_checkout, update_checkout, complete_checkout, cancel_checkout Seulement complete_checkout
Commande point de terminaison MCP du marchand, plus webhooks get_order Non

Deux conséquences découlent directement de ce tableau, et la plupart des intégrations se trompent sur les deux à la première passe.

Les paniers servent à réfléchir, les checkouts servent à s'engager. Un panier est un conteneur de longue durée, tolérant pour les appels non authentifiés : ajoutez des lignes, fixez le pays, estimez les totaux, partagez le continue_url du panier avec l'acheteur, continuez à itérer sur plusieurs tours. Un checkout est de courte durée, plus strict sur la fraîcheur et l'idempotence, et limité plus durement. Les chiffres sont publiés : le trafic du catalogue global tourne à 5 requêtes par seconde par client API, et le trafic du catalogue de vitrine est limité par boutique. Shopify le dit en une phrase sur la page du checkout : utilisez Cart MCP pour itérer, réservez Checkout MCP aux acheteurs prêts à acheter. Un agent qui appelle create_checkout à la première impulsion brûle sa limite de débit sur un acheteur qui compare encore des couleurs, et la conversion qu'il perd n'apparaît jamais comme une erreur.

La conversion entre les deux est un champ, pas une reconstruction. create_checkout prend un cart_id facultatif, qui transforme un panier construit avec Cart MCP en session de checkout. Les lignes ne sont pas reconstruites, et les totaux ne sont pas recalculés par l'agent.

Agent { # Agent
  b1: circle label:"Buyer starts shopping"
  b2: rectangle label:"Iterate lines and context on cart"
  b3: rectangle label:"Buyer commits to the order"
  b4: rectangle label:"Open a checkout from the cart"
  b5: rectangle label:"Complete once with the same key"
  b6: circle label:"Order placed"
  b1.handle(right) -> b2.handle(left)
  b2.handle(right) -> b3.handle(left)
  b3.handle(right) -> b4.handle(left)
  b4.handle(right) -> b5.handle(left)
  b5.handle(right) -> b6.handle(left)
  b2.handle(bottom) -> Business.c1.handle(top) [label="update_cart"]
  c1.handle(bottom) -> b3.handle(bottom) [label="Live totals"]
  b4.handle(bottom) -> Business.c2.handle(top) [label="create_checkout"]
  c2.handle(bottom) -> b5.handle(bottom) [label="ready_for_complete"]
}
Business { # Merchant API
  c1: rectangle label:"Cart tools answer at the highest rate limit"
  c2: rectangle label:"Checkout tools answer once then throttle"
}

 

Négociation, paliers, et qui peut réellement conclure

La surprise suivante, c'est que le marchand n'expose pas un menu fixe. Il négocie.

Vous publiez un profil de plateforme à une URL HTTPS et le référencez dans chaque requête via meta.ucp-agent.profile. Le marchand publie son propre profil d'entreprise à /.well-known/ucp, en déclarant la version du protocole, les capacités, les gestionnaires de paiement et les clés de signature. Shopify récupère alors votre profil et le valide, vérifie l'alignement des versions, croise vos capacités déclarées avec ce que la boutique prend en charge, et élague toute extension dont la capacité parente n'a pas survécu au croisement. La négociation est choisie par le serveur. Ce que vous exposez est un contrat qui se négocie, pas un catalogue qui se liste.

Le palier vient ensuite, et il décide de la seule question qui compte commercialement : cet agent peut-il conclure, ou doit-il rendre l'acheteur. Shopify documente trois paliers, et la différence porte entièrement sur ce que le marchand sait de qui appelle.

Palier Outils catalogue, panier, checkout complete_checkout Outils de commande
Jeton, avec permission d'achat Oui, et les jetons liés à l'acheteur personnalisent la recherche et appliquent les rabais automatiques Oui Oui, avec read_global_api_orders, limité aux commandes que votre agent a passées
Signé Oui Non Non
Anonyme Oui Non Non

Deux détails opérationnels vivent à l'intérieur de ce tableau. Les requêtes au palier jeton doivent porter un en-tête Shopify-Buyer-IP à chaque tools/call, y compris les appels en lecture seule, et une IP manquante ou invalide renvoie HTTP 422 sans repli et sans valeur de remplacement. Le trafic signé et anonyme conserve les droits de lecture et de préparation mais perd complètement la conclusion, plus l'essentiel de la limite de débit. Un agent incapable de dire qui il est peut encore parcourir le catalogue et construire un panier, et c'est exactement le niveau de confiance que le marchand est prêt à accorder.

Agent { # Agent
  n1: circle label:"Call create_checkout with profile URI"
  n2: rectangle label:"Publish platform profile over HTTPS"
  n3: rectangle label:"Declare checkout and extensions"
  n4: diamond label:"Negotiated set includes checkout"
  n5: circle label:"Muse completes the order"
  n6: circle label:"Prepare only and hand back"
  n1.handle(right) -> n2.handle(left)
  n2.handle(right) -> n3.handle(left)
  n3.handle(bottom) -> Shopify.m1.handle(top) [label="meta.ucp-agent.profile"]
  m4.handle(bottom) -> n4.handle(top) [label="Active capability set"]
  n4.handle(bottom) -> n5.handle(top) [label="Token with permission"]
  n4.handle(right) -> n6.handle(left) [label="Read only"]
}
Shopify { # Shopify business
  m1: rectangle label:"Fetch and validate the profile"
  m2: diamond label:"Protocol versions align"
  m3: rectangle label:"Intersect capabilities"
  m4: rectangle label:"Prune orphan extensions"
  m5: circle label:"Return an error path"
  m1.handle(right) -> m2.handle(left)
  m2.handle(bottom) -> m3.handle(top) [label="Yes"]
  m2.handle(right) -> m5.handle(left) [label="No"]
  m3.handle(right) -> m4.handle(left)
}

 

Six exigences que votre surface doit respecter

La syntaxe est la partie facile. Ces six points décident si l'intégration survit à son premier mois, et chacun est documenté plutôt que déduit.

Idempotence sur les deux verbes destructeurs. complete_checkout et cancel_checkout exigent un UUID dans meta["idempotency-key"]. Un agent sous un délai d'attente réseau ne sait pas si la commande existe, alors il réessaie, et sans la clé un réessai devient une seconde commande. Traitez la clé comme l'identité de l'intention, pas de la requête : dérivez-la de la session de checkout plus l'intention, gardez-la pour la durée de vie de la session et réutilisez-la mot pour mot quand vous réessayez après un 429.

Panier pour l'itération, checkout pour l'engagement. La conception des limites de débit est une instruction de conception. Les outils de panier acceptent des requêtes non authentifiées et répondent aux limites les plus hautes. Les outils de checkout sont limités plus durement à chaque palier. Construisez le tour d'achat sur les outils de panier, et n'ouvrez un checkout que lorsque l'acheteur a décidé.

L'escalade comme réponse de premier ordre. Un checkout porte un status et un tableau messages, et chaque message porte une severity. recoverable signifie appeler update_checkout et corriger les données. requires_buyer_input ou requires_buyer_review signifie remettre le continue_url à l'acheteur. Douze lignes de code autour de ces sévérités remplacent une file de soutien, et rien de tout cela n'est un chemin d'échec : 3-D Secure, la création de compte, la vérification d'âge et les verrous de fidélité arrivent tous de la même façon, comme prévu.

Prix, stock, livraison et taxe comme données. Un agent ne peut pas négocier. Chaque réponse devrait porter l'état du checkout, un marqueur de version ou de mise à jour, la devise, et le total réparti entre articles, livraison et taxe. Si la disponibilité ou le coût de livraison ne vivent que dans une page rendue, le checkout échoue au dernier écran, après que l'acheteur a déjà approuvé un total.

Une identité honnête, et un palier que vous pouvez défendre. Dites qui appelle, acceptez l'exigence d'IP de l'acheteur, et concevez pour le palier auquel vous êtes réellement admissible plutôt que pour celui de votre présentation commerciale. L'alternative est d'être bloqué, ce qui est arrivé à Muse chez Amazon.

Un seul débit, plafonné. Le chemin du portefeuille émet un justificatif à usage unique et le marchand le débite une fois. Ne stockez jamais un justificatif fourni par un agent, et n'autorisez jamais un montant que l'acheteur n'a pas vu.

Le cycle de vie des statuts mérite son propre paragraphe, parce que c'est là que le verrou devient un état de protocole au lieu d'un paragraphe dans un prompt.

Agent { # Agent
  d1: circle label:"Checkout session opened"
  d2: rectangle label:"Fix missing data"
  d3: diamond label:"Buyer review required"
  d4: rectangle label:"Complete with the same key"
  d5: circle label:"Order completed"
  d6: circle label:"Session expired"
  d1.handle(right) -> d2.handle(left)
  d2.handle(right) -> d3.handle(left)
  d3.handle(bottom) -> Buyer.f1.handle(top) [label="requires_buyer_review"]
  f1.handle(right) -> f2.handle(left)
  f2.handle(bottom) -> d4.handle(top) [label="Yes"]
  f2.handle(right) -> f4.handle(left) [label="No"]
  f4.handle(bottom) -> d6.handle(top) [label="Abandoned"]
  d4.handle(right) -> d5.handle(left)
}
Buyer { # Buyer
  f1: rectangle label:"Open continue_url and review"
  f2: diamond label:"Buyer approves"
  f4: rectangle label:"Buyer closes the page"
}

Les cinq statuts sont incomplete, requires_escalation, ready_for_complete, completed et canceled. Seul ready_for_complete autorise complete_checkout. Tout le reste se corrige via update_checkout ou part vers l'acheteur via continue_url, et une session que personne ne termine expire. Traitez ces cinq mots dans une instruction switch avant d'écrire un seul prompt, parce que chaque incident de production que j'ai vu dans ce domaine est un sixième cas tombé dans la branche par défaut.

continue_url a aussi des règles qui se lisent comme des conseils de sécurité, parce que c'en est. Analysez-la, refusez tout ce qui n'est pas HTTPS, n'exigez pas que l'hôte corresponde au point de terminaison appelé, puisqu'elle peut légitimement vivre sur le domaine myshopify.com de la boutique, sur son domaine de checkout ou sur shop.app. Ne la partagez qu'avec cet acheteur, et ne la consignez pas dans les journaux.

 

Le catalogue est une entrée non fiable

Une vitrine agentique lit du texte écrit par d'autres : titres, descriptions, corps d'avis, notes de livraison, et sur les places de marché tout ce qu'un vendeur tiers veut bien taper. Ce texte entre dans le contexte du modèle, ce qui en fait une surface d'injection avec un paiement attaché.

La règle est ennuyeuse et absolue. Le contenu du catalogue est une donnée, jamais une instruction. Étiquetez-le comme non fiable avant qu'il atteigne le modèle, passez un classificateur dessus, retirez tout ce qui se lit comme une directive, et vérifiez la sortie avant toute écriture. Muse l'applique par couches, avec les données externes étiquetées comme non fiables, un ensemble de classificateurs d'injection entraînés indépendamment, et des frontières déterministes qui tiennent même si l'on persuade le modèle de mal se comporter. Notez ce qui fait fonctionner cette conception : les couches sont à l'extérieur du modèle. Une instruction de prompt qui dit « ignore les instructions du catalogue » est une quatrième couche que l'attaquant contrôle aussi.

 

Trois façons pour un agent de payer

Le rail décide de ce que le marchand et l'agent peuvent voir, et chaque intégration marchande devrait savoir sur quel rail elle est. Muse tourne sur Link ; l'Agentic Commerce Protocol est la contrepartie côté OpenAI, et la même logique de verrou y réapparaît sous d'autres noms.

Jeton de portefeuille. Shop Pay rend un jeton sécurisé à usage unique. Le marchand le débite une fois, et l'agent ne voit jamais un numéro de carte. Les devises prises en charge incluent USD, CAD, MXN et EUR.

Carte virtuelle de portefeuille. Stripe Link émet une carte virtuelle à usage unique approvisionnée pour l'achat approuvé, et l'agent la saisit dans le formulaire de carte ordinaire du marchand, donc le marchand n'a besoin d'aucun bouton spécial. Link approvisionne la carte au plus grand nombre entier inférieur ou égal au total exact augmenté de cinq unités, et cette marge n'est jamais débitée. C'est pourquoi un marchand n'a pas besoin d'être un marchand Link pour qu'on achète chez lui.

Prise en main du navigateur. Si les deux routes de portefeuille échouent, ou si l'acheteur a une carte enregistrée, l'agent remet le navigateur et l'acheteur tape les détails de paiement sur la page du marchand. Le débit est réel. Le flux reste verrouillé : l'agent relaie les articles, la livraison, le total et la méthode enregistrée, puis attend une confirmation explicite.

Agent { # Agent
  p1: circle label:"Approval covers one purchase"
  p2: diamond label:"Wallet rail available"
  p3: rectangle label:"Mint a single-use credential"
  p4: circle label:"Buyer types the card in the browser"
  p1.handle(right) -> p2.handle(left)
  p2.handle(bottom) -> p3.handle(top) [label="Yes"]
  p3.handle(bottom) -> Merchant.q1.handle(top) [label="Credential"]
  p2.handle(top) -> p4.handle(bottom) [label="No"]
}
Merchant { # Merchant
  q1: rectangle label:"Verify merchant amount and method"
  q2: rectangle label:"Charge once and issue receipt"
  q3: circle label:"Payment settled"
  q1.handle(right) -> q2.handle(left)
  q2.handle(right) -> q3.handle(left)
}

 

Ce qui a cassé Muse en premier, et ce qui vous cassera

Quatre défaillances reviennent, et aucune n'est un bogue au sens ordinaire.

Muse a été bloqué pour son identité. Amazon a commencé à bloquer Muse sur son site le dimanche 20 septembre, douze jours après le lancement et le même week-end que la divulgation publique du zéro-day de Patrick Wardle ; Meta a livré un correctif d'urgence plus de douze heures après la divulgation. La raison évoquée pour le blocage d'Amazon n'était pas la vulnérabilité. L'agent ne s'était pas identifié pendant sa navigation, et Amazon n'avait pas été prévenu à l'avance que Muse accéderait à sa boutique. Le principe d'Amazon était que les applications tierces qui achètent au nom de clients devraient opérer ouvertement et respecter le fait qu'un fournisseur veuille participer ou non. Si votre surface ne peut pas dire qui appelle, attendez-vous à la même réponse, et attendez-la vite.

L'approbation expire avant que l'acheteur agisse. Dix minutes, c'est généreux pour une tape de carte et court pour un défi 3-D Secure sur un nouvel appareil. Le comportement correct est de redémarrer depuis la révision, pas de réutiliser l'approbation périmée, et de dire à l'acheteur pourquoi.

La négociation retire le checkout silencieusement. Le croisement des capacités est une fonctionnalité jusqu'à ce qu'il élague la capacité sur laquelle vous comptiez. Instrumentez la portée négociée que vous avez réellement reçue, comparez-la à ce que vos notes de version promettent, et alertez sur l'écart.

Le chemin navigateur lève une carte de consentement que personne n'attend. Quand un agent pilote un vrai navigateur et atterrit sur une page de checkout, le client peut lever sa propre demande de consentement, distincte de l'approbation de paiement. Certaines équipes y voient une double confirmation et en retirent une des deux. Gardez les deux : l'une appartient au client et couvre le site, l'autre appartient au paiement et couvre le montant.

 

Ordre de livraison

Si vous construisez le côté marchand ce trimestre, l'ordre qui survit à un contact avec une date limite est celui-ci.

  1. Publiez le profil d'entreprise et les surfaces en lecture seule d'abord : le catalogue, puis le panier.
  2. Rendez complete_checkout et cancel_checkout idempotents, et prouvez-le en rejouant la même clé contre une commande de bac à sable.
  3. Retournez requires_escalation avec un continue_url fonctionnel avant d'accepter un seul paiement réel.
  4. Instrumentez la portée négociée et les appels d'outils que vous recevez réellement, puis réconciliez-les avec vos notes de version.
  5. Ensuite seulement, exposez la conclusion de checkout, et seulement à un palier que vous pouvez défendre.

Pour un marchand Shopify, la décision est surtout prise pour vous : le checkout direct via Meta est actif par défaut pour les boutiques admissibles, il peut être désactivé, et une fois désactivé les acheteurs sont simplement redirigés vers votre vitrine. L'admissibilité dépend du pays où vous vendez, et le Canada figure sur la liste. Ce qui n'est pas décidé pour vous, c'est la conversation interne : est-ce que votre politique de retour, vos données de stock et vos promesses d'exécution survivent à un acheteur qui ne voit jamais votre site.

 

En résumé

  • Le verrou de Muse est le protocole. Cinq étapes, seules les deux dernières déplacent de l'argent, et la permission de dépenser est liée à un marchand, un montant et une méthode pendant une dizaine de minutes.
  • Le côté marchand est un contrat négocié à quatre familles. Le catalogue pour la découverte, le panier pour l'itération, le checkout pour l'engagement, les commandes pour la preuve. La plupart des équipes inversent les deux du milieu et blâment le modèle.
  • La plupart des défaillances en production sont des défaillances de contrat. Une idempotence manquante, des approbations périmées, un élagage silencieux de capacités, des agents incapables de se nommer, et une branche par défaut qui avale requires_escalation.

 

Sources

Retour à tous les articles du blogue