Tags: ChatGPT Commerce, OpenAI, ACP, Architecture, eCommerce, Agentic Commerce Protocol, Delegated Payment, Merchant Edge

ChatGPT Commerce 不会取代商家的商务体系。OpenAI 目前的模式从结构化商品信息流开始，然后通过 Agentic Commerce Protocol 流程和委托支付来连接商务动作，而商家仍然拥有支付处理、订单接收、履约、退款、拒付、合规和客户支持的责任。

这是一个有用的起点，因为它让讨论保持脚踏实地。有趣的部分不是"AI 购物"这个口号。有趣的部分是开发者必须暴露、编排和治理哪些东西，才能让一个新的对话式渠道安全地使用现有的商务系统。

如果你是接到这个项目的人，实际问题不是 ChatGPT 能不能展示商品。OpenAI 已经文档化了商家如何通过 ACP 接入目录数据并支持结账。真正的问题是你的现有架构能否在不让 ChatGPT 与店铺代码耦合、不重复业务逻辑、不造成支付和订单状态不一致的前提下，支持一个新渠道。

OpenAI 实际文档化的内容

OpenAI 当前的商务指南描述了想要参与这一模式的商家的三个核心构建块。

第一，商家分享结构化商品信息流，让 ChatGPT 能够索引商品、理解核心属性，并在购物体验中展示准确的商品信息。OpenAI 建议从这里开始，并说明商品信息流接入 ChatGPT 目前对获批合作伙伴开放。

第二，ChatGPT 可以调用商家的 ACP 端点来创建或更新结账会话，安全地传递买家和履约信息，并在商家验证交易并决定接受或拒绝后接收订单状态。OpenAI 还说明结账界面嵌入在 ChatGPT 中，而实际的结账状态和支付处理保留在商家的系统上。

第三，OpenAI 的委托支付规范允许 OpenAI 安全地与商家或其指定 PSP 分享支付详情。商家和 PSP 随后以与其他数字交易相同的方式处理支付，OpenAI 明确声明自己不是记录商家。

这是事实层面的平台模式。本文其余部分都是关于如何围绕该模式干净地构建的实施建议。

开发者需要构建什么

实际上，一个商家集成需要五个可工作的层级。

可靠的商品信息流管道。
用于 ACP 请求的渠道安全商家边缘层。
对定价、促销、库存、税务和物流等核心商务服务的访问。
与现有 PSP 或 vault 的委托支付集成。
与 OMS、履约、退货和支持系统的售后连接。

这之所以重要，原因很简单：ChatGPT 可以成为一个新的意图和结账界面，但它仍然依赖商家的系统来完成底层交易。如果这些系统是碎片化的、不一致的，或者隐藏在店铺专属逻辑后面，ChatGPT 渠道会迅速暴露这些弱点。

这就是为什么这应该被视为一个系统集成项目，而不是一个聊天机器人功能。

架构视图

ChatGPT Commerce 架构图，展示五个层次：ChatGPT 渠道、商家边缘层、商务服务、支付栈和订单运营

本文推荐的架构将实施过程分解为五个层次：ChatGPT 渠道、商家边缘层、商务服务、支付栈和订单运营。这是架构建议，不是 OpenAI 的官方图，但它与 OpenAI 商务模式中记录的责任划分高度吻合。复制以下 FlowZap Code 到你的 FlowZap 账户中的图表里，开始编辑以适配你的用例！

merchantEdge { # 商家边缘层
  n1: rectangle label="发布商品信息流"
  n2: rectangle label="验证信息流"
  n3: rectangle label="暴露 ACP 端点"
  n4: rectangle label="创建结账会话"
  n5: diamond label="批准订单？"
  n6: rectangle label="返回订单结果"
  n1.handle(right) -> n2.handle(left)
  n2.handle(right) -> n3.handle(left)
  n3.handle(right) -> n4.handle(left)
  n4.handle(right) -> n5.handle(left)
  n5.handle(right) -> n6.handle(left) [label="是"]
  n2.handle(bottom) -> commerce.n7.handle(top) [label="刷新目录状态"]
  n4.handle(bottom) -> payment.n11.handle(top) [label="委托支付请求"]
  n6.handle(bottom) -> operations.n14.handle(top) [label="创建订单事件"]
  n6.handle(top) -> chatgpt.n20.handle(bottom) [label="订单结果"]
}

commerce { # 商务服务
  n7: rectangle label="解析内容"
  n8: rectangle label="解析价格促销"
  n9: rectangle label="解析库存"
  n10: rectangle label="解析税务物流"
  n7.handle(right) -> n8.handle(left)
  n8.handle(right) -> n9.handle(left)
  n9.handle(right) -> n10.handle(left)
  n10.handle(top) -> merchantEdge.n4.handle(bottom) [label="结账数据"]
}

payment { # 支付栈
  n11: rectangle label="Tokenize 支付"
  n12: rectangle label="授权支付"
  n13: rectangle label="返回授权状态"
  n11.handle(right) -> n12.handle(left)
  n12.handle(right) -> n13.handle(left)
  n13.handle(top) -> merchantEdge.n5.handle(bottom) [label="已批准或已拒绝"]
}

operations { # 订单运营
  n14: rectangle label="创建 OMS 订单"
  n15: rectangle label="预留库存"
  n16: rectangle label="触发履约"
  n17: rectangle label="处理退货支持"
  n14.handle(right) -> n15.handle(left)
  n15.handle(right) -> n16.handle(left)
  n16.handle(right) -> n17.handle(left)
  n17.handle(top) -> chatgpt.n21.handle(bottom) [label="服务与支持"]
}

chatgpt { # ChatGPT 渠道
  n18: circle label="购物者意图"
  n19: rectangle label="展示商品"
  n20: rectangle label="显示确认"
  n21: circle label="支持入口"
  n18.handle(right) -> n19.handle(left)
  n19.handle(right) -> n20.handle(left)
  n20.handle(right) -> n21.handle(left)
  n18.handle(left) -> merchantEdge.n3.handle(right) [label="发现请求"]
  n19.handle(left) -> merchantEdge.n4.handle(right) [label="会话请求"]
  n20.handle(left) -> merchantEdge.n5.handle(right) [label="购买批准"]
}

从信息流开始

OpenAI 推荐的集成路径从商品信息流开始，这对工程实施来说也是正确的起点。信息流让 ChatGPT 获得理解标题、描述、图片、价格、库存和其他核心商品属性所需的目录数据。

指南已经足够具体，可以转化为真正的交付计划。OpenAI 推荐文件上传或 API，一般建议每天通过文件上传发送完整信息流一次，并在白天用 API 进行更新，同时说明促销数据只能通过 API 提供。它还要求验证必填字段并定期刷新数据。

对开发者来说，这转化为具体的工作：

确定每个信息流字段的记录系统。
将内部商品模型映射到文档化的 schema。
对每条记录验证必填字段。
发布每日快照。
对价格、库存和促销进行日内变更推送。
监控信息流新鲜度和 schema 失败。

这项工作并不光鲜，但它是基础性的。店铺前端可以用模板、导航和商品逻辑掩盖糟糕的目录结构。机器可读的信息流无法做到这一点。

构建商家边缘层

OpenAI 在协议层面文档化了流程，但它并不要求商家通过店铺控制器或页面专属 API 来暴露这些能力。这正是架构判断发挥作用的地方。

最干净的实现通常是构建一个商家边缘层：一个网关或编排层，接收来自 ChatGPT 的请求并协调底层商务服务。该层应为发现、结账会话创建、结账更新、支付完成和售后服务查询暴露渠道安全的端点。

商家边缘层应在四个方面做得很好：

将 ChatGPT 请求翻译为内部服务调用。
将下游响应规范化为渠道就绪数据。
应用策略、可观测性、幂等性和链路追踪。
让该渠道与店铺专属行为保持解耦。

最后一点很重要。如果 ChatGPT 渠道依赖会话 cookie、页面渲染逻辑或店铺控制器，集成会变得脆弱。更好的模式是让 ChatGPT 消费商务能力，而不是店铺实现细节。

一个实用的能力表面可能包括如下函数：

searchProducts(query, locale, filters)
getProduct(productId)
createCheckoutSession(items, buyerContext)
updateCheckoutSession(sessionId, shippingAddress, deliveryChoice, promoCode)
completeCheckout(sessionId, delegatedPaymentToken)
getOrderStatus(orderId)
getReturnEligibility(orderId, itemIds)
openSupportCase(orderId, reason)

这些端点名称是架构示例，不是 OpenAI 发布规范的一部分。要点在于商家边缘层应编排业务能力，而不是复用店铺 API。

让真相留在源系统中

集成项目中一种常见的失败模式是将中间件变成意外的第二真相源。这个渠道应避免这种情况。

商家边缘层应编排，而非拥有现实。商品真相应留在目录或 PIM 中。定价真相应留在定价和促销服务中。库存真相应留在库存或 ATP 服务中。税务和物流真相应留在对应的计算器中。订单真相应留在 OMS 中。支付真相应留在 PSP 和商家的支付系统中。

这种设计让对账变得可控，也让新渠道更容易运营。

委托支付的实际工作原理

OpenAI 的委托支付规范足够具体，开发者无需猜测即可理解整个流程。

根据规范，买家在 ChatGPT 中使用保存的首选支付方式结账。OpenAI 随后将委托支付载荷直接发送给商家的 PSP 或 vault。委托支付是一次性的，并受额度限制，如最大金额、货币、结账会话 ID、商家 ID 和到期时间。PSP 或 vault 返回一个限定于该委托支付的支付 token，OpenAI 在 complete-checkout 调用中转发该 token，以便商家完成交易。

OpenAI 还声明了几项重要约束。OpenAI 不是记录商家。商家应自带 PSP，并以处理任何其他数字交易的方式处理支付。结算、退款、拒付和合规仍由商家及其 PSP 负责。直接与委托支付规范集成面向 PSP 或使用自有 vault 的 PCI DSS Level 1 商家，而其他商家可以使用兼容的 PSP 实现，例如 Stripe 的 Shared Payment Token 路径。

从实施角度来看，结论很直接：不要重新设计支付。将委托 token 流程集成到商家现有的 PSP 路径中，保持幂等性和可追溯性，并仅在商家端的授权和策略检查通过后才创建订单。

实用的运行时序列

一旦信息流存在且商家边缘层就位，端到端运行时就更易于推理。

购物者在 ChatGPT 中表达意图。
ChatGPT 通过商家边缘层请求商品数据。
商家边缘层查询目录、定价和库存服务并返回规范化结果。
ChatGPT 通过 ACP 兼容端点发起或更新结账会话。
商家边缘层从权威服务解析物流、税务、促销和最终总价。
OpenAI 通过 PSP 或 vault 流程触发委托支付。
商家接收委托支付 token 并在自有系统上完成授权。
商家接受或拒绝订单并将该状态返回给 ChatGPT。
若获批准，商家创建 OMS 订单、预留库存并触发下游履约。
售后服务通过商家自身的运营系统继续进行。

这个序列并非从单个 OpenAI 页面复制而来。它是已记录的信息流、结账和支付流程的实践性综合，形成了一套可实施的商家架构。

通常最先出问题的地方

这个架构中的薄弱点通常并不令人意外。

信息流数据与真实库存产生偏差。
促销在不同服务中的解析方式不同。
物流和税务总价在各步骤之间发生变化。
PSP token 流程在重试或过期方面遇到边界情况。
欺诈和风险逻辑在设计时未考虑这一渠道。
OMS 或支持系统集成得不够早。

OpenAI 自身的指南已经暗示了一个重要修复：如果底层商务状态变化比每天一次更频繁，应使用每日快照加 API 更新，而不是依赖静态的每日一次信息流。促销也明确由 API 驱动，这意味着商家需要一个比静态文件交付更强大的更新路径。

其余部分归结为熟悉的工程纪律：单一的权威结账计算路径、清晰的服务所有权、幂等写入，以及对每个关键过渡的可观测性。

现实的分阶段上线

最安全的上线方式是窄范围推进。

OpenAI 说明 ChatGPT 中的商品信息流接入目前对获批合作伙伴开放，ChatGPT 中的 Instant Checkout 也同样仅对获批合作伙伴开放。这意味着第一阶段不是全面生产上线。它是准备、准入和范围控制。

一个实用的分阶段计划如下：

阶段 0：准备

确认合作伙伴准入路径。
撰写一份简短的架构说明。
确定源系统和负责人。
审查禁售商品政策和合规责任。

阶段 1：目录准备

映射信息流字段。
验证必填字段。
生成并提交初始样本。
发布每日快照。
为变化数据添加日内 API 更新。

阶段 2：交易编排

构建商家边缘层端点。
连接定价、库存、税务、物流和促销服务。
将委托支付与 PSP 路径集成。
返回商家自有的订单决策和确认状态。

阶段 3：售后运营

连接 OMS 事件。
添加订单状态查询。
添加取消和退货资格逻辑。
通过商家的服务栈路由支持请求。

这个分阶段计划不是 OpenAI 强制要求的，但它符合文档化的平台模式，并通过避免"一次性连接所有东西"的上线方式降低了风险。

该向管理层说什么

管理层团队听到"ChatGPT Commerce"时，可能会误以为这是一个聊天机器人附加组件或轻量 UI 集成。更准确的描述则不同。

这是一个新渠道，通过结构化信息流、基于 ACP 的结账流程和委托支付，利用商家现有的商务能力，而商家仍保留对支付、订单接受、履约、合规和客户支持的责任。

这种 framing 很有用，因为它让对话保持诚实。机会是真实的，但实施工作也同样真实。

总结

看待 ChatGPT Commerce 最有用的方式不是把它当作商务体系的替代品，而是把它当作一个新的意图渠道，它要求商家已有的体系得到更干净的暴露。OpenAI 的文档明确指出了商家对商品质量、支付处理、订单接受和运营跟进的所有权。

实施中的原创性不是来自发明关于平台的新事实。它来自把商家边缘层建好、把业务真相留在正确的系统中、以及以窄范围、可观测、可支持的方式推出这个渠道。

为 ChatGPT Commerce 做好准备：一份实用的企业实施规划