Panorama do AI‑commerce e o papel da OpenAI

1. O que é, afinal, AI‑commerce

Se o e‑commerce clássico é a história “entrou no site — abriu o catálogo — colocou no carrinho — sofreu com três formulários”, o AI‑commerce é quando a interface principal vira o diálogo com o ChatGPT. O usuário formula a tarefa em linguagem natural, e um agente dentro do ChatGPT assume o papel de consultor, merchandiser e, em parte, de product manager.

As consultas não se parecem com “category=meias&price_max=20”, mas sim com “indique um presente engraçado, mas não muito cringe, para um colega de até 20 dólares, que possa ser enviado por e‑mail”. O agente interpreta a tarefa, faz perguntas de esclarecimento, consulta o catálogo de produtos, explica prós e contras das opções e então conduz o usuário até a compra — e tudo isso sem que o usuário precise ver um “carrinho” como página separada.

Do ponto de vista da arquitetura, o ChatGPT App, nesse momento, deixa de ser um “catálogo inteligente de presentes” e vira um aplicativo de commerce, capaz de:

1. Entender a intenção do usuário e restrições (orçamento, tipo de presente, país, produto digital/físico).
2. Selecionar SKUs específicos do product feed e explicar a escolha.
3. Iniciar a finalização da compra por meio do protocolo padronizado ACP (Agentic Commerce Protocol).

A ideia do AI‑commerce é que “catalog + checkout” deixam de ser um site separado e passam a ser uma continuação lógica do diálogo que o usuário já está mantendo com o GPT.

2. E‑commerce clássico vs AI‑commerce

Para sentir melhor a diferença, é útil colocar as duas abordagens lado a lado. Abaixo há uma tabela simplificada, que não pretende cobrir tudo, mas evidencia bem a mudança de paradigma.

Consequência prática: no AI‑commerce, a atenção sai do design visual do “catálogo e carrinho” e vai para a estrutura e qualidade dos dados, além do protocolo formal de interação entre o ChatGPT, seu backend e o provedor de pagamentos. O Product Feed e os endpoints ACP tornam‑se um “UI” tão importante quanto o próprio widget.

Se, no comércio clássico, é possível ajustar parte do UX no navegador, no AI‑commerce o modelo se apoia quase inteiramente nos dados e nos esquemas que você fornece: da descrição do produto aos status da sessão de checkout.

3. Blocos de construção do OpenAI Commerce

A OpenAI não oferece um “sistema de pagamento mágico GPTPay” que faz tudo sozinha. Em vez disso, há um conjunto de especificações e guias que descrevem como conectar corretamente merchants e provedores de pagamento existentes ao mundo do ChatGPT. Desses documentos, quatro tijolos são especialmente importantes para nós.

Em primeiro lugar, a Product Feed Specification. É o formato oficial em que o vendedor descreve seu catálogo de produtos: id, title, description, preço, moeda, disponibilidade, imagens etc. O feed funciona como uma “fonte de verdade estruturada”, que a OpenAI valida, indexa e usa para busca, ranqueamento e checkout dentro do ChatGPT.

Em segundo lugar, a Agentic Checkout Specification. É um contrato REST para trabalhar com a entidade checkout_session: a API descreve como criar uma sessão de pagamento, atualizá‑la (por exemplo, ao mudar o endereço ou a opção de entrega) e concluí‑la, bem como quais campos o backend deve retornar (valores, impostos, opções de fulfillment, links para política de devolução etc.).

Em terceiro lugar, a Delegated Payment Specification. É o protocolo pelo qual a plataforma do agente (ChatGPT) obtém um token de pagamento delegado do provedor de pagamentos (por exemplo, Stripe Shared Payment Token) e o repassa ao seu backend, sem expor os dados de pagamento em si. O token em si é limitado por valor, tempo de vida e outros parâmetros, e é usado pelo seu backend para criar o pagamento real no PSP.

Por fim, o Instant Checkout no ChatGPT — é uma camada de UX sobre essas especificações. Dentro do chat aparece uma interface de checkout compacta: produto escolhido, preço, endereço, método de pagamento. Por baixo dos panos, ela se apoia no Product Feed, chama seus /checkout_sessions pela Agentic Checkout Spec e usa Delegated Payment para executar a transação no PSP.

A boa notícia é que tudo isso não é um “API secreto do ChatGPT”, e sim especificações abertas do ACP (Agentic Commerce Protocol). Isso significa que o mesmo backend pode, teoricamente, funcionar com outras plataformas de IA, caso elas também suportem ACP.

4. Papéis e limites de responsabilidade

Agora começa a parte mais interessante: quando dinheiro entra no sistema, reguladores e advogados de repente viram seus melhores amigos. Para não se perder, é importante separar claramente os papéis.

O papel mais importante é o da plataforma do agente, no nosso caso — o ChatGPT. Ela controla a experiência do usuário: chat, widgets, Instant Checkout UI. A plataforma inicia o fluxo de commerce, escolhe produtos a partir do Product Feed, chama seus endpoints ACP e exibe o resultado ao usuário. Mas o ChatGPT não se torna dono do produto, nem um provedor de pagamentos, e não armazena seus dados de produto como “seu próprio” catálogo — ele usa exatamente o feed que você forneceu.

Em segundo lugar está o merchant (seller, merchant‑of‑record). É o dono dos produtos ou serviços. O merchant é responsável pelo próprio product feed (estrutura, qualidade, atualização de preços e disponibilidade), pela implementação correta dos endpoints ACP (/checkout_sessions, webhooks), pela criação e armazenamento de pedidos, pelo fulfillment, suporte e devoluções. A documentação do ACP enfatiza que o merchant continua sendo o vendedor de registro no sentido jurídico, e não a plataforma do agente.

O terceiro papel é o provedor de pagamentos (PSP), por exemplo, o Stripe. O PSP é responsável pelo processamento de pagamentos, conformidade com PCI DSS e outros requisitos, armazenamento de dados de pagamento, combate à fraude e chargebacks. No contexto de Delegated Payment, o PSP emite para a plataforma do agente um token especial (SPT), que então é usado pelo seu servidor para criar o pagamento real (por exemplo, um PaymentIntent no Stripe).

O quarto e mais importante papel é o usuário. Ele formula a tarefa, toma a decisão final de compra, dá o consentimento para o pagamento e, idealmente, lê os Termos / Política de Privacidade que você exibe honestamente na interface do checkout. O Product Feed pode conter links para esses documentos e para a política de devoluções, a fim de aumentar a confiança e a transparência.

Para facilitar, podemos resumir em uma pequena tabela:

Separar as zonas de responsabilidade é importante não só para os jurídicos, mas também para a arquitetura. Por exemplo, se amanhã você conectar um segundo PSP, não precisa reescrever o ChatGPT App: basta adaptar a camada de Delegated Payment no seu backend. E se surgir uma segunda plataforma de IA que também entenda ACP, você poderá reutilizar tanto o product feed quanto os endpoints de checkout.

5. Como é o cenário de compra “tudo no diálogo”

Agora vamos juntar tudo e ver como é um cenário end‑to‑end de compra de um presente digital no ChatGPT do ponto de vista da arquitetura. É um cenário simplificado, mas que reflete a essência.

sequenceDiagram
  participant U as Usuário
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Backend do Merchant
  participant P as PSP (Stripe)

  U->>C: "Compre um presente digital de até $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Lista de SKUs adequados
  G-->>C: Opções de presentes + metadados
  C-->>U: Explica a escolha, oferece opções
  U->>C: "Fico com este"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Solicitar token de pagamento (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Processar o pagamento
  B-->>C: Webhook sobre a criação do pedido
  C-->>U: Confirmação da compra

Em linguagem seca do ACP, acontece o seguinte:

1. O agente usa o Product Feed (via seu backend) para selecionar SKUs adequados.
2. Quando a decisão é “comprar”, o ChatGPT cria uma checkout_session por meio do seu /checkout_sessions, conforme a Agentic Checkout Spec.
3. Durante o Instant Checkout, o ChatGPT solicita ao PSP um token de pagamento delegado para um valor e um merchant específicos.
4. Esse token é enviado no POST /checkout_sessions/{id}/complete; seu backend cria o pagamento no PSP e gera o pedido.
5. Quando o pedido estiver pronto, seu servidor notifica a OpenAI via webhook e, em seguida, o usuário vê a confirmação final.

Para nós, nesta aula, não é tão importante memorizar os nomes dos endpoints, e sim enxergar a estrutura: feed → seleção de SKU → checkout_session → pagamento → pedido → webhook. Nas próximas aulas, vamos detalhar cada pedaço separadamente, incluindo os campos do feed, os campos da sessão de checkout e o formato dos pagamentos delegados.

6. GiftGenius: como nosso App se encaixa no AI‑commerce

Até aqui, o GiftGenius desempenhava o papel de “assistente de escolha de presentes”. Ele sabia:

• perguntar ao usuário para quem e por qual motivo o presente era necessário;
• usar ferramentas MCP para buscar no próprio catálogo;
• mostrar cards de opções no widget e enviar botões de follow‑up no chat.

Do ponto de vista de commerce, isso era um “discovery inteligente” sem compra real. No mundo do OpenAI Commerce, esse modo corresponde a um feed em que, para o SKU, está definido enable_search = true, mas enable_checkout = false: os produtos podem ser encontrados e discutidos, mas o Instant Checkout está desativado para eles.

No módulo de AI‑commerce vamos, aos poucos, transformar o GiftGenius em um merchant totalmente integrado:

• adicionar um Product Feed estruturado conforme a especificação da OpenAI;
• projetar um backend ACP capaz de trabalhar com checkout_sessions;
• conectar o Delegated Payment por meio do Stripe Shared Payment Token;
• ensinar o App a mostrar ao usuário que ele pode não só escolher, mas também comprar o presente direto no chat.

Para que isso não pareça “mágica negra”, vamos adicionar ao nosso código uma pequena camada técnica que modele explicitamente os papéis e as etapas do fluxo de commerce. Isso será útil tanto para logs quanto para testes internos.

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

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

Esses tipos ajudam a separar mentalmente “quem faz o quê” até no nível do TypeScript. Podemos usá‑los, por exemplo, em testes ou em um UI de depuração dentro do widget.

Um pequeno exemplo de array de etapas para o cenário “presente digital de até $50”:

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

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Formular o pedido e o orçamento" },
  { id: "search", role: "chatgpt", description: "Selecionar SKUs do Product Feed" },
  { id: "checkout", role: "merchant", description: "Criar checkout_session" },
  { id: "payment", role: "psp", description: "Processar o pagamento com o token" }
];

Esse código ainda não conversa com ninguém pela rede, mas já cria um útil “eixo de coordenadas” em torno do qual vamos construir o código ACP real nas próximas aulas.

7. Mini‑tarefa: decomponha o fluxo “Compre um presente digital de até $50”

No fim da aula, é útil praticar com as mãos aquilo que acabamos de discutir. Pegue o pedido do usuário:

“Compre um presente digital de até $50”.

A tarefa é descrever, em 3–5 etapas lógicas, o que acontece em seguida e, para cada etapa, indicar quem a executa: o ChatGPT, seu backend de merchant, o provedor de pagamentos ou o próprio usuário. Você pode se apoiar no diagrama acima e no array digitalGiftFlow, mas não precisa bater com ele exatamente.

Por exemplo, você pode começar pela etapa em que o ChatGPT interpreta o pedido e esclarece detalhes com o usuário (vale‑presente digital, região do destinatário, para quem é o presente). Depois, a etapa em que seu backend busca SKUs adequados via Product Feed, em seguida — a criação da checkout_session, a obtenção do token de pagamento no PSP e a conclusão da compra.

Se quiser, pode implementar isso diretamente em código, adicionando mais algumas etapas ao digitalGiftFlow e renderizando‑as em um pequeno componente de depuração no widget. Esse exercício treina bem o hábito de pensar não só “sobre o código”, mas também sobre os papéis no protocolo.

Exemplo de um endpoint de API simples que poderia receber esse “plano de fluxo” e registrá‑lo em log (ainda sem comércio 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 });
}

Na vida real, em vez de console.log, você escreverá logs estruturados e, talvez, armazene esses cenários como parte da documentação ou dos testes. Mas mesmo esse pequeno exemplo ajuda a conectar a arquitetura abstrata com o TypeScript concreto no seu aplicativo Next.js.

Se mantivermos em mente o quadro de papéis que vimos nesta aula, os detalhes técnicos seguintes — campos do Product Feed, esquemas de sessões de checkout e a estrutura de pagamentos delegados — vão se encaixar com muito mais facilidade e sem romantizar demais o “GPT onipotente”.

8. Erros típicos ao entender AI‑commerce e papéis

Erro nº 1: achar que “o ChatGPT fará tudo sozinho”.
Às vezes os desenvolvedores pensam que basta “conectar o Stripe” e de algum modo “dar acesso da modelo ao API”, e o GPT resolve o resto. Na realidade, o AI‑commerce ao redor do ChatGPT se apoia em especificações formais: Product Feed, Agentic Checkout, Delegated Payment. Se você não descreveu os produtos em um feed estruturado, não implementou /checkout_sessions e não configurou o Delegated Payment, nenhuma modelo vai inventar isso por você.

Erro nº 2: confundir os papéis do ChatGPT e do merchant.
Outra confusão comum é achar que o ChatGPT vira a “loja” e você apenas “conecta o catálogo”. Na realidade, é o contrário: você continua sendo o merchant, mantém o product feed, cria e atende aos pedidos, processa devoluções. O ChatGPT responde apenas pelo UX do diálogo e por chamar corretamente seus endpoints ACP. Se você tentar projetar o sistema como se “o GPT fosse distribuir assinaturas e enviar produtos por conta própria”, cedo ou tarde vai cair em um beco sem saída jurídico e técnico.

Erro nº 3: ignorar o provedor de pagamentos como entidade separada.
Às vezes dá vontade de “esconder” o PSP dentro do backend e falar com ele como com qualquer REST‑API, esquecendo que a camada de pagamentos vive com suas próprias regras (PCI, fraude, chargebacks, limites). Na abordagem ACP, a Delegated Payment Spec é destacada por um motivo: a plataforma do agente conversa com o PSP no seu próprio nível, recebe o token SPT e o repassa a você; então você cria o pagamento. Se tentar contornar esse esquema e aceitar dados de cartão diretamente no App, você logo vai dar um tiro no pé com exigências de compliance.

Erro nº 4: encarar o product feed como “configuração de marketing”, e não como um API para LLM.
Muitos vêm com background de Google Shopping e pensam no feed como algo mais importante para o gerenciador de anúncios do que para o código. No mundo do AI‑commerce, o feed é, na prática, a base de conhecimento do seu sortimento para a modelo. Se houver links quebrados para imagens, atributos inconsistentes, unidades estranhas e exageros de marketing em vez de fatos, a modelo vai sugerir coisas erradas e a conversão vai cair.

Erro nº 5: tentar ativar o Instant Checkout “de uma vez só”.
A tentação é grande: “vamos logo ligar o enable_checkout para que os usuários comprem pelo chat”. Mas, sem um discovery de qualidade (feed bem feito), sem um backend de checkout confiável e sem uma integração bem pensada com o PSP, você corre o risco de ter um sistema frágil, em que metade dos pedidos trava no meio do caminho. É muito mais sensato seguir as etapas sugeridas pela OpenAI: primeiro um Product Feed de qualidade, depois a depuração dos endpoints ACP, em seguida o Delegated Payment e só então ativar o Instant Checkout em produção.