ChatGPT Merchants 與商家的全流程：從註冊到責任

1. 什麼是 ChatGPT 商家？它與「一般網店」有何不同

從開發者視角，很容易混淆層級：我們有 Next.js 應用、MCP 伺服器、某個 commerce backend，還有 OpenAI、ChatGPT、Stripe 與其他大型服務。很想說：「反正都是同一套系統，只要測試是綠的就行」。

然而在 AI‑commerce 世界，法律與技術邊界劃得非常清楚。ChatGPT 不會變成你的商店，也不會成為付款處理器。它只提供智慧介面，並依公開規格呼叫你的 API。商家仍是具體的公司，擁有具體的目錄，並對使用者承擔責任。

理解商家的角色不僅是法務的事。它會影響你的架構決策：feed 資料存在哪裡、如何驗證訂單、記錄什麼日誌、以及如何調試聊天中展示的結果與你系統中實際發生之間的差異。

範例

想像典型的 e‑commerce：你有網站、購物車、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 服務的商家 backend 團隊。

2. ChatGPT Merchants 入口：從申請到上線商家

OpenAI 有一個專門給賣家的網站—— ChatGPT Merchants。 透過它，賣家能加入 Instant Checkout 計畫並接上自己的 feed 與 backend。我們將把這條路徑拆成幾個步驟，暫不深入技術細節（下一講會講）。

事前準備

在你團隊中有人按下「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 的 pre‑signed URL，或是一個你定期 POST 更新的 HTTPS 端點。
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

最後階段——檢查你的 backend 在真實情境下的表現：

• 是否正確建立訂單；
• 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 自建 backend

好消息：不是所有商家都必須自己寫完整的 ACP backend。對某些平台（Shopify、Etsy 等）已經有現成整合，會替你承擔技術實作。

如果你透過 Shopify 或 Etsy 銷售，流程大致如此：在它們的後台開啟類似「Show in ChatGPT」的選項，平台會自行：

• 生成並維護符合要求的 Product Feed；
• 實作或代理 ACP 端點；
• 銜接 Stripe 或其他 PSP。

你作為店主，更多是在管理品項與描述，而不是 REST 端點。

若你像我們課程中的 GiftGenius 一樣，打造有自家 backend 的自建商家，你會有更大的自由，但也有更多工作：feed、checkout 與支付供應商整合都要自己寫。

下表簡單對比：

在課程中我們刻意選第三種：唯有如此，我們才能走完整條從 feed 到 webhook，再到穩健上線的道路。

4. 商家的責任：資料、訂單、政策、金流

當你成為 ChatGPT 商家後，你不僅獲得新訂單的喜悅，也要承擔一組非常具體的義務。讓我們分層來看。

目錄資料與 Product Feed 品質

Product Feed 是 ChatGPT 的單一真相來源。如果其中標示商品價格為 10 USD 且顯示有貨，使用者在對話中就會看到這樣的資訊。若 feed 不可信，輕則招致不滿的客戶，重則違反政策並與 OpenAI 產生麻煩。

對商家的期望：

• 必填欄位正確（正確的價格格式、ISO 貨幣代碼、有效的 HTTPS 連結、可用的圖片）；
• 足夠頻繁地更新 feed，避免販售幽靈存貨；
• 識別碼一致性：id（SKU）在 feed 中必須與你的資料庫與訂單系統的 ID 一致， 這樣你才能明確知道究竟買了什麼。

類比一般 e‑commerce，Product Feed 就像你的「上傳到市集的匯出檔」，只不過這個市集不是網站，而是住在使用者腦中的智慧助理，且很容易記住不一致之處。

訂單、配送與退款

ChatGPT 不會變成你的客服部門。使用者當然會與它互動，但法律上，他是向商家購買，而不是向 OpenAI。也就是說：

• 你負責讓訂單在你的系統中被建立並送達倉庫；
• 你負責讓包裹送達使用者在 Instant Checkout 中填寫的地址；
• 你負責處理退貨、取消、部分退款等。

在 ACP 中，checkout_session 成功結束後通常會包含 order 物件及其欄位。 但那只是你 backend 中發生之事的映射——由你決定資料表 orders 的結構、擁有哪些狀態、以及它們如何與物流關聯。

政策與銷售地區

在 Merchants 入口中，你會指定在哪些國家販售、販售哪些商品類型。OpenAI 會檢查你是否：

• 未販售被禁止的類別；
• 遵守當地法律（例如稅務規則與年齡限制）；
• 提供清楚的服務條款（ToS）與隱私政策（Privacy Policy）。

在後續模組我們還會談法律頁面，但現在就該以這種方式思考：「如果我無法向法務清楚說明我賣什麼、在哪裡賣，ChatGPT 大概也不會替我賣」。

金流與支付供應商

最後，也是最讓人緊張的——金流。幸好 ACP 與 Delegated Payment 大幅簡化開發者的工作：

• ChatGPT 與支付供應商（例如 Stripe）會就特定金額與商家協商出 Shared Payment Token；
• 你的 backend 會在 complete 請求中收到此權杖，並在你的 PSP 中使用，而不會看到「原始」卡片資料。

也就是說，你不必變成 PCI 相容的怪獸、不儲存卡號、也不會陷入稽核噩夢。你的責任是正確使用委派權杖（建立付款、扣款、退款），並謹慎做好帳務。

5. 在 GiftGenius 架構中的落地

回到我們的教學應用 GiftGenius。在架構層面上，完成第 14 模組之後，我們希望學生能畫出這樣的示意：「使用者 → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend」。

在此架構中，商家的角色由我們的 backend 承擔，而 widget 與 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）從測試環境不小心走進正式結帳。

用 MCP tool 讀取商家資訊

常見的做法是讓模型與 widget 能知道商家目前的運作模式。例如：在關閉時別讓 GPT 推 Instant Checkout。

在 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),
    };
  },
};

這個工具沒有做什麼了不起的事，但提供了一個明確的位置，讓模型可以發問：「現在能在對話裡直接購買，還是只能跳連結？」。

在 widget 中使用商家資訊

在 widget 端，利用我們熟悉的 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，在 production 則使用 Vercel 或其他平台的設定。

其次，在 MCP 伺服器實作一個簡單的 get_merchant_info 工具，至少回傳 name 與 instantCheckout。想想還有哪些欄位對模型有用：例如支援的幣別或配送國家清單。

第三，在 widget 加上一個小 UI 元件（徽章、狀態列、或商品卡片上的註記），使用這個 tool 告訴使用者你的商家目前處於哪個模式：僅推薦（discovery only）或已開啟 Instant Checkout。這不僅對 UX 有幫助，也非常利於除錯。

最後，嘗試用文字列出你的專案將如何從「我們有網站與 backend」走到 ChatGPT 商家狀態。你會在哪裡接上 Product Feed、何時開啟 enable_checkout、何時開始實作 ACP 端點。這樣的練習很能自我約束，並幫助你不要忘記那些不討喜但重要的事情，例如退貨政策。

7. 通往 ChatGPT 商家的常見錯誤

錯誤一：「ChatGPT 就是我的商店」。
有時開發者會在心中把一切都「搬到」ChatGPT 那邊：彷彿它會存放目錄、計算價格、履行訂單。事實上，ChatGPT 是介面與協調者，而不是你的 ERP。如果忘了這點，很容易打造出沒有正常訂單模型的架構，所有資料都「活在 prompt 裡」，而模型行為的任何變化都可能讓一致性付諸東流。

錯誤二：未經獨立註冊與 ACP 就期待有 Instant Checkout。
寫了一個很棒的 widget 並設定好 Product Feed，並不會自動開啟 Instant Checkout。你還需要在 Merchants 入口申請、通過類別審查、實作 Agentic Checkout 與 Delegated Payment、並通過測試。若預設就指望有 Instant Checkout，往往會導致 GPT 向使用者承諾其實不存在的能力，或者在預期付款畫面處改成給連結。

錯誤三：把商家識別與 URL 寫死在程式裡。
經典案例：MERCHANT_ID = "prod-123" 被硬寫在程式中，feed 的 URL 也直接寫在 widget 元件裡。一旦你有了 staging 或需要新增第二個商家，就得進行大規模搜尋替換。將這些東西抽到組態與環境變數中，並透過小小的抽象層使用，會更安全，正如我們對 MerchantConfig 所做的。

錯誤四：Product Feed 與訂單系統各過各的。
如果在 feed 中 SKU GIFT_RED_MUG 的價格為 10 USD，但在訂單資料庫裡你卻因某些原因以 12 USD 扣款，遲早會出事。價格與庫存的真實來源應該是由你的內部資料彙整出的 feed，或是一個 feed 與 checkout 都信任的共同層。試圖維持「雙重帳本」（一套給 ChatGPT、另一套給自家網站）很快就會出問題。

錯誤五：忽視支付供應商的角色與支付資料的保存界線。
有時候會忍不住想「偷看」支付供應商的權杖，或在自己的 UI 額外向使用者索取支付資訊。這不僅違反 Delegated Payment 的模型，還可能把你拖進 PCI DSS 與繁重的合規世界。正確作法是把 Shared Payment Token 視為不透明字串，只在支付供應商的 SDK 內使用，並且不記錄、不快取。

錯誤六：低估導入流程的多步驟性且沒有計畫。
最後一個常見的組織性錯誤，是認為「我們就接上 ChatGPT，有什麼難的」。事實上，商家的道路由許多步驟組成：技術面的（feed、backend、測試）與非技術面的（法律文件、類別核可、地區限制）。如果事先不把路徑寫清楚，團隊就會在任務之間混亂跳轉，時程也會比你對 AI‑commerce 的熱情消退得更快。