ACP核心概念

1.1 ACP在AI代理商务中的角色

ACP（Agentic Commerce Protocol）由Stripe创建，是一套开放标准，定义了程序化商务交互的协议。OpenAI ChatGPT是首个实现者，但ACP被设计为可被任何AI平台采用。 核心区别: UCP是通用的多平台协议（Google/Shopify等联合发起），ACP则由Stripe创建并首先在ChatGPT生态实现。

1.2 四方模型

ACP定义了四个参与方：

买家 (Buyer)
  ↕ 通过AI对话交互
AI代理 (Agent, 如ChatGPT)
  ↕ 调用Checkout API
商家 (Business)
  ↕ 委托支付处理
支付服务商 (Payment Provider, 如Stripe)

参与方	角色	示例
Buyer	发起购买意图的消费者	ChatGPT用户
Agent	代替买家执行商务操作的AI	ChatGPT
Business	提供商品和结账服务的商家	在线零售商
Payment Provider	安全处理支付凭证	Stripe

1.3 两套独立系统

ACP不是单一API。它由两套完全独立的系统组成：

系统1: Product Feed（商品数据同步）

方向: 商家 → OpenAI平台商家将商品目录数据推送到OpenAI。ChatGPT利用这些数据在用户对话中展示相关商品。

商家商品数据库
  ↓ SFTP文件上传 (每日全量快照)
  ↓ REST API (白天实时增量)
OpenAI Product Feed系统
  ↓ 索引和理解
ChatGPT在对话中展示商品

支持的数据提交方式：

SFTP推送: Parquet(zstd压缩) / jsonl.gz / csv.gz / tsv.gz
REST API: Feeds + Products + Promotions端点

系统2: Agentic Checkout（结账交易）

方向: AI代理 → 商家服务器当用户确认购买时，AI代理调用商家自建的Checkout API端点完成交易。

用户: "我要买这双鞋"
  ↓
ChatGPT → POST /checkout_sessions (创建结账会话)
ChatGPT → POST /checkout_sessions/:id (更新收货地址)
  ↓
Stripe Delegate Payment API → 获取vault token (vt_...)
  ↓
ChatGPT → POST /checkout_sessions/:id/complete (提交支付)
  ↓
商家确认订单

1.4 Checkout会话状态机

每个结账会话有一个状态，按以下流程变化：

incomplete
  ↓
not_ready_for_payment
  ↓ (收货地址、买家信息补全)
ready_for_payment
  ↓ (提交支付)
complete_in_progress
  ↓
completed

完整的状态枚举：

状态	说明
`incomplete`	会话刚创建，信息不完整
`not_ready_for_payment`	缺少必要信息（地址、配送方式等）
`requires_escalation`	需要人工介入
`authentication_required`	需要3DS等身份验证
`ready_for_payment`	所有信息齐全，可以支付
`pending_approval`	等待审批
`complete_in_progress`	支付处理中
`completed`	交易完成
`in_progress`	处理中
`canceled`	已取消
`expired`	已过期

1.5 支付委托（Delegate Payment）

ACP通过Delegate Payment API解决支付安全问题。AI代理永远不会把原始卡号传给商家。流程：

AI代理将支付凭证发送到Stripe的 POST /agentic_commerce/delegate_payment
Stripe对卡号进行tokenization，返回一个vault token（格式 vt_...）
AI代理将vault token（不是卡号）传给商家的 /checkout_sessions/:id/complete
商家用vault token向Stripe请求实际扣款

安全保证: 商家从未接触到原始卡号，PCI合规由Stripe处理。

1.6 价格格式

ACP中所有金额使用ISO 4217 minor currency units（最小货币单位）：

实际金额	ACP中的值	货币
$79.99	7999	USD
¥399.00	39900	CNY
€49.50	4950	EUR
¥1000 (日元，无小数)	1000	JPY

{
  "amount": 7999,
  "currency": "USD"
}

金额必须大于等于0，货币使用ISO 4217三字母代码。

1.7 Capabilities协商

ACP支持商家和AI代理之间的能力协商。商家在创建Checkout Session的响应中声明自己支持的能力：

Payment handlers: 支持的支付方式（handler ID、版本、规范URL、schema）
Interventions: 是否支持重定向、人工介入等交互方式
Extensions: 扩展能力声明（语义化版本号 + 可选日期，JSONPath定义扩展字段）

1.8 ACP vs 传统电商 vs UCP

维度	传统电商	UCP	ACP
商品展示	商家自己的网站	AI代理调用商家API	ChatGPT从Feed数据中展示
数据控制	完全在商家侧	商家侧（API端点）	推送到OpenAI + 商家自建Checkout
支付	直接支付网关	Payment Token Exchange	Delegate Payment (vault token)
订单	商家系统管理	标准化Order API	Checkout完成后返回Order

下一章: 商品数据格式 — Product对象、Variant、价格、媒体、可用性的完整字段规范

ACP 代理商务协议 ACP商品数据模型字段规范

开始

学习路径

AI代理商务入门

OTR 开放信任协议

UCP 通用商务协议

ACP 代理商务协议

MCP 模型上下文协议

AI时代的SEO

ORBEXA 一体化方案

模板与提示词

术语词典

ACP协议架构与四方模型详解

ACP核心概念

1.1 ACP在AI代理商务中的角色

1.2 四方模型

1.3 两套独立系统

系统1: Product Feed（商品数据同步）

系统2: Agentic Checkout（结账交易）

1.4 Checkout会话状态机

1.5 支付委托（Delegate Payment）

1.6 价格格式

1.7 Capabilities协商

1.8 ACP vs 传统电商 vs UCP

​ACP核心概念

​1.1 ACP在AI代理商务中的角色

​1.2 四方模型

​1.3 两套独立系统

​系统1: Product Feed（商品数据同步）

​系统2: Agentic Checkout（结账交易）

​1.4 Checkout会话状态机

​1.5 支付委托（Delegate Payment）

​1.6 价格格式

​1.7 Capabilities协商

​1.8 ACP vs 传统电商 vs UCP

ACP核心概念

1.1 ACP在AI代理商务中的角色

1.2 四方模型

1.3 两套独立系统

系统1: Product Feed（商品数据同步）

系统2: Agentic Checkout（结账交易）

1.4 Checkout会话状态机

1.5 支付委托（Delegate Payment）

1.6 价格格式

1.7 Capabilities协商

1.8 ACP vs 传统电商 vs UCP