ChatGPT Merchants and the merchant journey: from registration to responsibility

1. What is a ChatGPT merchant and how is it different from a “regular store”

From a developer’s perspective it’s easy to blur the layers: there’s a Next.js app, an MCP server, some commerce backend, and somewhere out there OpenAI, ChatGPT, Stripe, and other grown‑up services. You might be tempted to say, “It’s all one big system — as long as the tests are green.”

But in AI commerce the legal and technical boundaries are strictly separated. ChatGPT does not become your store and does not turn into a payment processor. It only provides an intelligent interface and calls your APIs via open specifications. The merchant remains a specific company with a concrete catalog and accountability to the user.

Understanding the merchant’s role isn’t just for lawyers. It drives architecture decisions: where feed data is stored, how you validate orders, what you log, how you debug mismatches between what’s shown in chat and what actually happened in your system.

Example

Think of classic e‑commerce: you have a website, a cart, a checkout, and an integration with a payment provider. The user opens a browser, clicks with a mouse, enters card details — all straightforward.

A ChatGPT merchant is the same store, just trained to sell via an AI dialogue with a high degree of automation. The difference is not in what you sell, but in how the user moves from request to payment.

From OpenAI’s perspective, a merchant is an organization (or a sole proprietor) that:

• provides a Product Feed per OpenAI’s specification (CSV/TSV/XML/JSON with structured SKU data);
• registers in the ChatGPT Merchants portal and passes category and legal checks;
• in the advanced variant implements Agentic Checkout and Delegated Payment so that Instant Checkout in ChatGPT can complete a payment without leaving for your site.

So a merchant is not “the person who wrote a widget,” but the owner of the assortment and the financial obligations. In this course we play both roles: the team building GiftGenius as a ChatGPT App, and the team building the merchant backend that serves that App.

2. ChatGPT Merchants portal: path from application to a production merchant

OpenAI has a separate site for sellers — the ChatGPT Merchants portal. Through it, sellers join the Instant Checkout program and connect their feeds and backend. Let’s walk this path step by step, without deep technical details yet (that’s the next lecture).

Pre‑work

Before anyone on your team clicks “Apply,” you should already have a few building blocks:

A legal entity and a website. The merchant has a domain and a user‑facing storefront — even if everything will be sold via ChatGPT, OpenAI expects a public storefront.

Assortment within policy. In the previous lecture we discussed the Prohibited Products Policy: you can’t sell, for example, weapons or certain medical goods. Any item you want to sell via ChatGPT must fit allowed categories.

Basic payment infrastructure. Even though Delegated Payment removes the need to handle cards directly, you must have an integration with a PSP (e.g., Stripe) and an understanding of how you create orders and refunds in your system.

Application in the Merchants portal

From a technical point of view this is fairly boring but important: you go to the site and apply to join the Instant Checkout program. They typically ask:

• who you are (legal entity, site, contacts);
• what you sell (categories, price range, regions);
• how you can provide the Product Feed (format, URL, update frequency).

This part has little to do with TypeScript, but it strongly affects your roadmap: until the merchant passes a basic review, Instant Checkout won’t be enabled, even if your code is perfect.

Connecting the Product Feed

After your application is reviewed and tentatively approved, the main technical focus shifts to the Product Feed. Per the documentation the feed is mandatory: without it ChatGPT simply doesn’t know what you sell.

At this step you:

1. Define the feed format (most often CSV or JSON).
2. Agree on how you will deliver it: this can be a pre‑signed URL on S3 or an HTTPS endpoint where you periodically POST updates.
3. Prepare the minimum fields for each SKU: id, title, description, price, currency, availability, link, images, and flags enable_search / enable_checkout.

As long as you set enable_checkout = false, the merchant can operate in discovery‑only mode: ChatGPT finds and recommends products, but on a purchase attempt it sends the user to your website.

ACP integration (more in the next lecture)

When the Product Feed is stable and you’re ready to go further, you start integrating Agentic Checkout and Delegated Payment. From the Merchants portal perspective this is a separate requirement block: you need to implement endpoints /checkout_sessions, learn to accept the delegated payment token (Shared Payment Token), and correctly finish sessions with the required statuses (not_ready_for_payment, ready_for_payment, completed, canceled).

In this lecture we only mention it as the “next level of difficulty.” We’ll cover the protocol details and request schemas in the next lecture.

3.5. Certification and enabling Instant Checkout

The final stage is verifying how your backend behaves in real scenarios:

• whether orders are created correctly;
• whether prices from the feed match the prices you actually charge;
• whether errors and refunds are handled properly;
• whether your ToS/Privacy pages meet OpenAI’s and local legal expectations.

After this, the merchant gets the status “ready for Instant Checkout,” and its products with enable_checkout = true become truly purchasable right in ChatGPT.

You can picture all of this as a simple diagram:

flowchart TD
  A[Have product and website] --> B[Application to ChatGPT Merchants]
  B --> C[Product Feed connected]
  C --> D["ACP backend implemented
(checkout_sessions + delegated payment)"]
  D --> E[Certification
and enabling Instant Checkout]

3. Merchant options: Etsy/Shopify vs custom backend

Good news: not all merchants have to implement the entire ACP backend themselves. For some platforms (Shopify, Etsy, etc.) there are integrations that take care of the technical implementation.

If you sell via Shopify or Etsy, the flow is roughly: you enable an option like “Show in ChatGPT,” and the platform itself:

• builds and maintains the Product Feed in the required format;
• implements or proxies ACP endpoints;
• connects to Stripe or another PSP.

As the store owner, you focus more on assortment and descriptions than on REST endpoints.

If, as in our course with GiftGenius, you’re building a custom merchant with your own backend, you gain much more freedom, but also more work: you write the code that implements the feed, checkout, and integration with the payment provider.

It’s convenient to compare this in a table:

For the course we deliberately choose the third option: only then can we walk the whole path from feed to webhooks and reliable production.

4. Merchant responsibilities: data, orders, policy, money

When you become a ChatGPT merchant, you sign up not only for the joy of new orders but also for a set of very concrete obligations. Let’s break them down by layers.

Catalog data and Product Feed quality

The Product Feed is the source of truth for ChatGPT. If it states that an item costs 10 USD and is in stock, that is exactly what the user will see in the chat. If the feed is wrong, in the best case you’ll get an unhappy customer; in the worst — a policy violation and trouble with OpenAI.

OpenAI expects the merchant to ensure:

• correctness of required fields (proper price format, ISO currency codes, valid HTTPS links, working images);
• feed updates often enough to avoid selling ghost inventory;
• identifier consistency: the SKU id in the feed must match the ID in your database and order system, so you can unequivocally understand what exactly was purchased.

If you draw a parallel with regular e‑commerce, the Product Feed here is your “export to a marketplace,” except the marketplace is not a site but a smart assistant that lives in the user’s head and readily remembers inconsistencies.

Orders, shipping, and returns

ChatGPT doesn’t turn into your store’s support department. The user talks to it, of course, but legally they buy the product from the merchant, not from OpenAI. Which means:

• you are responsible for creating the order in your system and getting it to the warehouse;
• you are responsible for the shipment arriving at the address specified by the user in Instant Checkout;
• you are responsible for handling returns, cancellations, partial refunds, etc.

Within ACP, a checkout_session after successful completion usually contains an order object with its fields. But that’s only a reflection of what happened in your backend — you decide what the record in the orders table looks like, what statuses exist, and how they tie into logistics.

Policy and geography

In the Merchants portal you specify which countries you sell in and what types of goods. OpenAI on its side checks that you:

• do not sell prohibited categories;
• comply with local law (for example, tax rules and age restrictions);
• provide clear Terms of Service and a Privacy Policy.

We’ll talk more about legal pages in later modules, but even now it helps to think in terms like: “If I can’t explain to a lawyer exactly what I sell and where, ChatGPT is unlikely to sell it for me.”

Money and the payment provider

Finally, the scariest part — money. Fortunately, ACP and Delegated Payment greatly simplify life for developers:

• ChatGPT and the payment provider (e.g., Stripe) agree on a Shared Payment Token for a specific amount and merchant;
• your backend receives this token in a complete request and uses it with your PSP, without seeing raw card data.

So you don’t turn into a PCI‑compliant monster, you don’t store card numbers, and you avoid audit nightmares. Your responsibility is to use the delegated token correctly (create a payment, capture funds, issue refunds) and keep clean accounting.

5. How this maps onto the GiftGenius architecture

Back to our training app, GiftGenius. Architecturally, after module 14 we want the student to be able to draw a diagram like: “User → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend.”

In this scheme the merchant role is implemented in our backend, while the widget and the App are merely the merchant’s “face” in ChatGPT.

Merchant configuration in code

Let’s start with a simple step: create a merchant configuration structure in code. Let it be a TypeScript module lib/merchantConfig.ts in our Next.js project:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID of the merchant in ACP/Stripe
  name: string;              // Human-readable name
  feedUrl: string;           // Where the Product Feed lives
  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, // enable later
};

Here, first, we explicitly fix the boundaries: this is the merchant, not a “widget.” Second, we extract important values into environment variables — in the modules on deployment and environments we’ll revisit why you shouldn’t hard‑code such things.

For convenience, you can add a simple function that tells your code whether Instant Checkout can be used right now:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // Always disable Instant Checkout on dev and staging
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

This way we prepare the architecture for different behavior across environments and prevent ourselves (and GPT) from accidentally entering a live checkout from a test environment.

MCP tool for retrieving merchant information

It’s often useful to let the model and the widget know what mode the merchant is currently in. For example, so GPT doesn’t suggest Instant Checkout if it’s disabled.

In the MCP server (which we set up in previous modules) you can add a simple tool:

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

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Returns basic information about the GiftGenius merchant",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

This tool does nothing extraordinary, but it creates an explicit place where the model can ask: “Can I buy directly in chat right now, or should I only link out?”

Using merchant information in the widget

On the widget side, using the familiar Apps SDK hooks, you can call get_merchant_info and change the UI depending on the mode. A minimal component example:

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

This small component nicely emphasizes to the user (and to you in dev mode) what state the ChatGPT integration is currently in.

6. Practical mini‑assignment

To keep the lecture from staying at the level of “words and diagrams,” try the following steps in your GiftGenius project (or a similar one):

First, add a merchant configuration module similar to merchantConfig.ts, and move MERCHANT_ID and PRODUCT_FEED_URL to environment variables. For local development, you can use .env.local, and for production — Vercel settings or another platform.

Second, implement a simple get_merchant_info tool in the MCP server that returns at least name and instantCheckout. Consider what other fields might be helpful to the model, such as supported currencies or shipping countries.

Third, add a small UI element in the widget (a badge, a status line, a label on a product card) that uses this tool and shows the user which mode your merchant is currently in: recommendations only or full Instant Checkout already. This is not only useful for UX but also great for debugging.

Finally, try writing out the steps your specific project will take to go from “we have a site and a backend” to ChatGPT‑merchant status. Where exactly will you connect the Product Feed, when will you enable enable_checkout, and when will you start implementing ACP endpoints? This exercise is a good discipline and helps you not forget important, unloved things like return policies.

7. Common mistakes on the road to becoming a ChatGPT merchant

Mistake #1: “ChatGPT is my store.”
Sometimes developers mentally “move” everything to ChatGPT’s side: as if it stores the catalog, calculates prices, and fulfills orders. In reality, ChatGPT is an interface and an orchestrator, not your ERP. If you forget this, it’s easy to build an architecture with no proper native order model, data living “somewhere in prompts,” and any change in model behavior threatening consistency.

Mistake #2: expecting Instant Checkout without separate registration and ACP.
The fact that you built a great widget and set up a Product Feed does not automatically enable Instant Checkout. You need an application in the Merchants portal, category review, Agentic Checkout and Delegated Payment implementation, and passing tests. Planning on Instant Checkout “by default” usually ends with GPT offering the user something that doesn’t actually exist, or giving links instead of the expected payment screens.

Mistake #3: hard‑coding merchant IDs and URLs.
A classic story: MERCHANT_ID = "prod-123" is hard‑coded right in the code, and the feed URL is a string in a widget component. As soon as you get staging or need a second merchant, the mass search‑and‑replace begins. It’s much safer to move such things into configuration and environment variables and consume them via a small abstraction layer, as we did with MerchantConfig.

Mistake #4: the Product Feed lives its own life, disconnected from orders.
If the feed lists SKU GIFT_RED_MUG at 10 USD, but in the orders database for the same identifier you for some reason charge 12 USD, sooner or later it will surface. The source of truth for prices and availability should be either the feed assembled from your internal data, or a shared layer trusted by both the feed and the checkout. Trying to keep “double bookkeeping” (one for ChatGPT, another for your site) backfires quickly.

Mistake #5: ignoring the role of the payment provider and storage of payment data.
There’s sometimes a temptation to “peek” into the payment provider’s token or even to ask the user for payment details in your own UI. This not only violates the Delegated Payment model but can also drag you into the world of PCI DSS and heavy compliance. The right practice is to treat the Shared Payment Token as an opaque string, use it only in the payment provider’s SDK, and never log or cache it.

Mistake #6: underestimating the multi‑step onboarding and having no plan.
Finally, a common organizational mistake is thinking “we’ll just connect to ChatGPT — how hard can it be.” In reality, the merchant path consists of many steps: technical (feed, backend, tests) and non‑technical (legal documents, category approval, regional restrictions). If you don’t map out this path in advance, the team will jump chaotically between tasks, and deadlines will “melt” faster than your inspiration from AI commerce.