The AI‑commerce landscape and OpenAI’s role

1. What AI‑commerce actually is

If classic e‑commerce is the story “landed on a website — opened the catalog — added to cart — slogged through three forms,” then AI‑commerce is when the primary interface becomes a dialogue with ChatGPT. The user formulates a task in natural language, and the agent inside ChatGPT takes on the role of consultant, merchandiser, and, to some extent, product manager.

Requests don’t look like “category=socks&price_max=20”, but like “pick a funny but not too cringey gift for a colleague up to 20 dollars that can be sent by email.” The agent interprets the task, asks clarifying questions, looks into the product catalog, explains the pros and cons of the options, and then guides the user to purchase — all without the user seeing a “cart” as a separate page at all.

From an architecture perspective, the ChatGPT App at this point turns from a “smart gift catalog” into a commerce application that can:

1. Understand the user’s intent and constraints (budget, gift type, country, digital/physical item).
2. Select specific SKUs from the product feed and explain the choice.
3. Initiate checkout via the standardized ACP (Agentic Commerce Protocol).

The idea of AI‑commerce is that “catalog + checkout” are not a separate website but a natural continuation of the dialogue the user is already having with GPT.

2. Classic e‑commerce versus AI‑commerce

To better feel the difference, it’s useful to lay the two approaches side by side. Below is a simplified table that doesn’t claim perfect coverage but does highlight the paradigm shift well.

A practical consequence: in AI‑commerce, attention shifts from the visual design of the “catalog and cart” to the structure and quality of data, as well as to the formal protocol of interaction between ChatGPT, your backend, and the payment provider. The product feed and ACP endpoints become just as important a “UI” as the widget itself.

If in a classic store you can tweak part of the UX in the browser, in AI‑commerce the model relies almost entirely on the data and schemas you provide: from product descriptions to checkout session statuses.

3. OpenAI Commerce building blocks

OpenAI doesn’t offer a “magic GPTPay payment system” that does everything for you. Instead, there’s a set of specifications and guides describing how to correctly connect existing merchants and payment providers to the world of ChatGPT. From these documents, four building blocks are especially important to us.

First, the Product Feed Specification. This is the official format in which a seller describes their product catalog: id, title, description, price, currency, availability, images, etc. The feed serves as a “structured source of truth” that OpenAI validates, indexes, and uses for search, ranking, and checkout inside ChatGPT.

Second, the Agentic Checkout Specification. This is the REST contract for working with the checkout_session entity: the API describes how to create a payment session, update it (for example, when the address or shipping method changes), and complete it, as well as which fields your backend must return (amounts, taxes, fulfillment options, links to the return policy, and so on).

Third, the Delegated Payment Specification. This is the protocol by which the agent platform (ChatGPT) obtains a delegated payment token from the payment provider (for example, a Stripe Shared Payment Token) and passes it to your backend without exposing the actual payment credentials. The token is limited by amount, lifetime, and other parameters and is used by your backend to create the real payment with the PSP.

And finally, Instant Checkout in ChatGPT is a UX layer on top of these specifications. A compact checkout interface appears inside the chat: selected product, price, address, payment method. Under the hood it relies on the Product Feed, calls your /checkout_sessions per the Agentic Checkout Spec, and uses Delegated Payment to execute the transaction with the PSP.

The good news is that all these things are not a “secret ChatGPT API” but open ACP (Agentic Commerce Protocol) specifications. This means the same backend could theoretically work with other AI platforms if they also support ACP.

4. Roles and boundaries of responsibility

Here’s where it gets interesting: once money enters the system, regulators and lawyers suddenly become your best friends. To avoid confusion, it’s important to separate roles clearly.

The most important role belongs to the agent platform—in our case, ChatGPT. It owns the user experience: chat, widgets, Instant Checkout UI. The platform initiates the commerce flow, selects products from the Product Feed, calls your ACP endpoints, and shows the result to the user. But ChatGPT does not become the owner of the product, nor a payment provider, and it does not store your product data as “its own catalog”—it uses exactly the feed you provide.

The second role is the merchant (seller, merchant of record). This is the owner of the goods or services. The merchant is responsible for the product feed itself (structure, quality, up‑to‑date prices and availability), for the correct implementation of ACP endpoints (/checkout_sessions, webhooks), for creating and storing orders, for delivery, support, and returns. ACP documentation emphasizes that the merchant remains the seller of record in the legal sense, not the agent platform.

The third role is the payment service provider (PSP), e.g., Stripe. The PSP is responsible for processing payments, complying with PCI DSS and other requirements, storing payment credentials, and handling fraud and chargebacks. In the context of Delegated Payment, the PSP issues a special token (SPT) to the agent platform, which your server then uses to create the actual payment (for example, a PaymentIntent in Stripe).

The fourth and most important role is the user. They formulate the task, make the final purchase decision, consent to payment, and, ideally, read the Terms / Privacy Policy that you honestly show in the checkout UI. The product feed can contain links to these documents and to your returns policy to increase trust and transparency.

For convenience, we can condense this into a small table:

Separating areas of responsibility matters not only for lawyers but also for architecture. For example, if tomorrow you connect a second PSP, you don’t need to rewrite the ChatGPT App—just adapt the Delegated Payment layer on your backend. And if a second AI platform appears that also understands ACP, you can reuse both your product feed and your checkout endpoints.

5. What a “all in dialogue” purchase scenario looks like

Now let’s put it all together and see what an end‑to‑end digital gift purchase scenario in ChatGPT looks like from an architecture perspective. This is a simplified scenario, but it captures the essence.

sequenceDiagram
  participant U as User
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Merchant Backend
  participant P as PSP (Stripe)

  U->>C: "Buy a digital gift up to $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: List of matching SKUs
  G-->>C: Gift options + metadata
  C-->>U: Explains the choice, offers options
  U->>C: "I’ll take this one"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Request a payment token (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Process the payment
  B-->>C: Webhook about order creation
  C-->>U: Purchase confirmation

In ACP terms, the following happens here:

1. The agent uses the Product Feed (via your backend) to select matching SKUs.
2. When the decision is “let’s buy,” ChatGPT creates a checkout_session via your /checkout_sessions per the Agentic Checkout Spec.
3. During Instant Checkout, ChatGPT requests a delegated payment token from the PSP for a specific amount and merchant.
4. This token is passed into POST /checkout_sessions/{id}/complete; your backend creates the payment with the PSP and forms the order.
5. When the order is ready, your server notifies OpenAI via a webhook, after which the user sees the final confirmation.

What matters for us in this lecture is not memorizing endpoint names but seeing the structure: feed → SKU selection → checkout_session → payment → order → webhook. In the next lectures we’ll break down each piece separately, including feed fields, checkout session fields, and the format of delegated payments.

6. GiftGenius: how our App fits into AI‑commerce

Up to this point, GiftGenius played the role of a “gift‑selection assistant.” It could:

• ask the user who the gift is for and on what occasion;
• use MCP tools to search its catalog;
• show option cards in the widget and send follow‑up buttons into the chat.

From a commerce perspective, that was “smart discovery” without an actual purchase. In the world of OpenAI commerce, this corresponds to a feed where an SKU has enable_search = true, but enable_checkout = false: items can be found and discussed, but Instant Checkout is disabled for them.

In the AI‑commerce module, we will gradually turn GiftGenius into a fully integrated merchant:

• add a structured Product Feed per the OpenAI spec;
• design an ACP backend that can work with checkout_sessions;
• connect Delegated Payment via the Stripe Shared Payment Token;
• teach the App to show the user that they can not only select but also buy a gift right in the chat.

To keep this from looking like “black magic,” let’s add a small technical layer to our code that explicitly models the roles and steps of the commerce flow. This is useful for logs and for internal tests.

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

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

These types help mentally separate “who does what,” even at the TypeScript level. We can use them, for example, in tests or in a debug UI inside the widget.

A small example of a steps array for the “digital gift up to $50” scenario:

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

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Formulate the request and budget" },
  { id: "search", role: "chatgpt", description: "Select SKUs from the Product Feed" },
  { id: "checkout", role: "merchant", description: "Create a checkout_session" },
  { id: "payment", role: "psp", description: "Execute payment using the token" }
];

This code doesn’t talk to anyone over the network yet, but it already creates a useful “coordinate axis” around which we’ll build real ACP code in the next lectures.

7. Mini‑assignment: break down the flow “Buy me a digital gift up to $50”

At the end of the lecture, it’s useful to work through what we’ve just discussed by hand. Take the user’s request:

“Buy me a digital gift up to $50.”

Your task is to describe, in 3–5 logical steps, what happens next, and for each step indicate who performs it: ChatGPT, your merchant backend, the payment provider, or the user themself. You can rely on the diagram above and on the digitalGiftFlow array, but you don’t have to match them one‑to‑one.

For example, you can start with a step where ChatGPT interprets the request and clarifies details with the user (digital certificate, recipient’s region, who exactly the gift is for). Then a step where your backend searches the Product Feed for matching SKUs, followed by creating a checkout_session, obtaining a payment token from the PSP, and completing the purchase.

If you like, you can implement this directly in code by adding a few more steps to digitalGiftFlow and rendering them in a small debug component in the widget. This exercise helps build the habit of thinking not only “about code,” but also about roles in the protocol.

An example of a simple API endpoint that could accept such a “flow plan” and log it (without real commerce yet):

// 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 });
}

In real life, instead of console.log you’ll write structured logs and, perhaps, store such scenarios as part of documentation or tests. But even this small example helps tie abstract architecture to concrete TypeScript code in your Next.js application.

If you keep in mind the picture of roles we covered in this lecture, the subsequent technical details—Product Feed fields, checkout session schemas, and the structure of delegated payments—will fit much more easily, without unnecessary romanticism around the “almighty GPT.”

8. Typical misunderstandings about AI‑commerce and roles

Error #1: assuming that “ChatGPT will do everything itself.”
Sometimes developers think it’s enough to “hook up Stripe” and somehow “give the model access to the API,” and GPT will sort it out. In reality, AI‑commerce around ChatGPT rests on formal specifications: Product Feed, Agentic Checkout, Delegated Payment. If you haven’t described products in a structured feed, haven’t implemented /checkout_sessions, and haven’t set up Delegated Payment, no model will invent that for you.

Error #2: conflating the roles of ChatGPT and the merchant.
Another common confusion is to assume that ChatGPT becomes “the shop” and you just “connect a catalog.” In reality, it’s the other way around: you remain the merchant, you host the product feed, you create and service orders, and you handle returns. ChatGPT is only responsible for the dialogue UX and correct invocation of your ACP endpoints. If you design the system as if “GPT will distribute subscriptions and ship products itself,” sooner or later you’ll hit a legal and technical dead end.

Error #3: ignoring the payment provider as a separate entity.
It’s tempting to “hide” the PSP inside your backend and talk to it like any REST API, forgetting that the payment layer lives by its own rules (PCI, fraud, chargebacks, limits). In the ACP approach, the separate Delegated Payment Spec is no accident: the agent platform talks to the PSP at its own level, receives an SPT token, and passes it to you, and you create the payment. If you try to bypass this scheme and collect card details directly in your App, you’ll quickly shoot yourself in the foot with compliance requirements.

Error #4: treating the product feed as a “marketing setting,” not as an API for the LLM.
Many come with a Google Shopping background and think of the feed as something that matters more for the ad account than for code. In the world of AI‑commerce, the feed is, in essence, the model’s knowledge base of your assortment. If it contains broken image links, inconsistent attributes, odd units of measure, and marketing exaggerations instead of facts, the model will propose what you don’t need—and conversion will suffer.

Error #5: trying to roll out Instant Checkout “in one step.”
The temptation is strong: “let’s immediately enable enable_checkout and let users buy from chat.” But without good discovery (a quality feed), without a reliable checkout backend, and without a thoughtful PSP integration, you risk ending up with a brittle system where half of the orders get stuck halfway. It’s far more sensible to follow the steps OpenAI suggests: first a quality Product Feed, then debugging ACP endpoints, then Delegated Payment, and only after that enabling Instant Checkout in production.