ChatGPT Merchants 与商家的路径：从注册到责任

1. 什么是 ChatGPT 商家，它与“普通商店”有何不同

从开发者的视角，很容易混淆层级：我们有 Next.js 应用、MCP 服务器、某个 commerce 后端，以及 OpenAI、ChatGPT、Stripe 等其他大型服务。很容易想说：“这就是一个大系统，只要测试都是绿的就行。”

但在 AI‑commerce 的世界里，法律和技术边界被严格区分。ChatGPT 不会成为你的商店，也不会变成支付处理器。它只提供智能界面，并按照开放规范调用你的 API。商家仍然是一家具体的公司，拥有具体的商品目录，并对用户承担责任。

理解商家的角色不仅是律师需要的事情。它直接影响架构决策：Feed 数据存在哪里、如何校验订单、记录哪些日志、以及如何排查聊天中展示的内容与你系统中实际发生的事情之间的差异。

示例

设想一个典型的电商：你有网站、购物车、checkout、与支付服务商的集成。用户在浏览器里点击、输入卡片信息——一切都很清楚。

ChatGPT 商家本质上还是同一个商店，只是学会了通过高度自动化的 AI 对话进行销售。区别不在于你卖什么，而在于用户如何从需求走到支付。

在 OpenAI 看来，商家是一家机构（或个体经营者），它需要：

• 按照 OpenAI 的规范提供 Product Feed（CSV/TSV/XML/JSON 的结构化 SKU 数据）；
• 在 ChatGPT Merchants 门户注册，并通过品类和合规性检查；
• 在进阶方案中实现 Agentic Checkout 与 Delegated Payment，从而让 ChatGPT 的 Instant Checkout 能够在不跳转你网站的情况下完成支付。

也就是说，商家不是“写了一个小部件的人”，而是品类和财务义务的承担者。在本课程中，我们同时扮演两种角色：既是编写 GiftGenius 这一 ChatGPT App 的团队，也是构建服务该 App 的商家后端的团队。

2. ChatGPT Merchants 门户：从申请到上线商家

OpenAI 为卖家提供了单独的网站—— ChatGPT Merchants 门户。 卖家通过它加入 Instant Checkout 计划并接入 Feed 与后端。我们把这个流程分解成步骤，先不深入技术细节（这些会在下一讲展开）。

前期准备

在你们团队中有人点下“Apply”按钮之前，你们应该已经具备几个基础模块：

法律主体与网站。商家应当有域名和用户易于理解的对外门店（storefront）——即使后面主要通过 ChatGPT 销售，OpenAI 仍期望你有公开的展示窗口。

符合政策的商品范围。上一讲我们讨论了 Prohibited Products Policy（禁止商品政策）：例如，武器或某些医疗类产品不允许。任何你希望通过 ChatGPT 销售的商品都必须属于允许的品类。

基础支付基础设施。尽管 Delegated Payment 免去了你直接处理卡片的需求，你仍然需要与 PSP（如 Stripe）集成，并清楚地知道如何在你的系统中创建订单与退款。

在 Merchants 门户提交申请

从技术视角看，这是一个“有点枯燥但很重要”的步骤：你登录网站，提交参与 Instant Checkout 计划的申请。通常会询问：

• 你是谁（法人主体、网站、联系方式）；
• 你卖什么（品类、价格区间、地区）；
• 你如何提供 Product Feed（格式、URL、更新频率）。

这一部分与 TypeScript 的关系不大，但对 roadmap 影响很大：在商家通过基础审核之前，就算你的代码再完美，Instant Checkout 也不会被开启。

接入 Product Feed

当申请被查看并整体同意后，主要技术工作会转向 Product Feed。根据文档，Feed 是集成的必需项：没有它，ChatGPT 根本不知道你在卖什么。

在这一步你需要：

1. 确定 Feed 格式（最常见是 CSV 或 JSON）。
2. 约定交付方式：可以是 S3 的预签名 URL，或你周期性向某个 HTTPS 端点 POST 更新。
3. 为每个 SKU 准备最少字段： id、title、description、 price、currency、availability、 link、图片，以及 enable_search / enable_checkout 标志。

当你将 enable_checkout = false 时，商家可以以仅发现（discovery‑only）模式运行：ChatGPT 会查找并推荐商品，但在尝试购买时会把用户引导至你的网站。

ACP 集成（下一讲详解）

当 Product Feed 稳定且你准备更进一步时，就该开始集成 Agentic Checkout 与 Delegated Payment。从 Merchants 门户的角度看，这是一块单独的要求：你需要实现 /checkout_sessions 端点， 学会接收委托支付令牌（Shared Payment Token），并以正确的状态结束会话 （not_ready_for_payment、ready_for_payment、 completed、canceled）。

本讲只把它当作“下一个难度级别”来提及。协议细节与请求模式我们会在下一讲详细拆解。

3.5. 认证与开启 Instant Checkout

最后阶段——验证你的后端在真实场景中的表现：

• 订单是否被正确创建；
• Feed 中的价格是否与实际扣款价格一致；
• 错误与退款是否被正确处理；
• 你的 ToS/Privacy 页面是否符合 OpenAI 与当地法律的预期。

之后，商家会获得“可启用 Instant Checkout”的状态，且其 enable_checkout = true 的商品将真正支持在 ChatGPT 内直接购买。

可以把整个流程想象成一张简单的图：

flowchart TD
  A[已有产品和网站] --> B[在 ChatGPT Merchants 申请]
  B --> C[已接入 Product Feed]
  C --> D["已实现 ACP backend
(checkout_sessions + delegated payment)"]
  D --> E[认证通过
并开启 Instant Checkout]

3. 商家形态：Etsy/Shopify vs 自建后端

好消息是：并非所有商家都要自己编写完整的 ACP 后端。对于部分平台（Shopify、Etsy 等）已存在集成方案，技术实现由平台承担。

如果你通过 Shopify 或 Etsy 销售，流程大致如下：你在平台上开启类似“Show in ChatGPT”的选项，平台会自动：

• 按要求生成并维护 Product Feed；
• 实现或代理 ACP 端点；
• 与 Stripe 或其他 PSP 对接。

作为店主，你更多关注商品与描述，而不是 REST 端点。

如果像我们在 GiftGenius 课程中那样构建自建商家及其后端，你会拥有更大的自由度，同时也会有更多工作：你要自己编写实现 Feed、checkout 与支付服务商集成的代码。

用表格对比会更清晰：

在课程中我们有意选择第三种方案：只有这样，我们才能完整走一遍从 Feed 到 webhook 再到可靠生产环境的全流程。

4. 商家的责任：数据、订单、政策、资金

当你成为 ChatGPT 商家时，你收获的不仅是新订单带来的喜悦，还有一组非常具体的义务。我们按层次来拆解。

目录数据与 Product Feed 质量

Product Feed 是 ChatGPT 的事实来源（source of truth）。如果其中写着商品价格是 10 美元且有库存，那么用户在聊天里看到的就是这个。如果 Feed 与事实不符，轻则带来不满客户，重则违反政策并与 OpenAI 产生问题。

对商家的期望包括：

• 必填字段的正确性（价格格式正确、ISO 货币代码、有效的 HTTPS 链接、可用的图片）；
• 足够频繁地更新 Feed，避免售卖“幽灵库存”；
• 标识的一致性：Feed 中 SKU 的 id 必须与数据库和订单系统中的 ID 一致， 以便你能明确知道到底买的是哪个。

与传统电商类比，这里的 Product Feed 更像是“导出到某个市场”，只不过这个“市场”不是网站，而是住在用户脑海里的智能助手，它很容易记住不一致之处。

订单、配送与退款

ChatGPT 不会成为你的客服中心。用户当然在与它对话，但从法律上讲，用户是向商家购买商品，而不是向 OpenAI。也就是说：

• 你需要确保订单在你的系统中被创建并传达到仓库；
• 你需要确保包裹按 Instant Checkout 中的地址寄达；
• 你需要负责处理退款、取消、部分退款等。

在 ACP 中，checkout_session 成功结束后通常包含一个 order 对象。 但这只是你后端中发生事件的映射——你来决定表 orders 的记录长什么样、有哪些状态、它们如何与物流关联。

政策与地域

在 Merchants 门户中，你需要声明在哪些国家销售以及商品类型。OpenAI 会从自身角度核查你是否：

• 不售卖被禁止的品类；
• 遵守当地法律（例如税务规则与年龄限制）；
• 提供清晰的服务条款（Terms of Service）与隐私政策（Privacy Policy）。

在后续模块我们还会讨论法律页面，但现在就应当按这样的思路来想：“如果我不能清晰地向法务解释我卖什么、在哪里卖，ChatGPT 就很难替我销售。”

资金与支付服务商

最后是最“可怕”的部分——钱。好在 ACP 与 Delegated Payment 极大简化了开发者的工作：

• ChatGPT 与支付服务商（例如 Stripe）就某个固定金额与商家达成 Shared Payment Token；
• 你的后端在 complete 请求中收到该令牌，并在你的 PSP 中使用它，而无需看到“原始”的卡片数据。

也就是说，你不需要成为 PCI 合规的“怪兽”，不存储卡号，也不会掉进审计的泥潭。你的责任是正确使用委托令牌（创建支付、扣款、退款）并做好精确的账务记录。

5. 在 GiftGenius 架构中的落地

回到我们的教学应用 GiftGenius。从第 14 模块开始，我们希望学生能画出这样一张图：“用户 → ChatGPT → App 小部件 → MCP Gateway → Product Feed / Agents / ACP backend”。

在这张图里，商家的角色由我们的后端实现，而小部件与 App 只是商家在 ChatGPT 中的“门面”。

在代码中配置商家

从简单的步骤开始：在代码里建立一份商家配置结构。比如在我们的 Next.js 项目中创建一个 TypeScript 模块 lib/merchantConfig.ts：

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // 商家在 ACP/Stripe 中的 ID
  name: string;              // 便于阅读的名称
  feedUrl: string;           // 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, // 稍后再开启
};

这里首先我们明确了边界：这是商家，而不是“小部件”。其次，把重要的值放入环境变量——在部署与环境的模块中我们会多次强调，不要把这类内容硬编码。

为方便起见，可以添加一个简单函数，告诉我们的代码当前是否可以使用 Instant Checkout：

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // 在 dev 与 staging 环境始终关闭 Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

这样我们就为不同环境的差异化行为提前做好了架构准备，也避免自己（以及 GPT）在测试环境不小心跑到生产级别的 checkout。

MCP 工具：获取商家信息

通常最好给模型与小部件一个能力：了解商家当前所处的模式。比如，当 Instant Checkout 被关闭时，不要让 GPT 主动推荐它。

在 MCP 服务器（我们在前几个模块已经搭建过）里可以新增一个简单工具：

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

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "返回 GiftGenius 商家的基础信息",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

该工具本身并不复杂，但提供了一个明确的位置，让模型可以询问：“现在能否在聊天里直接购买，还是只能跳转链接？”。

在小部件中使用商家信息

在小部件端，借助我们熟悉的 Apps SDK hooks，可以调用 get_merchant_info，并根据模式切换 UI。下面是一个最简单的组件示例：

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

这样一个小组件可以清晰地提示用户（也方便你在开发模式下自查）当前与 ChatGPT 的集成处于何种状态。

6. 实践小练习

为了避免本讲停留在“空谈与图示”，请尝试在你的 GiftGenius 项目（或类似项目）里完成以下步骤：

首先，新增一个类似 merchantConfig.ts 的商家配置模块，并将 MERCHANT_ID 和 PRODUCT_FEED_URL 提取到环境变量。对于本地开发可使用 .env.local，生产环境用 Vercel 或其他平台的配置。

其次，在 MCP 服务器中实现一个简单的 get_merchant_info 工具，至少返回 name 与 instantCheckout。思考模型还可能需要哪些字段：例如支持的货币列表或配送国家列表。

第三，在小部件中添加一个小的 UI 元素（徽章、状态行、商品卡片上的标识），使用该 tool 显示当前商家的模式：仅推荐还是已经支持完整的 Instant Checkout。这不仅对 UX 有用，也非常利于调试。

最后，尝试以文字方式梳理你的项目如何从“我们有网站与后端”一步步走到获得 ChatGPT 商家资格。你将在何处接入 Product Feed，何时开启 enable_checkout，何时开始实现 ACP 端点。这样的演练有助于自我约束，避免忽略诸如退款政策等“不太受欢迎”的事项。

7. 通往 ChatGPT 商家的典型错误

错误 1：“ChatGPT 就是我的商店”。
有时开发者会在心智上把一切“搬”到 ChatGPT 端：仿佛它既存储目录、又计算价格、还履行订单。实际上，ChatGPT 是界面与编排器，而不是你的 ERP。如果忘了这一点，很容易设计出没有自有订单模型的架构，数据“散落在提示词里”，只要模型行为有变更，就会威胁一致性。

错误 2：未做单独注册与 ACP 实现却期待 Instant Checkout。
写好一个小部件并配置 Product Feed，并不会自动开启 Instant Checkout。你还需要在 Merchants 门户提交申请、通过品类审核、实现 Agentic Checkout 与 Delegated Payment，并通过测试。指望“默认就有 Instant Checkout”往往会导致 GPT 向用户承诺并不存在的能力，或给出链接而非预期的支付界面。

错误 3：把商家标识与 URL 硬编码在代码里。
典型情形：MERCHANT_ID = "prod-123" 直接写死在代码里，Feed 的 URL 也写在小部件组件中。一旦出现 staging 或需要第二个商家，就会陷入大范围“查找‑替换”。更安全的做法是把这些内容抽到配置与环境变量，并通过一个小的抽象层使用它们，就像我们用 MerchantConfig 那样。

错误 4：Product Feed 与订单系统彼此脱节、各自为政。
如果 Feed 中 SKU GIFT_RED_MUG 的价格是 10 美元，而订单库里对同一标识因为某些原因却扣了 12 美元，迟早会暴露问题。价格与库存的事实来源应当要么来自你的内部数据生成的 Feed，要么来自 Feed 与 checkout 都信任的公共中间层。试图做“双重记账”（一套给 ChatGPT、一套给自家网站）很快会带来麻烦。

错误 5：忽视支付服务商的角色并尝试存取支付数据。
有时会忍不住“窥探”支付服务商的令牌，甚至在自家 UI 中向用户额外索要支付信息。这不仅破坏 Delegated Payment 模式，还可能把你拖入 PCI DSS 与沉重合规中。正确实践是把 Shared Payment Token 当作不透明字符串，只在支付服务商的 SDK 中使用，且不要记录日志或缓存。

错误 6：低估入驻流程的多步骤性且缺乏计划。
最后一个常见的组织层面错误是以为“我们就接个 ChatGPT，有什么难的”。实际上，成为商家的路径包含大量步骤：技术的（Feed、后端、测试）与非技术的（法律文档、品类确认、地域限制）。如果不把路径预先写出来，团队就会在任务之间混乱跳转，截止日期也会“蒸发”得比你对 AI‑commerce 的热情更快。