Checkout.com：让商户接收 AI 平台创建的受限支付凭证

类型：商户支付处理与 ACP 委托支付接口｜面向：AI 平台、企业商户｜资料核验：2026-10-28｜API 未实测。

在聊天里选好商品后，AI 平台如何把支付能力交给商户，又避免把用户卡号直接交给购物 Agent？Checkout.com 的 ACP 接口围绕这个问题提供受限、单次使用的委托支付 Token，供获准的商户处理交易。

背景和市场位置

Checkout.com 为企业提供线上支付处理。公司于 2025 年 11 月宣布采用 Agentic Commerce Protocol（ACP），目标是帮助商户接入 AI 平台的购物与结账。它的 ACP API 目前标注 Beta，要求 AI 平台联系公司开通；这是一项商户及平台支付集成，不是面向所有人的独立 Agent 钱包。ACP 公告 · API 参考

从授权到委托凭证

sequenceDiagram participant U as 消费者 participant A as AI 平台 participant C as Checkout.com participant M as 已开通商户 U->>A: 确认购买与付款方式 A->>C: 提交卡资料、限制和风险信号 C-->>A: 创建单次委托支付 Token A->>M: 传递订单及 Token M->>C: 在支持的集成中处理支付 C-->>M: 返回支付处理结果

按 API 文档，创建委托 Token 的请求包含卡支付方法、allowance、风险信号和元数据，并用签名及时间戳验证请求完整性。示例中的 allowance 包含最大金额、币种、商户 ID、结账会话和过期时间。这证明接口支持表达这些约束，不代表任何 Agent 都有权调用，也不证明所有限制在任意下游系统均已执行。 文档也描述幂等键和未经启用商户可能返回 403，值得集成方测试。API 参考

判断维度	官方材料显示	仍须确认
Agent 权限	面向限定范围、单次 Token	用户同意如何获得、金额和期限如何强制执行
原始卡资料	平台向受控接口提供支付方法，Token 用于商户处理	哪些系统接触卡数据及其 PCI 责任
商户接入	AI 平台需要 onboarding，商户需获启用	哪些地区、AI 平台、商户与支付方式可用
交易保障	传递风险信号并支持请求完整性检查	发卡方批准、退款、拒付和责任分配
重复请求	提供可选幂等键	端到端重试及异常订单恢复策略

Token 的生成不是付款完成。发卡方可能拒绝，订单可能失败，商户仍须处理履约和售后。Checkout.com 的商户问答说明，商户通常仍是 merchant of record，并承担与现有模型有关的欺诈、拒付和争议责任；具体交易仍需以合同和网络规则为准。官方问答

商业模式和竞争

Checkout.com 的商户业务以支付处理及相关服务为基础。ACP API 的专项费率、AI 平台收费与收入分成在上述材料未给出统一公开报价，需直接核实。将现有商户处理能力带入新的 AI 渠道可能有助于保持交易量，这是分析推断，不等于已经公开对应收入。

与 Stripe SPT 相比，两者都围绕受限的委托支付凭证，但 Token 生命周期、平台支持、商户准入、风险信号、合同和支付方式可能不同。与 Visa TAP 比较，TAP 更关注可信 Agent 与商户通信；Checkout.com 的此项接口关注创建可供商户处理的支付凭证。两者也可能参与同一支付链路的不同环节。

集成前应做四项核验：确认 Beta 与商户资格；获取 Token 限额和撤销规则；测试付款失败及幂等行为；梳理退款、争议、客户支持和风控责任。

一个 API 请求背后的责任划分

Checkout.com 的示例将用户选择的卡支付方法和由平台传入的 allowance 放在同一个受保护请求中。官方文档显示可按最大金额、币种、商户、checkout session 和过期时间表达边界，并要求请求签名、时间戳及风险信号。它生成的 Token 是给受支持商户使用的委托凭证。消费额度可能约束凭证的使用，但购买内容是否符合用户意图，还要依赖平台、商户以及相关授权信息。ACP API

例如用户同意以不超过 $100 购买一双鞋，商户最终总价 $105 时，平台与商户需要知道能否调整、重新授权或直接拒绝。官方接口描述允许范围及处理校验，不足以证明任何特定税费变化场景都支持自动处理。相同地，生成 Token 后持卡人仍可能被发卡方拒绝，商户不可把 Token 创建成功当作收款成功。

处理失败的顺序比“是否支持 Agent”更重要

凭证创建失败：检查平台认证、时间戳签名及字段；文档列出 400、401 和 422 等响应。
商户未开通：文档列出 403；要核对商户和平台的启用关系，而不是盲目重复请求。
网络中断：记录幂等键，查询原始操作状态，再根据接口合同决定是否重试；相同幂等键与不同请求体可能返回 409。
支付已获批但订单失败：核对商户订单和支付状态，按合同决定撤销或退款。
发生争议：关联用户授权、Agent、订单、Token 约束和支付结果，由相关商户、服务商及网络按适用规则处理。

这是依据 API 已列出的响应状态和通常的订单生命周期编写的验证清单；后两项的具体接口和责任并未在该文档中得到完整证明。API 参考

买方成本、商户收入和平台费分开算

消费者看到的订单总价、商户实际收到的结算款与 Checkout.com 的服务收入是三个数字。支付方式、卡网络、换汇、退款和合同都可能改变商户成本。比如 $100 订单，即使商户账单显示多个费用项目，也不能把它们全部称为 Checkout.com 的 Agent 产品收入。其 ACP 专项统一费率未公开确认；应让销售提供实际交易地区、卡类型、额度及争议情形下的书面报价。

比较服务商时，首先确认同一个商户和 Agent 平台是否可接，再比较超时重试、风险信号和商户控制；若只比较两家的“单次 Token”，很容易忽略订单完整性和售后能力。商户问答

参考资料

ACP API 参考：Beta 状态、请求字段和错误。
Checkout.com ACP 公告。
Agentic commerce 官方问答。