Panorama del AI‑commerce y el papel de OpenAI

1. Qué es exactamente el AI‑commerce

Si el e‑commerce clásico es la historia de «entras en la web — abres el catálogo — añades al carrito — pasas por tres formularios», el AI‑commerce es cuando la interfaz principal pasa a ser el diálogo con ChatGPT. El usuario formula la tarea en lenguaje natural y el agente dentro de ChatGPT asume el papel de consultor, especialista en merchandising y, en parte, product manager.

Las consultas no se ven como «category=calcetines&price_max=20», sino como «encuentra un regalo gracioso, pero no demasiado vergonzoso, para un compañero por hasta 20 dólares que se pueda enviar por correo electrónico». El agente interpreta la tarea, hace preguntas de aclaración, consulta el catálogo de productos, explica pros y contras de las opciones y luego guía al usuario hasta la compra; y todo ello sin que el usuario vea el «carrito» como una página aparte.

Desde el punto de vista de la arquitectura, la ChatGPT App en ese momento deja de ser un «catálogo de regalos inteligente» para convertirse en una aplicación de commerce capaz de:

1. Entender la intención del usuario y las restricciones (presupuesto, tipo de regalo, país, producto digital/físico).
2. Seleccionar SKU concretos del product feed y justificar la elección.
3. Iniciar la compra a través del protocolo estandarizado ACP (Agentic Commerce Protocol).

La idea del AI‑commerce es que «catálogo + checkout» dejan de ser un sitio independiente y pasan a ser una continuación lógica del diálogo que el usuario ya mantiene con GPT.

2. E‑commerce clásico frente a AI‑commerce

Para notar mejor la diferencia, conviene poner ambos enfoques uno al lado del otro. A continuación verás una tabla simplificada que no pretende cubrirlo todo, pero resalta bien el cambio de paradigma.

Consecuencia práctica: en AI‑commerce la atención se desplaza del diseño visual del «catálogo y carrito» a la estructura y calidad de los datos, así como al protocolo formal de interacción entre ChatGPT, tu backend y el proveedor de pagos. El product feed y los endpoints de ACP se convierten en un «UI» tan importante como el propio widget.

Si en una tienda clásica puedes corregir parte del UX en el navegador, en AI‑commerce el modelo se apoya casi por completo en los datos y esquemas que le diste: desde la descripción del producto hasta los estados de la sesión de checkout.

3. Bloques de construcción de OpenAI Commerce

OpenAI no ofrece «un sistema de pagos mágico GPTPay» que lo haga todo por sí solo. En su lugar, hay un conjunto de especificaciones y guías que describen cómo conectar correctamente a los comerciantes y proveedores de pagos existentes con el mundo de ChatGPT. De estos documentos, para nosotros son especialmente importantes cuatro ladrillos.

En primer lugar, la Product Feed Specification. Es el formato oficial en el que el vendedor describe su catálogo de productos: id, title, description, precio, divisa, disponibilidad, imágenes, etc. El feed actúa como «fuente de verdad estructurada» que OpenAI valida, indexa y utiliza para búsqueda, ranking y checkout dentro de ChatGPT.

En segundo lugar, la Agentic Checkout Specification. Es un contrato REST para trabajar con la entidad checkout_session: El API describe cómo crear una sesión de pago, actualizarla (por ejemplo, al cambiar la dirección o la opción de envío) y completarla, así como qué campos debe devolver tu backend (importes, impuestos, opciones de fulfillment, enlaces a la política de devoluciones, etc.).

En tercer lugar, la Delegated Payment Specification. Es el protocolo mediante el cual la plataforma del agente (ChatGPT) recibe del proveedor de pagos un token de pago delegado (por ejemplo, Stripe Shared Payment Token) y lo transmite a tu backend sin revelar los datos de pago. Este token está limitado por importe, tiempo de vida y otros parámetros, y tu backend lo usa para crear el pago real en el PSP.

Y por último, el Instant Checkout en ChatGPT es una capa de UX sobre estas especificaciones. Dentro del chat aparece una interfaz de checkout compacta: producto seleccionado, precio, dirección, método de pago. Bajo el capó se apoya en el Product Feed, llama a tus /checkout_sessions según la Agentic Checkout Spec y utiliza Delegated Payment para ejecutar la transacción en el PSP.

La buena noticia es que todo esto no es un «API secreto de ChatGPT», sino especificaciones abiertas del ACP (Agentic Commerce Protocol). Esto significa que el mismo backend podría funcionar teóricamente con otras plataformas de IA si también soportan ACP.

4. Roles y límites de responsabilidad

Aquí empieza lo más interesante: cuando entran en juego el dinero, los reguladores y los abogados se convierten de repente en tus mejores amigos. Para no liarse, es importante separar claramente los roles.

El rol más importante es el de la plataforma del agente, en nuestro caso, ChatGPT. Es quien posee la experiencia de usuario: chat, widgets, Instant Checkout UI. La plataforma inicia el flujo de commerce, elige productos del Product Feed, llama a tus endpoints ACP y muestra el resultado al usuario. Pero, aun así, ChatGPT no se convierte ni en propietario del producto ni en proveedor de pagos y no almacena tus datos de producto como «su propio catálogo»; utiliza exactamente el feed que tú le entregas.

El segundo rol es el del comerciante (seller, merchant‑of‑record). Es el propietario de los productos o servicios. El comerciante es responsable del propio product feed (estructura, calidad, actualización de precios y disponibilidad), de la implementación correcta de los endpoints ACP (/checkout_sessions, webhooks), de la creación y almacenamiento de pedidos, de la entrega, soporte y devoluciones. La documentación de ACP recalca que el comerciante sigue siendo el vendedor de registro en sentido jurídico, no la plataforma del agente.

El tercer rol es el del proveedor de pagos (PSP), por ejemplo, Stripe. El PSP se encarga del procesamiento de pagos, del cumplimiento de PCI DSS y otros requisitos, del almacenamiento de los datos de pago, de la lucha contra el fraude y los chargebacks. En el contexto de Delegated Payment, el PSP emite a la plataforma del agente un token especial (SPT) que luego utiliza tu servidor para crear el pago real (por ejemplo, un PaymentIntent en Stripe).

El cuarto y más importante rol es el del usuario. Formula la tarea, toma la decisión final de compra, otorga el consentimiento de pago y, idealmente, lee los Términos / la Política de privacidad que muestras de forma transparente en el checkout‑UI. El product feed puede contener enlaces a estos documentos y a la política de devoluciones para aumentar la confianza y la transparencia.

Para mayor comodidad, podemos resumirlo en una pequeña tabla:

La separación de responsabilidades es importante no solo para los abogados, sino también para la arquitectura. Por ejemplo, si mañana conectas un segundo PSP, no necesitas reescribir la ChatGPT App: basta con adaptar la capa de Delegated Payment en tu backend. Y si aparece una segunda plataforma de IA que también entienda ACP, podrás reutilizar tanto el product feed como los endpoints de checkout.

5. Cómo es un escenario de compra «todo en el diálogo»

Ahora juntemos todo y veamos cómo se ve un escenario end‑to‑end de compra de un regalo digital en ChatGPT desde el punto de vista de la arquitectura. Es un escenario simplificado, pero capta la esencia.

sequenceDiagram
  participant U as Usuario
  participant C as ChatGPT
  participant G as Aplicación GiftGenius
  participant B as Backend del comerciante
  participant P as PSP (Stripe)

  U->>C: "Compra un regalo digital por hasta $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Lista de SKU adecuados
  G-->>C: Opciones de regalos + metadatos
  C-->>U: Explica la elección, propone opciones
  U->>C: "Me quedo con este"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Solicitar token de pago (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Ejecutar el pago
  B-->>C: Webhook sobre la creación del pedido
  C-->>U: Confirmación de compra

En el lenguaje seco de ACP, aquí ocurre lo siguiente:

1. El agente utiliza el Product Feed (a través de tu backend) para seleccionar SKU adecuados.
2. Cuando se decide «comprar», ChatGPT crea una checkout_session a través de tu /checkout_sessions según la Agentic Checkout Spec.
3. Durante el Instant Checkout, ChatGPT solicita al PSP un token de pago delegado por un importe y comerciante concretos.
4. Ese token se envía en POST /checkout_sessions/{id}/complete, tu backend crea el pago en el PSP y genera el pedido.
5. Cuando el pedido está listo, tu servidor notifica a OpenAI mediante un webhook, tras lo cual el usuario ve la confirmación final.

Para esta lección lo importante no es memorizar los nombres de los endpoints, sino ver la estructura: feed → selección de SKU → checkout_session → pago → pedido → webhook. En las siguientes lecciones desglosaremos cada pieza por separado, incluidos los campos del feed, los campos de la sesión de checkout y el formato de los pagos delegados.

6. GiftGenius: cómo encaja nuestra App en el AI‑commerce

Hasta este punto, GiftGenius hacía de «asistente para encontrar regalos». Sabía:

• preguntar al usuario para quién y con qué motivo se necesita el regalo;
• usar herramientas MCP para buscar en su propio catálogo;
• mostrar tarjetas de opciones en el widget y enviar botones de follow‑up al chat.

Desde el punto de vista del commerce, esto era un «discovery inteligente» sin compra real. En el mundo de OpenAI commerce, tal modo corresponde a un feed en el que para un SKU está marcado enable_search = true, pero enable_checkout = false: los productos se pueden encontrar y comentar, pero el Instant Checkout está desactivado para ellos.

En el módulo de AI‑commerce transformaremos gradualmente GiftGenius en un comerciante plenamente integrado:

• añadiremos un Product Feed estructurado según la especificación de OpenAI;
• diseñaremos un backend ACP que sepa trabajar con checkout_sessions;
• conectaremos Delegated Payment mediante Stripe Shared Payment Token;
• enseñaremos a la App a mostrar al usuario que no solo puede encontrar, sino también comprar un regalo directamente en el chat.

Para que todo esto no parezca «magia negra», añadamos a nuestro código una pequeña capa técnica que modele explícitamente los roles y los pasos del flujo de commerce. Servirá tanto para logs como para tests internos.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

Estos tipos ayudan a separar mentalmente «quién hace qué» incluso a nivel de TypeScript. Podemos usarlos, por ejemplo, en tests o en un UI de depuración dentro del widget.

Un pequeño ejemplo de array de pasos para el escenario «regalo digital por hasta $50»:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Formular la solicitud y el presupuesto" },
  { id: "search", role: "chatgpt", description: "Seleccionar SKU del Product Feed" },
  { id: "checkout", role: "merchant", description: "Crear checkout_session" },
  { id: "payment", role: "psp", description: "Ejecutar el pago con el token" }
];

Este código aún no habla con nadie por la red, pero ya crea un útil «eje de coordenadas» alrededor del cual iremos añadiendo el código real de ACP en siguientes lecciones.

7. Mini‑tarea: desglosa el flujo «Cómprame un regalo digital por hasta $50»

Al final de la lección es útil desmenuzar a mano lo que acabamos de comentar. Toma la solicitud del usuario:

«Cómprame un regalo digital por hasta $50».

La tarea es describir en 3–5 pasos lógicos qué ocurre a continuación y, para cada paso, indicar quién lo ejecuta: ChatGPT, tu backend de comerciante, el proveedor de pagos o el propio usuario. Puedes apoyarte en el diagrama de arriba y en el array digitalGiftFlow, pero no es obligatorio coincidir punto por punto.

Por ejemplo, puedes empezar por el paso en el que ChatGPT interpreta la solicitud y aclara detalles al usuario (vale de regalo digital, región del destinatario, para quién es el regalo). Después, el paso en el que tu backend busca SKU adecuados a partir del Product Feed, seguido de la creación de la checkout_session, la obtención del token de pago del PSP y la finalización de la compra.

Si quieres, puedes plasmarlo directamente en código, añadiendo algunos pasos más a digitalGiftFlow y renderizándolos en un pequeño componente de depuración en el widget. Este ejercicio entrena bien el hábito de pensar no solo «en el código», sino también en los roles dentro del protocolo.

Ejemplo de un endpoint de API sencillo que podría aceptar ese «plan de flujo» y registrarlo en logs (aún sin comercio real):

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

En la vida real, en lugar de console.log escribirás logs estructurados y, quizá, almacenarás estos escenarios como parte de la documentación o de los tests. Pero incluso este pequeño ejemplo ayuda a conectar la arquitectura abstracta con código concreto de TypeScript en tu aplicación de Next.js.

Si mantienes en mente el mapa de roles que hemos visto en esta lección, los detalles técnicos posteriores —campos del Product Feed, esquemas de las sesiones de checkout y estructura de los pagos delegados— encajarán mucho mejor y sin romantizar en exceso al «todopoderoso GPT».

8. Errores típicos al entender el AI‑commerce y los roles

Error n.º 1: pensar que «ChatGPT lo hará todo por sí solo».
A veces los desarrolladores creen que basta con «conectar Stripe» y «dar a la modelo acceso al API» y que luego GPT se apañará. En realidad, el AI‑commerce alrededor de ChatGPT se apoya en especificaciones formales: Product Feed, Agentic Checkout, Delegated Payment. Si no has descrito los productos en forma de feed estructurado, no has implementado /checkout_sessions y no has configurado Delegated Payment, ningún modelo inventará eso por ti.

Error n.º 2: confundir los roles de ChatGPT y del comerciante.
Otra confusión habitual es creer que ChatGPT se convierte en «la tienda» y que tú solo «enchufas el catálogo». En realidad es al revés: tú sigues siendo el comerciante, alojas el product feed, creas y atiendes los pedidos y gestionas las devoluciones. ChatGPT solo responde del UX del diálogo y de llamar correctamente a tus endpoints ACP. Si intentas diseñar el sistema como si «GPT fuera a repartir suscripciones y enviar productos por su cuenta», tarde o temprano acabarás en un callejón sin salida jurídico y técnico.

Error n.º 3: ignorar al proveedor de pagos como entidad aparte.
A veces uno quiere «esconder» el PSP dentro del backend y hablar con él como con cualquier REST‑API, olvidando que la capa de pagos vive con sus propias reglas (PCI, fraude, chargebacks, límites). En el enfoque ACP no por casualidad existe una Delegated Payment Spec independiente: la plataforma del agente habla con el PSP a su nivel, obtiene el token SPT y te lo pasa, y tú ya creas el pago. Si intentas saltarte este esquema y aceptar directamente datos de tarjetas en tu App, te dispararás al pie con los requisitos de compliance.

Error n.º 4: ver el product feed como «ajuste de marketing» y no como un API para la LLM.
Muchos llegan con background de Google Shopping y piensan en el feed como algo más importante para el panel de anuncios que para el código. En el mundo del AI‑commerce, el feed es, en esencia, la base de conocimiento de tu surtido para el modelo. Si hay enlaces rotos a imágenes, atributos incoherentes, unidades extrañas y exageraciones de marketing en lugar de hechos, el modelo propondrá lo que no te conviene y la conversión caerá.

Error n.º 5: intentar activar Instant Checkout «de una sola vez».
La tentación es grande: «activemos ya enable_checkout, que los usuarios compren desde el chat». Pero sin un buen discovery (feed de calidad), sin un backend de checkout fiable y sin una integración bien pensada con el PSP, corres el riesgo de obtener un sistema frágil en el que la mitad de los pedidos se quedan a medias. Es mucho más sensato seguir los peldaños que propone OpenAI: primero un Product Feed de calidad, luego depurar los endpoints de ACP, después Delegated Payment y solo entonces activar el Instant Checkout en modo real.