ChatGPT Merchants y el recorrido del comerciante: del registro a las responsabilidades

1. Qué es un comerciante de ChatGPT y en qué se diferencia de una «tienda normal»

Visto con ojos de desarrollador, es muy fácil confundir niveles: tenemos una app Next.js, un servidor MCP, algún backend de comercio, y por ahí también OpenAI, ChatGPT, Stripe y otros servicios de nivel empresarial. Apetece decir: «Es todo un único sistema grande; lo importante es que los tests estén en verde».

Pero en el mundo del AI‑commerce las fronteras jurídicas y técnicas están muy bien delimitadas. ChatGPT no se convierte en tu tienda ni en tu procesador de pagos. Solo proporciona una interfaz inteligente y llama a tus API siguiendo especificaciones abiertas. El comerciante sigue siendo una empresa concreta con un catálogo concreto y con responsabilidad frente al usuario.

Comprender el papel del comerciante no es solo para juristas. De ello dependen decisiones de arquitectura: dónde se guardan los datos del feed, cómo validas los pedidos, qué registras en los logs, cómo depuras discrepancias entre lo que se muestra en el chat y lo que realmente ocurrió en tu sistema.

Ejemplo

Imaginemos un e‑commerce clásico: tienes un sitio web, un carrito, un checkout, integración con un proveedor de pagos. El usuario entra desde el navegador, hace clic con el ratón, introduce los datos de la tarjeta — todo claro.

Un comerciante de ChatGPT es la misma tienda, solo que aprendió a vender mediante un diálogo con IA con un alto grado de automatización. La diferencia no está en qué vendes, sino en cómo el usuario recorre el camino desde la petición hasta el pago.

Desde el punto de vista de OpenAI, un comerciante es una organización (o un autónomo) que:

• proporciona un Product Feed según la especificación de OpenAI (CSV/TSV/XML/JSON con datos estructurados sobre SKUs);
• se registra en el portal ChatGPT Merchants y supera la revisión de categorías y requisitos legales;
• en la variante avanzada implementa Agentic Checkout y Delegated Payment, para que Instant Checkout en ChatGPT pueda completar el pago sin salir a tu sitio.

Es decir, el comerciante no es «la persona que hizo un widget», sino el propietario del surtido y de las obligaciones financieras. En nuestro curso jugamos dos roles a la vez: somos el equipo que escribe GiftGenius como ChatGPT App, y el equipo que construye el backend del comerciante que atiende esa app.

2. Portal ChatGPT Merchants: recorrido desde la solicitud hasta el comerciante en producción

OpenAI tiene un sitio aparte para vendedores — el portal ChatGPT Merchants. A través de él los vendedores entran en el programa Instant Checkout y conectan sus feeds y backend. Veamos este recorrido por pasos, sin entrar aún en detalles técnicos profundos (eso será en la próxima lección).

Preparación previa

Antes de que alguien de tu equipo pulse «Apply», ya deberíais tener varios ladrillos:

Entidad legal y sitio web. El comerciante tiene un dominio y un storefront comprensible para el usuario — incluso si luego todo se vende a través de ChatGPT, OpenAI espera que exista un escaparate público.

Surtido conforme a la política. En la lección anterior hablamos de la Prohibited Products Policy: no se permiten, por ejemplo, armas o determinados productos médicos. Cualquier artículo que quieras vender a través de ChatGPT debe encajar en la lista de categorías permitidas.

Infraestructura de pagos básica. Aunque Delegated Payment te quite la necesidad de trabajar directamente con tarjetas, debes tener integración con un PSP (por ejemplo, Stripe) y entender cómo creas pedidos y devoluciones en tu sistema.

Solicitud en el portal Merchants

Desde el punto de vista técnico es un paso bastante aburrido, pero importante: entras en el sitio y solicitas participar en el programa Instant Checkout. Normalmente preguntan:

• quién eres (persona jurídica, sitio, contactos);
• qué vendes (categorías, rango de precios, regiones);
• de qué forma estás listo para ofrecer el Product Feed (formato, URL, periodicidad de actualización).

Esta parte tiene poco que ver con TypeScript, pero afecta mucho a tu hoja de ruta: mientras el comerciante no haya pasado la verificación básica, no se activará ningún Instant Checkout, aunque tengas código perfecto.

Conexión del Product Feed

Una vez revisada la solicitud y en general aceptada, el foco técnico principal se desplaza al Product Feed. Según la documentación, el feed es obligatorio para la integración: sin él, ChatGPT simplemente no sabe qué vendes.

En este paso tú:

1. Determinas el formato del feed (lo más habitual es CSV o JSON).
2. Acuerdas cómo lo vas a servir: puede ser un pre‑signed URL en S3 o un endpoint HTTPS al que publiques actualizaciones periódicamente por POST.
3. Preparas el mínimo de campos para cada SKU: id, title, description, price, currency, availability, link, imágenes y flags enable_search / enable_checkout.

Mientras estableces enable_checkout = false, el comerciante puede trabajar en modo solo descubrimiento: ChatGPT encuentra y recomienda productos, pero al intentar comprar envía al usuario a tu sitio.

Integración ACP (más en la próxima lección)

Cuando el Product Feed es estable y estás listo para avanzar, comienza la integración de Agentic Checkout y Delegated Payment. Desde el punto de vista del portal Merchants es un bloque de requisitos aparte: hay que implementar los endpoints /checkout_sessions, aprender a aceptar el token de pago delegado (Shared Payment Token) y finalizar correctamente las sesiones con los estados adecuados (not_ready_for_payment, ready_for_payment, completed, canceled).

En esta lección solo lo mencionamos como «el siguiente nivel de dificultad». Todos los detalles del protocolo y los esquemas de solicitudes los veremos en la próxima lección.

3.5. Certificación y activación de Instant Checkout

La etapa final es comprobar cómo se comporta tu backend en escenarios reales:

• si los pedidos se crean correctamente;
• si coinciden los precios del feed con los precios a los que realmente cobras;
• si se gestionan adecuadamente los errores y las devoluciones;
• si tus páginas de Términos de servicio y Política de privacidad cumplen con las expectativas de OpenAI y el derecho local.

Después de esto, el comerciante obtiene el estado «listo para Instant Checkout» y sus productos con enable_checkout = true pasan a poder comprarse directamente en ChatGPT.

Todo esto se puede imaginar mentalmente en forma de un diagrama simple:

flowchart TD
  A[Hay producto y sitio] --> B[Solicitud en ChatGPT Merchants]
  B --> C[Product Feed conectado]
  C --> D["ACP backend implementado
(checkout_sessions + delegated payment)"]
  D --> E[Certificación
y activación de Instant Checkout]

3. Variantes de comerciante: Etsy/Shopify vs backend a medida

La buena noticia: no todos los comerciantes están obligados a escribir por sí mismos todo el backend de ACP. Para algunas plataformas (Shopify, Etsy, etc.) ya existen integraciones que asumen la implementación técnica.

Si vendes a través de Shopify o Etsy, el esquema es aproximadamente así: activas en ellos una opción tipo «Show in ChatGPT», y la plataforma por sí misma:

• forma y mantiene el Product Feed en el formato necesario;
• implementa o hace proxy de los endpoints de ACP;
• se conecta con Stripe u otro PSP.

Tú, como propietario de la tienda, te ocupas más del surtido y de las descripciones que de los endpoints REST.

Si, como en nuestro curso con GiftGenius, construyes un comerciante a medida con su propio backend, entonces tienes mucha más libertad, pero también más trabajo: escribes tú mismo el código que implementa el feed, el checkout y la integración con el proveedor de pagos.

Es útil compararlo en forma de tabla:

Para el curso elegimos conscientemente la tercera opción: solo así podemos recorrer todo el camino desde el feed hasta los webhooks y un producto fiable en producción.

4. Responsabilidades del comerciante: datos, pedidos, política, dinero

Cuando te conviertes en comerciante de ChatGPT, no solo te apuntas a la alegría de los nuevos pedidos, sino también a un conjunto de obligaciones muy concretas. Vamos a desglosarlas por capas.

Datos de catálogo y calidad del Product Feed

El Product Feed es la fuente de la verdad para ChatGPT. Si en él se indica que un artículo cuesta 10 USD y está disponible, eso es exactamente lo que verá el usuario en el chat. Si el feed miente, en el mejor de los casos obtendrás un cliente descontento; en el peor, una infracción de políticas y problemas con OpenAI.

Se espera del comerciante:

• corrección de los campos obligatorios (formato correcto del precio, códigos de moneda ISO, enlaces HTTPS válidos, imágenes funcionales);
• actualización del feed con suficiente frecuencia para no vender artículos fantasma;
• consistencia de identificadores: el id del SKU en el feed debe coincidir con el ID en tu base de datos y en el sistema de pedidos, para que puedas entender de manera inequívoca qué se compró.

Si hacemos un paralelismo con el e‑commerce habitual, aquí el Product Feed es tu «exportación al marketplace», solo que el marketplace en este caso no es un sitio, sino un asistente inteligente que vive en la cabeza del usuario y recuerda fácilmente las incongruencias.

Pedidos, envío y devoluciones

ChatGPT no se convierte en el servicio de soporte de tu tienda. El usuario, por supuesto, habla con él, pero jurídicamente compra el producto al comerciante, no a OpenAI. Por lo tanto:

• respondes de que el pedido se cree en tu sistema y llegue al almacén;
• respondes de que el envío llegue a la dirección indicada por el usuario en Instant Checkout;
• respondes de gestionar devoluciones, cancelaciones, devoluciones parciales, etc.

En el marco de ACP, la checkout_session tras completarse con éxito suele contener un objeto order con sus campos. Pero esto solo refleja lo que ocurrió en tu backend — tú decides cómo es el registro en la tabla orders, qué estados existen y cómo se relacionan con la logística.

Política y geografía

En el portal Merchants indicas en qué países vendes y qué tipos de productos. OpenAI, por su parte, comprueba que:

• no vendas categorías prohibidas;
• cumplas con el derecho local (por ejemplo, normas fiscales y restricciones de edad);
• proporciones Términos de servicio y Política de privacidad comprensibles.

En módulos posteriores volveremos a hablar de las páginas legales, pero ya ahora es útil pensar en términos de: «Si no puedo explicar al abogado qué vendo exactamente y dónde, es poco probable que ChatGPT lo venda por mí».

Dinero y proveedor de pagos

Por fin, lo más delicado: el dinero. Por suerte, ACP y Delegated Payment simplifican mucho la vida del desarrollador:

• ChatGPT y el proveedor de pagos (por ejemplo, Stripe) acuerdan un Shared Payment Token para un importe concreto y para un comerciante concreto;
• tu backend recibe ese token en la solicitud complete y lo usa en tu PSP, sin ver datos «en crudo» de la tarjeta.

Es decir, no te conviertes en un monstruo compatible con PCI, no guardas números de tarjeta y no te metes en las pesadillas de auditoría. Tu responsabilidad es usar correctamente el token delegado (crear el pago, cobrar, realizar devoluciones) y llevar la contabilidad con cuidado.

5. Cómo encaja esto en la arquitectura de GiftGenius

Volvamos a nuestra app educativa GiftGenius. A nivel de arquitectura, después del módulo 14 queremos que el estudiante pueda dibujar un esquema del tipo: «Usuario → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend».

En este esquema, el papel del comerciante se implementa en nuestro backend, y el widget y la App son solo la «cara» de ese comerciante en ChatGPT.

Configuración del comerciante en el código

Empecemos por un paso sencillo: definamos en el código una estructura de configuración del comerciante. Que sea un módulo de TypeScript lib/merchantConfig.ts en nuestro proyecto Next.js:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID del comerciante en ACP/Stripe
  name: string;              // Nombre legible por humanos
  feedUrl: string;           // Dónde está el 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, // lo activaremos más tarde
};

Aquí, en primer lugar, fijamos explícitamente los límites: esto es un comerciante, no un «widget». En segundo lugar, extraemos valores importantes a variables de entorno — en los módulos sobre despliegue y entornos volveremos más de una vez a por qué no conviene hardcodear este tipo de cosas.

Para mayor comodidad, puedes añadir una función simple que diga a nuestro código si ahora se puede usar Instant Checkout:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // En dev y staging siempre desactivamos Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

Así preparamos de antemano la arquitectura para que el comportamiento sea distinto según el entorno y evitamos que nosotros (y GPT) nos vayamos por accidente a un checkout de producción desde un entorno de pruebas.

MCP‑tool para obtener información del comerciante

A menudo es útil dar a la modelo y al widget la posibilidad de saber en qué modo funciona ahora el comerciante. Por ejemplo, para que GPT no proponga Instant Checkout si está desactivado.

En el servidor MCP (que levantamos en módulos anteriores) se puede definir una herramienta sencilla:

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

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Devuelve información básica sobre el comerciante GiftGenius",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

Esta herramienta no hace nada increíble, pero crea un lugar explícito donde la modelo puede preguntar: «¿Se puede comprar ahora mismo en el chat o solo seguir un enlace?».

Uso de la información del comerciante en el widget

En el lado del widget, usando los hooks ya conocidos del Apps SDK, puedes llamar a get_merchant_info y cambiar el UI según el modo. Un ejemplo mínimo de componente:

// 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 componente pequeño como este subraya agradablemente al usuario (y a ti mismo en modo dev) en qué estado se encuentra la integración con ChatGPT.

6. Mini‑ejercicio práctico

Para que la lección no se quede solo en «palabras y diagramas», intenta realizar los siguientes pasos en tu proyecto GiftGenius (o similar):

Primero, añade un módulo de configuración del comerciante, parecido a merchantConfig.ts, y extrae MERCHANT_ID y PRODUCT_FEED_URL a variables de entorno. Para desarrollo local puedes usar .env.local, y para production — la configuración de Vercel u otra plataforma.

Segundo, implementa en el servidor MCP una herramienta sencilla get_merchant_info que devuelva al menos name e instantCheckout. Piensa qué otros campos podrían ser útiles para la modelo: por ejemplo, la lista de monedas admitidas o países de envío.

Tercero, añade en el widget un pequeño elemento de UI (badge, línea de estado, etiqueta en la tarjeta del producto) que use este tool y muestre al usuario en qué modo funciona ahora tu comerciante: solo recomendaciones o ya con Instant Checkout completo. Esto no solo es útil para el UX, sino que también ayuda mucho a la depuración.

Por último, intenta describir por escrito qué pasos seguirá tu proyecto concreto desde «tenemos sitio y backend» hasta el estatus de comerciante de ChatGPT. Dónde exactamente conectarás el Product Feed, cuándo activarás enable_checkout, cuándo empezarás la implementación de los endpoints de ACP. Este ejercicio disciplina y ayuda a no olvidar cosas importantes pero poco agradables como la política de devoluciones.

7. Errores típicos en el camino hacia ser comerciante de ChatGPT

Error nº 1: «ChatGPT es mi tienda».
A veces los desarrolladores «trasladan» mentalmente todo al lado de ChatGPT: como si guardara el catálogo, calculase los precios y ejecutase los pedidos. En realidad, ChatGPT es una interfaz y un orquestador, no tu ERP. Si lo olvidas, es fácil construir una arquitectura sin un modelo propio de pedidos, con todos los datos viviendo «en prompts», y cualquier cambio en el comportamiento del modelo pone en riesgo la consistencia.

Error nº 2: esperar Instant Checkout sin registro aparte ni ACP.
El hecho de que hayas escrito un gran widget y configurado el Product Feed no activa automáticamente Instant Checkout. Hacen falta una solicitud en el portal Merchants, revisión de categorías, implementación de Agentic Checkout y Delegated Payment, y pasar pruebas. Intentar contar con Instant Checkout «por defecto» suele acabar con GPT ofreciendo al usuario lo que en realidad no existe, o dando enlaces en lugar de las pantallas de pago esperadas.

Error nº 3: hardcode rígido de identificadores y URL del comerciante.
La historia clásica: MERCHANT_ID = "prod-123" está escrito directamente en el código, y la URL del feed es una cadena en el componente del widget. En cuanto necesitas un staging o dar de alta a un segundo comerciante, empieza la búsqueda y reemplazo masiva. Es mucho más seguro extraer estas cosas a configuración y variables de entorno y usarlas a través de una pequeña capa de abstracción, como hicimos con MerchantConfig.

Error nº 4: el Product Feed va por libre, sin relación con los pedidos.
Si en el feed el SKU GIFT_RED_MUG cuesta 10 USD, y en la base de pedidos para ese mismo identificador por algún motivo cobras 12 USD, tarde o temprano saldrá a la luz. La fuente de la verdad sobre precios y stock debe ser o bien el feed, construido a partir de tus datos internos, o una capa común en la que confíen tanto el feed como el checkout. Intentar llevar una «contabilidad doble» (una para ChatGPT y otra para tu sitio) se te volverá en contra muy rápido.

Error nº 5: ignorar el papel del proveedor de pagos y el almacenamiento de datos de pago.
A veces surge la tentación de «husmear» el token del proveedor de pagos o incluso pedir datos de pago adicionales al usuario en tu propio UI. Eso no solo viola el modelo de Delegated Payment, sino que puede arrastrarte al mundo de PCI DSS y un compliance pesado. La práctica correcta es tratar el Shared Payment Token como una cadena opaca, usarlo únicamente en el SDK del proveedor de pagos y no registrarlo en logs ni cachearlo en ningún sitio.

Error nº 6: subestimar lo multietapa del onboarding y la ausencia de un plan.
Por último, un error organizativo frecuente es pensar que «nos conectamos a ChatGPT y ya está, qué complicado puede ser». En realidad, el recorrido del comerciante consta de muchos pasos: técnicos (feed, backend, pruebas) y no técnicos (documentos legales, acuerdo de categorías, restricciones regionales). Si no planeas este recorrido por adelantado, el equipo saltará caóticamente entre tareas y los plazos empezarán a «derretirse» más rápido que tu entusiasmo por el AI‑commerce.