ChatGPT Merchants et le parcours du marchand: de l’inscription aux responsabilités

1. Qu’est‑ce qu’un marchand ChatGPT et en quoi diffère‑t‑il d’une « boutique ordinaire »

Si l’on regarde avec les yeux d’un développeur, il est très facile de confondre les niveaux: nous avons une application Next.js, un serveur MCP, un backend commerce quelconque, et quelque part OpenAI, ChatGPT, Stripe et d’autres services “adultes”. On a envie de dire: « Tout ça forme un seul grand système, l’essentiel est que les tests soient au vert ».

Mais dans le monde de l’AI‑commerce, les frontières juridiques et techniques sont délimitées très strictement. ChatGPT ne devient pas votre boutique et ne se transforme pas en processeur de paiements. Il ne fournit qu’une interface intelligente et appelle vos API selon des spécifications ouvertes. Le marchand reste une entreprise concrète avec un catalogue concret et une responsabilité claire vis‑à‑vis de l’utilisateur.

Comprendre le rôle du marchand n’est pas utile qu’aux juristes. Il conditionne des décisions d’architecture: où sont stockées les données du feed, comment vous validez les commandes, ce que vous journalisez, comment vous déboguez les écarts entre ce qui est affiché dans le chat et ce qui s’est réellement produit dans votre système.

Exemple

Imaginons un e‑commerce classique: vous avez un site, un panier, un checkout, une intégration avec un prestataire de paiement. L’utilisateur va dans le navigateur, clique à la souris, saisit les données de sa carte — tout est clair.

Le marchand ChatGPT — c’est la même boutique, mais qui a appris à vendre via un dialogue IA avec un haut degré d’automatisation. La différence ne porte pas sur ce que vous vendez, mais sur la manière dont l’utilisateur passe de la requête au paiement.

Du point de vue d’OpenAI, un marchand est une organisation (ou un entrepreneur individuel) qui:

• fournit un Product Feed selon la spécification OpenAI (CSV/TSV/XML/JSON avec des données structurées sur les SKU);
• s’inscrit sur le portail ChatGPT Merchants et passe la vérification des catégories et des exigences juridiques;
• dans une version avancée, implémente Agentic Checkout et Delegated Payment afin que l’Instant Checkout dans ChatGPT puisse effectuer le paiement sans rediriger vers votre site.

Autrement dit, un marchand n’est pas « la personne qui a écrit un widget », mais le propriétaire de l’assortiment et des obligations financières. Dans notre cours, nous jouons deux rôles à la fois: nous sommes l’équipe qui écrit GiftGenius en tant que ChatGPT App et l’équipe qui construit le backend du marchand qui sert cette App.

2. Portail ChatGPT Merchants: du dépôt de candidature au marchand en production

OpenAI dispose d’un site séparé pour les vendeurs — le portail ChatGPT Merchants. C’est par lui que les vendeurs rejoignent le programme Instant Checkout et connectent leurs feeds et backend. Parcourons ce chemin étape par étape, sans encore entrer dans les détails techniques poussés (ce sera dans la prochaine leçon).

Préparation préalable

Avant que quelqu’un de votre équipe n’appuie sur le bouton « Apply », vous devez déjà avoir quelques briques:

Entité juridique et site. Un marchand dispose d’un domaine et d’une vitrine claire pour l’utilisateur — même si la suite se vend via ChatGPT, OpenAI s’attend à l’existence d’une vitrine publique.

Assortiment conforme à la politique. Dans la leçon précédente, nous avons parlé de la Prohibited Products Policy: armes interdites, certains produits médicaux, etc. Tout produit que vous souhaitez vendre via ChatGPT doit s’inscrire dans la liste des catégories autorisées.

Infrastructure de paiement de base. Même si Delegated Payment vous évite de manipuler directement les cartes, vous devez avoir une intégration avec un PSP (Stripe, par exemple) et comprendre comment vous créez des commandes et des remboursements dans votre système.

Candidature dans le portail Merchants

D’un point de vue technique, c’est une étape assez monotone mais importante: vous allez sur le site et déposez une candidature pour participer au programme Instant Checkout. En général, on vous demande:

• qui vous êtes (personne morale, site, contacts);
• ce que vous vendez (catégories, fourchette de prix, régions);
• de quelle manière vous êtes prêt à fournir le Product Feed (format, URL, fréquence de mise à jour).

Cette partie a peu à voir avec TypeScript, mais impacte fortement votre roadmap: tant que le marchand n’a pas passé la vérification de base, aucun Instant Checkout ne sera activé, même si votre code est parfait.

Connexion du Product Feed

Une fois la candidature examinée et globalement acceptée, le focus technique se déplace vers le Product Feed. Selon la documentation, le feed est obligatoire pour l’intégration: sans lui, ChatGPT ne sait tout simplement pas ce que vous vendez.

À cette étape, vous:

1. Déterminez le format du feed (le plus souvent CSV ou JSON).
2. Concordez la manière de le fournir: cela peut être une URL pré‑signée sur S3 ou un endpoint HTTPS vers lequel vous envoyez périodiquement des mises à jour en POST.
3. Préparez un minimum de champs pour chaque SKU: id, title, description, price, currency, availability, link, images et indicateurs enable_search / enable_checkout.

Tant que vous mettez enable_checkout = false, le marchand peut fonctionner en mode « découverte uniquement »: ChatGPT trouve et recommande des produits, mais au moment de l’achat envoie l’utilisateur sur votre site.

Intégration ACP (détails dans la prochaine leçon)

Quand le Product Feed est stable et que vous êtes prêt à aller plus loin, commence l’intégration Agentic Checkout et Delegated Payment. Du point de vue du portail Merchants, c’est un bloc d’exigences séparé: il faut implémenter les endpoints /checkout_sessions, apprendre à accepter le jeton de paiement délégué (Shared Payment Token) et terminer correctement les sessions avec les statuts requis (not_ready_for_payment, ready_for_payment, completed, canceled).

Dans cette leçon, nous n’en parlons que comme d’un « niveau de complexité suivant ». Tous les détails du protocole et les schémas de requêtes seront abordés dans la prochaine leçon.

3.5. Certification et activation d’Instant Checkout

Dernière étape — vérifier comment votre backend se comporte dans des scénarios réels:

• les commandes sont‑elles créées correctement;
• les prix du feed coïncident‑ils avec ceux réellement débités;
• les erreurs et les remboursements sont‑ils traités correctement;
• vos pages de Conditions d’utilisation et de Politique de confidentialité répondent‑elles aux attentes d’OpenAI et du droit local.

Après cela, le marchand obtient le statut « prêt pour Instant Checkout » et ses produits avec enable_checkout = true deviennent réellement achetables directement dans ChatGPT.

On peut se représenter tout cela sous forme d’un schéma simple:

flowchart TD
  A[Produit et site en place] --> B[Candidature sur ChatGPT Merchants]
  B --> C[Product Feed connecté]
  C --> D["Backend ACP réalisé
(checkout_sessions + delegated payment)"]
  D --> E[Certification
et activation d’Instant Checkout]

3. Variantes de marchands: Etsy/Shopify vs backend personnalisé

Bonne nouvelle: tous les marchands ne sont pas obligés d’écrire eux‑mêmes tout le backend ACP. Pour certaines plateformes (Shopify, Etsy, etc.), il existe déjà des intégrations qui prennent en charge la réalisation technique.

Si vous vendez via Shopify ou Etsy, le schéma est à peu près le suivant: vous activez chez eux une option du type « Show in ChatGPT », et la plateforme se charge elle‑même de:

• former et maintenir le Product Feed au bon format;
• implémenter ou proxifier les endpoints ACP;
• s’interfacer avec Stripe ou un autre PSP.

Vous, en tant que propriétaire de la boutique, vous occupez davantage de l’assortiment et des descriptions que des endpoints REST.

Si, comme dans notre cours avec GiftGenius, vous construisez un marchand personnalisé avec votre propre backend, vous avez beaucoup plus de liberté, mais aussi plus de travail: vous écrivez vous‑même le code qui réalise le feed, le checkout et l’intégration avec le prestataire de paiement.

Pratique de comparer cela sous forme de tableau:

Pour le cours, nous choisissons délibérément la troisième option: c’est la seule manière de parcourir tout le chemin du feed aux webhooks et jusqu’à un véritable production fiable.

4. Responsabilité du marchand: données, commandes, politique, argent

Quand vous devenez marchand ChatGPT, vous signez non seulement pour la joie de nouvelles commandes, mais aussi pour un ensemble d’obligations très concrètes. Décomposons‑les par couches.

Données de catalogue et qualité du Product Feed

Le Product Feed est la source de vérité pour ChatGPT. S’il indique qu’un produit coûte 10 USD et est en stock, c’est exactement ce que verra l’utilisateur dans le chat. Si le feed ment, au mieux vous aurez un client mécontent, au pire — une violation de politique et des problèmes avec OpenAI.

On attend du marchand:

• la correction des champs obligatoires (format de prix correct, codes ISO des devises, liens HTTPS valides, images fonctionnelles);
• une mise à jour suffisamment fréquente du feed pour ne pas vendre un produit fantôme;
• la cohérence des identifiants: l’id du SKU dans le feed doit correspondre à l’ID de votre base et de votre système de commandes, afin que vous puissiez comprendre sans ambiguïté ce qui a été acheté.

Par analogie avec l’e‑commerce classique, ici le Product Feed — c’est votre « export vers une place de marché », sauf que la place de marché n’est pas un site, mais un assistant intelligent qui vit dans la tête de l’utilisateur et mémorise facilement les incohérences.

Commandes, livraison et retours

ChatGPT ne devient pas le service client de votre boutique. L’utilisateur discute certes avec lui, mais juridiquement il achète le produit au marchand, et non à OpenAI. Donc:

• vous êtes responsable de la création de la commande dans votre système et de son acheminement jusqu’à l’entrepôt;
• vous êtes responsable de la livraison à l’adresse indiquée par l’utilisateur dans Instant Checkout;
• vous êtes responsable du traitement des retours, annulations, remboursements partiels, etc.

Dans le cadre d’ACP, une checkout_session après réussite contient généralement un objet order avec ses champs. Mais ce n’est qu’un reflet de ce qui s’est passé dans votre backend — c’est vous qui décidez de la forme de l’enregistrement dans la table orders, des statuts disponibles et de leur lien avec la logistique.

Politiques et géographie

Dans le portail Merchants, vous indiquez dans quels pays vous vendez et quels types de produits. OpenAI, de son côté, vérifie que vous:

• ne vendez pas de catégories interdites;
• respectez le droit local (par exemple, les règles fiscales et les restrictions d’âge);
• fournissez des Conditions d’utilisation et une Politique de confidentialité claires.

Dans les modules suivants, nous parlerons encore des pages juridiques, mais il est déjà utile de penser en ces termes: « Si je ne peux pas expliquer à un juriste ce que je vends et où, ChatGPT ne le vendra probablement pas à ma place ».

Argent et prestataire de paiement

Enfin, le plus sensible — l’argent. Heureusement, ACP et Delegated Payment simplifient grandement la vie des développeurs:

• ChatGPT et le prestataire de paiement (par exemple Stripe) conviennent d’un Shared Payment Token pour un montant et un marchand donnés;
• votre backend reçoit ce jeton dans la requête complete et l’utilise chez votre PSP, sans voir les données “brutes” de la carte.

Ainsi, vous ne devenez pas un monstre conforme PCI, vous ne stockez pas de numéros de carte et n’entrez pas dans les cauchemars d’audit. Votre responsabilité — utiliser correctement le jeton délégué (créer un paiement, débiter, effectuer un remboursement) et tenir une comptabilité rigoureuse.

5. Comment cela s’inscrit dans l’architecture de GiftGenius

Revenons à notre application pédagogique GiftGenius. D’un point de vue architectural, après le module 14, nous voulons que l’étudiant puisse dessiner un schéma du type: « Utilisateur → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / backend ACP ».

Dans ce schéma, le rôle du marchand est réalisé dans notre backend, tandis que le widget et l’App ne sont que le « visage » de ce marchand dans ChatGPT.

Configuration du marchand dans le code

Commençons par une étape simple: créons dans le code une structure de configuration du marchand. Supposons un module TypeScript lib/merchantConfig.ts dans notre projet Next.js:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID du marchand dans ACP/Stripe
  name: string;              // Nom lisible par un humain
  feedUrl: string;           // Emplacement du Product Feed
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // on l’activera plus tard
};

Ici, premièrement, nous fixons explicitement les frontières: c’est un marchand, pas un « widget ». Deuxièmement, nous externalisons des valeurs importantes dans des variables d’environnement — dans les modules sur le déploiement et les environnements, nous rappellerons pourquoi il ne faut pas hardcoder ce genre de choses.

Pour plus de confort, on peut ajouter une simple fonction qui indiquera à notre code s’il est possible d’utiliser Instant Checkout en ce moment:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // En dev et en staging, on désactive toujours Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

Ainsi, nous préparons l’architecture au fait que le comportement diffère selon les environnements, et nous empêchons nous‑mêmes (et GPT) de partir accidentellement vers un checkout de production depuis un environnement de test.

Outil MCP pour obtenir des informations sur le marchand

Il est souvent utile de donner au modèle et au widget la possibilité de savoir dans quel mode le marchand fonctionne actuellement. Par exemple, pour que GPT ne propose pas Instant Checkout s’il est désactivé.

Dans le serveur MCP (que nous avons monté dans les modules précédents), on peut créer un outil simple:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Renvoie les informations de base sur le marchand GiftGenius",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

Cet outil ne fait rien d’extraordinaire, mais crée un endroit explicite où le modèle peut demander: « Peut‑on acheter directement dans le chat en ce moment, ou uniquement suivre un lien ? ».

Utilisation des informations marchand dans le widget

Côté widget, en utilisant les hooks Apps SDK que nous connaissons déjà, on peut appeler get_merchant_info et modifier l’UI selon le mode. Exemple minimal de composant:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

Un petit composant de ce type met agréablement en évidence pour l’utilisateur (et pour vous en mode dev) l’état actuel de l’intégration avec ChatGPT.

6. Mini‑exercice pratique

Pour que la leçon ne reste pas au niveau des « mots et schémas », essayez d’effectuer les étapes suivantes dans votre projet GiftGenius (ou équivalent):

Premièrement, ajoutez un module de configuration du marchand, similaire à merchantConfig.ts, et externalisez MERCHANT_ID et PRODUCT_FEED_URL dans des variables d’environnement. Pour le développement local, vous pouvez utiliser .env.local, et pour la production — les paramètres de Vercel ou d’une autre plateforme.

Deuxièmement, implémentez dans le serveur MCP un outil simple get_merchant_info qui renvoie au moins name et instantCheckout. Réfléchissez aux autres champs qui pourraient être utiles au modèle: par exemple, la liste des devises prises en charge ou des pays livrables.

Troisièmement, ajoutez dans le widget un petit élément d’UI (badge, ligne de statut, mention sur la carte produit) qui utilise cet outil et indique à l’utilisateur dans quel mode fonctionne actuellement votre marchand: recommandations uniquement ou déjà un Instant Checkout complet. Ce n’est pas seulement utile pour l’UX, mais aide aussi énormément au débogage.

Enfin, essayez d’écrire textuellement par quelles étapes votre projet concret passera pour aller de « nous avons un site et un backend » jusqu’au statut de marchand ChatGPT. Où vous connecterez le Product Feed, quand vous activerez enable_checkout, quand vous commencerez l’implémentation des endpoints ACP. Cet exercice est très structurant et aide à ne pas oublier les choses peu séduisantes comme la politique de retours.

7. Erreurs typiques sur la voie du marchand ChatGPT

Erreur n° 1: « ChatGPT, c’est mon magasin ».
Parfois les développeurs “déportent” mentalement tout du côté de ChatGPT: comme s’il stockait le catalogue, calculait les prix et exécutait les commandes. En réalité, ChatGPT est une interface et un orchestrateur, pas votre ERP. Si on l’oublie, on conçoit facilement une architecture sans véritable modèle de commandes propre, où toutes les données vivent « quelque part dans des prompts », et le moindre changement de comportement du modèle menace la cohérence.

Erreur n° 2: attendre Instant Checkout sans inscription séparée ni ACP.
Le fait d’avoir écrit un excellent widget et configuré un Product Feed n’active pas automatiquement Instant Checkout. Il faut une candidature dans le portail Merchants, une vérification des catégories, l’implémentation d’Agentic Checkout et de Delegated Payment, et le passage des tests. Parier sur Instant Checkout « par défaut » se termine en général par un GPT qui propose à l’utilisateur ce qui n’existe pas vraiment, ou fournit des liens à la place d’écrans de paiement attendus.

Erreur n° 3: hardcoder brutal des identifiants et des URL du marchand.
Histoire classique: MERCHANT_ID = "prod-123" est écrit en dur dans le code, l’URL du feed — une chaîne dans le composant du widget. Dès que vous ajoutez un staging ou qu’il faut créer un second marchand, c’est la chasse au “rechercher‑remplacer”. Il est bien plus sûr d’externaliser ces éléments dans la configuration et les variables d’environnement, et de les utiliser via une petite couche d’abstraction, comme nous l’avons fait avec MerchantConfig.

Erreur n° 4: le Product Feed vit sa propre vie, déconnectée des commandes.
Si, dans le feed, le SKU GIFT_RED_MUG est à 10 USD, mais que, dans la base des commandes pour le même identifiant, vous débitez 12 USD pour une raison quelconque, cela finira par ressortir. La source de vérité sur les prix et la disponibilité doit être soit le feed construit depuis vos données internes, soit une couche commune à laquelle font confiance à la fois le feed et le checkout. Tenter de tenir une « double comptabilité » (une pour ChatGPT, une autre pour votre site) se retourne très vite contre vous.

Erreur n° 5: ignorer le rôle du prestataire de paiement et la conservation des données de paiement.
La tentation peut apparaître de « jeter un œil » dans le jeton du prestataire de paiement ou même de demander des coordonnées de paiement supplémentaires dans votre UI. Non seulement cela viole le modèle de Delegated Payment, mais cela peut aussi vous entraîner dans l’univers PCI DSS et un compliance lourd. La bonne pratique — considérer le Shared Payment Token comme une chaîne opaque, l’utiliser uniquement dans le SDK du prestataire de paiement, et ne jamais le journaliser ni le mettre en cache.

Erreur n° 6: sous‑estimer la nature multi‑étapes de l’onboarding et l’absence de plan.
Enfin, une erreur d’organisation fréquente — penser que « nous allons juste nous connecter à ChatGPT, rien de sorcier ». En réalité, le parcours du marchand se compose de nombreuses étapes: techniques (feed, backend, tests) et non techniques (documents juridiques, validation des catégories, restrictions régionales). Sans planifier ce parcours à l’avance, l’équipe saute de manière chaotique entre les tâches, et les délais fondent plus vite que votre enthousiasme pour l’AI‑commerce.