支付服务域

范围

本域定位

支付服务域（Payment Services Domain, PSD）规定智能体在完成支付前商业确认后，向支付服务方发起支付、接受支付核验、获取支付结果并处理相关状态的交互规则，为智能体商业中的支付执行阶段提供统一、可校验、可衔接的支付服务语义。

本域职责范围

本域覆盖以下内容：

• 支付方式绑定及支付工具引用管理；
• 智能体专属子账户及其相关验证能力管理；
• 用户即时支付、用户委托支付和自主化支付；
• 支付请求构造、支付工具引用、授权核验、支付执行和状态回传；
• 支付执行阶段所需的关键对象、状态语义和跨域引用关系。

本域不规范以下内容：

• 商户内部订单履约、库存处理和业务系统实现；
• 底层清算网络报文、资金清算结算处理及通道内部机制；
• 支付服务方内部风控策略实现、路由策略和账户核心系统实现。

本域组件列表与关系

组件总览

支付服务域由五个协议组件构成，它们共同完成从支付工具准备、账户隔离与支付授权，到支付执行与结果状态管理的完整链路。

各组件的功能定位如下。

• PSD-PMT-BND：支付方式绑定。 负责规范委托人向支付服务方完成智能体支付能力开通，并为智能体建立可用支付标记或等价支付工具引用的过程。
• PSD-AGT-SUB：智能体专属子账户管理。 负责规范为特定智能体开立具有资金隔离能力的专属子账户，并管理其配套验证密钥及生命周期的过程。
• PSD-PAY-INS：用户即时支付。 负责规范委托人实时在场场景下，基于购物车确认结果发起即时支付、完成支付确认并接收支付结果的过程。
• PSD-PAY-DEL：用户委托支付。 负责规范委托人不在场场景下，买方智能体基于有效用户意图授权凭证（IAC）和购物车确认结果发起委托支付并接受 PSP 核验的过程。
• PSD-PAY-AUP：自主化支付。 负责规范智能体与卖方服务方之间在完成支付能力对齐后，围绕付费资源或服务的支付请求、支付授权结果凭证传递、支付授权结果凭证验证以及履约交付等开展的支付执行过程。

核心对象与标识

为保持本域内部处理以及与其他域之间引用关系的一致性，支付服务域使用一组标准核心对象和标识来描述支付执行阶段的关键信息。本域核心对象及其作用可概括如下。

对象或标识	含义	主要产生位置	主要使用位置
支付工具引用	支付执行时用于标识付款工具的可用引用对象，可表现为支付标记、子账户标识或其他等价支付工具凭据	PSD-PMT-BND、PSD-AGT-SUB	PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP
购物车确认结果	来自商业交互域的订单级最终确认结果，通常包括交易标的、金额、商户标识、订单交易号及相关确认时间信息	CID-CART-CFM	支付服务域各支付执行组件
支付能力协商结果	来自商业交互域的支付前能力对齐结果，用于确定本次支付所采用的支付方式、支付服务方、接口端点及载荷模式	CID-PCA-NEG	PSD-PAY-DEL、PSD-PAY-AUP，以及必要时的 PSD-PAY-INS
用户意图授权凭证（IAC）	委托授权域签发的意图授权凭证，用于表达委托支付或自主支付的授权边界	ADD-IAC-ISS	PSD-PAY-DEL、PSD-PAY-AUP
delegation_id	委托授权凭证生命周期标识，用于在支付执行、授权核验和后续存证中稳定关联同一次授权链路	ADD-IAC-ISS	PSD-PAY-DEL、PSD-PAY-AUP
支付请求	买方智能体面向支付服务方构造的标准化支付执行请求，承载交易确认信息、支付工具引用、时间戳、请求唯一标识及必要签名材料。	PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP	PSP 或相关支付受理方
支付结果	支付服务方返回的支付执行结果，通常包括交易流水号、关联订单标识、交易状态和交易时间信息	PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP	买方智能体、商户侧以及后续存证处理

依赖与跨域引用

PSD-PMT-BND 和 PSD-AGT-SUB 分别提供两类支付执行所需的支付工具基础：前者提供面向委托人主账户的支付工具引用，后者提供面向特定智能体的资金隔离账户及其验证密钥。

PSD-PAY-INS、PSD-PAY-DEL 和 PSD-PAY-AUP 在支付发起前都需要引用商业交互域形成的购物车确认结果；其中，PSD-PAY-DEL 和 PSD-PAY-AUP 还需要进一步引用委托授权域提供的用户意图授权凭证。

当交易对手为卖方智能体或支付方式需动态协商时，PSD-PAY-DEL 和 PSD-PAY-AUP 还可引用 CID-PCA-NEG 形成的支付能力协商结果，以确定支付方式、支付服务方和接口端点。

在采用智能体专属子账户的场景下，支付授权密文的生成、验证密钥绑定和密钥失效处理，可依赖 ASL 提供的密钥管理与安全执行能力实现。

信任服务域统一维护支付相关事件类型与存证治理规则；支付服务域仅在相关组件中引用事件标识，不在本域重复定义事件结构或治理机制。

PSD-PMT-BND：支付方式绑定

概述

支付方式绑定（Payment Method Binding，PSD-PMT-BND）规定委托人向支付服务方或账户服务方完成智能体支付能力开通，并为智能体建立可用支付工具引用的基本流程和要求。

本组件的目标是使智能体在后续支付执行过程中能够使用经过授权的支付工具完成支付，同时避免原始支付账户信息直接暴露给智能体。

在智能体支付场景中，智能体不应直接持有或接触委托人的原始支付账户信息。可通过支付标记（Payment Token）或其他等价支付工具引用，将真实账户与受托智能体身份标识建立受限绑定，并可进一步配置有效期、金额上限、适用商户范围等限制条件。

参与方与前置条件

本组件涉及以下参与方：委托人、买方智能体，以及提供支付方式绑定服务的支付服务方或账户服务方。在具体实现中，支付标记服务能力可由支付服务方自身提供，也可由独立的支付标记服务方提供。

进入本组件前，应满足以下前置条件。

• 委托人已建立与买方智能体的有效交互关系，并明确希望为该智能体开通支付能力。
• 买方智能体应已具备可被支付服务方或账户服务方识别和绑定的身份标识。
• 支付服务方或账户服务方应具备委托人身份核验、支付工具引用生成、绑定关系管理和有效性校验能力。

基本流程

支付方式绑定宜由委托人主动触发。委托人在智能体平台发起支付开通请求后，平台宜将相关请求引导至支付服务方或账户服务方侧完成身份核验和绑定确认。

第一步是身份核验与意愿确认。支付服务方或账户服务方应对委托人身份及绑定意愿进行核验，核验方式可包括生物识别、支付密码、动态验证码或其他实现方支持的方式。在核验过程中，支付服务方或账户服务方应向委托人明确展示本次绑定的受托智能体身份标识及相关授权范围，确保绑定行为建立在知情确认基础上。

第二步是生成与下发支付工具引用。身份核验通过后，支付服务方或账户服务方生成支付标记，或生成其他等价的支付工具引用，并将其与委托人真实资金账户、受托智能体身份标识以及相关限制条件建立绑定关系。相关限制条件可包括有效期、金额上限及其他实现方定义的使用约束。绑定完成后，支付服务方或账户服务方将支付工具引用下发给买方智能体，供其在后续支付请求中作为付款工具标识使用。

处理要求

本组件形成的支付工具引用（支付标记），应能稳定关联以下信息：委托人的真实资金账户、受托智能体身份标识，以及该引用对象自身的有效状态。

支付服务方或账户服务方在受理后续支付请求时，应能够校验支付工具引用是否有效，以及其与发起支付的买方智能体身份是否保持一致。

若支付工具引用已过期、失效，或与当前智能体身份不匹配，支付服务方或账户服务方不应继续受理相关支付请求。

失败处理

若身份核验、支付工具引用生成或绑定关系建立过程中发生失败，支付服务方或账户服务方应拒绝本次绑定请求，并返回可区分的失败结果。

失败原因的语义宜至少覆盖身份核验失败、智能体身份未注册、账户额度超限以及其他导致支付工具引用无法建立的异常情况。

绑定失败不应产生可继续用于支付的有效支付工具引用。

已建立的绑定关系如发生失效、冻结或注销，也应在后续支付校验中被识别为不可用状态。

PSD-AGT-SUB：智能体专属子账户管理

概述

智能体专属子账户管理（Agent-Dedicated Sub-Account Management，PSD-AGT-SUB）规定为特定智能体开立具有资金隔离能力的专属子账户，以及与之配套的验证密钥绑定和生命周期管理要求。
本组件的目标是为自主性较高的智能体提供账户级风险隔离机制，使委托人主账户不直接暴露于智能体自主执行的支付风险之中。

参与方与前置条件

本组件涉及以下参与方：委托人、买方智能体，以及负责子账户开立、验证和管理的支付服务方。

进入本组件前，应满足以下前置条件。

• 委托人已明确希望为特定智能体建立独立的支付资金边界。
• 买方智能体应已具备可被识别和绑定的稳定身份标识；在专属型智能体场景下，该身份通常与委托人设备、账号或运行环境保持更强绑定关系。
• 支付服务方应具备子账户开立、充值、冻结、解冻、注销和状态查询等基础管理能力。

子账户管理要求

智能体专属子账户宜由委托人主动申请开立。

支付服务方在开立过程中应完成委托人身份核验，并建立子账户、受托智能体身份标识和相关验证密钥之间的绑定关系。

子账户开立后，委托人可按需向其充值或设置可用额度，使智能体在既定余额或额度范围内执行支付。

在后续支付过程中，买方智能体可携带子账户标识以及相应的支付授权密文发起支付，支付服务方则依据绑定关系和账户状态完成验证与处理。

当风控异常触发、委托人主动申请或智能体身份失效时，支付服务方应支持对子账户执行冻结或注销处理。

子账户注销或失效后，其相关验证密钥也应同步失效，不应继续用于后续支付。

专属密钥绑定

子账户宜配套专属验证密钥，以支持对子账户支付授权的有效验证。该验证密钥可采用非对称方案或对称方案；实现方可依据安全要求与部署条件选择适用方式。

子账户开立时，相关密钥或验证材料宜在受保护执行环境中生成，并与子账户标识完成绑定注册，作为后续验证依据。

在后续支付过程中，买方智能体可基于该验证密钥生成支付授权密文，支付服务方据此验证支付请求是否与当前子账户及其绑定智能体一致。

当子账户被冻结或注销时，与其关联的验证密钥也应联动失效；失效后，支付服务方不应继续接受该子账户的支付请求。

对于密钥生成、调用保护和失效处理的底层安全机制，本组件不重复定义具体实现；相关能力可由 ASL协议的安全执行与密钥管理能力提供支撑，对应模块为 ASL-INF-SEE 和 ASL-INF-KMS。

处理要求与失败处理

本组件管理的子账户，至少应能够稳定关联以下信息：子账户标识、受托智能体身份标识、账户当前状态，以及与其关联的验证密钥状态。

实现方可根据业务需要进一步为子账户配置余额上限、单笔额度、累计额度、有效期或适用任务范围等限制条件，以支持更细粒度的风险隔离。

支付服务方应能够识别子账户的基本生命周期状态，至少包括可用、冻结和注销等状态，并据此决定是否接受后续支付请求。

当子账户未开立、余额不足、状态异常、绑定关系不一致或验证密钥无效时，支付服务方应拒绝相关支付或管理操作，并返回可区分的失败结果。

失败原因的语义宜至少覆盖身份核验失败、子账户未开立、子账户已冻结、子账户已注销、余额不足和验证密钥无效等情况。

PSD-PAY-INS：用户即时支付

概述

用户即时支付（Instant Payment，PSD-PAY-INS）适用于委托人实时在场，并对本次购买行为进行即时确认后完成支付的场景。

在该场景下，委托人全程参与购买决策闭环，因此无需预先签发意图授权凭证；委托人在支付服务方收银台完成的即时确认行为，本身即构成本次支付的合法授权依据。

注：当前协议中仅定义了由智能体向支付服务方发起支付请求的模式，后续将扩展支持由商户向支付服务方发起支付请求的模式。

前置条件

本组件涉及以下参与方：委托人、买方智能体、卖方或商户侧系统，以及负责支付受理、校验和资金处理的支付服务方。

进入本组件前，应满足以下前置条件。

• 委托人已向买方智能体表达实时购买意图，且买方智能体已在商业交互域完成规则前置检验与购物车确认流程，获得待支付的商户侧订单信息。
• 买方智能体应已持有在 PSD-PMT-BND 中为本次支付场景建立的有效支付工具引用。
• 支付服务方应能够校验支付工具引用有效性、验证买方智能体身份与请求完整性，并在校验通过后唤起面向委托人的支付收银台或确认界面。

流程步骤

第一步是购物车确认与订单锁定。

买方智能体完成商业交互域的意图搜索与购物车确认流程后，应取得商户侧订单号及购物车信息；商户侧订单号用于连接前端商业意图与后端资金清算处理。

第二步是构造并发送即时支付请求。

买方智能体向支付服务方发起即时支付请求时，请求内容宜至少包含以下核心要素。

• 本次请求的全局唯一标识，用于防重放校验。
• 来自购物车确认环节的商户侧订单号和购物车信息，用于支付内容一致性校验。
• 前期绑定得到的支付工具引用。
• 本次支付金额及币种，且其数值应与购物车信息中的待支付总金额一致。
• 请求时间戳，用于支付服务方执行时效性验证。
• 买方智能体身份标识，以及对本次请求关键要素的签名或等价完整性保护材料。

第三步是支付服务方基础校验。

支付服务方在接收到即时支付请求后，应先完成基础校验，基础校验至少包括请求唯一标识防重放校验、请求时间戳时效性校验、买方智能体签名有效性校验，以及支付工具引用有效性校验。

对于支付工具引用，支付服务方应确认其未过期、未失效，且与发起本次支付请求的买方智能体身份绑定关系一致。

上述任一校验未通过时，支付服务方不应继续进入收银台确认流程，而应直接返回对应失败结果。

第四步是唤起收银台与委托人即时确认。

在基础校验全部通过后，支付服务方应向委托人唤起支付收银台或确认弹窗。

收银台中至少应展示本次支付金额及币种、收款商户名称和支付方式，且展示内容应与即时支付请求中的对应字段保持一致。

委托人通过生物识别、支付密码、动态验证码或其他支付服务方支持的方式完成确认后，支付服务方应记录本次确认所使用的核身方式及确认时间戳，作为本次支付的授权证据。

第五步是支付执行与状态回传。

委托人完成即时确认后，支付服务方应将支付工具引用解析到对应的真实支付账户，并执行资金扣划或额度冻结处理。

支付服务方应将支付结果同步返回买方智能体，返回内容宜至少包括支付服务方交易流水号、商户侧订单号、交易状态和交易时间戳。

支付服务方还应同步将支付结果通知商户侧系统，以支持订单状态更新和后续履约处理。

支付交易完成后，支付服务方宜异步上报 act:payment:transaction-completed 存证事件，以支持后续争议处理和审计追溯。

处理要求

买方智能体在构造即时支付请求时，应确保支付金额、币种和商户侧订单信息与购物车确认结果保持一致，不应擅自修改已确认的交易核心要素。

支付服务方在唤起收银台前，应完成所有基础校验；未通过校验的请求不应进入收银台确认流程。

支付服务方展示给委托人的支付信息，应与请求中相应字段严格一致，以确保委托人是在充分知情的条件下完成确认。

错误响应

即时支付中的错误响应，宜覆盖以下语义类别。

语义类别	说明	重试建议
请求重复	请求唯一标识已被使用，疑似重放攻击。	不应直接重试；应更换请求唯一标识后重新发起。
请求已过期	请求时间戳超出支付服务方接受的有效窗口。	可在重新生成时间戳并确认请求仍有效后重试。
智能体签名无效	买方智能体签名验证失败。	不应直接重试；应先修正签名材料或校验身份绑定关系。
支付工具引用无效	支付工具引用不存在、已失效、已过期或不可用。	不应直接重试；应先重新绑定或更换可用支付工具。
支付工具引用与智能体身份不匹配	当前支付工具引用与发起请求的买方智能体身份绑定关系不一致。	不应直接重试；应先修正绑定关系或更换合法发起方。
金额与购物车不一致	即时支付请求中的金额与购物车确认结果所覆盖金额不一致。	不应直接重试；应先修正请求金额或重新确认购物车。
用户确认失败	委托人在收银台核身失败、取消确认或未在规定时间内完成确认。	可按业务策略决定是否允许用户重新发起确认。
支付执行失败	基础校验与用户确认通过后，资金扣划、额度冻结或通道路由阶段发生失败。	可根据失败原因决定是否允许重试；通道瞬时异常可重试，账户或风控异常通常不宜直接重试。

PSD-PAY-DEL：用户委托支付

概述

用户委托支付（Delegated Payment，PSD-PAY-DEL）适用于委托人不在场情形下，由买方智能体依据委托人预先签发的意图授权凭证，在授权边界内自主完成程序化支付的场景。

与 PSD-PAY-INS 不同，本组件的授权基础不是支付服务方收银台上的委托人实时确认，而是委托人预先签发且在支付时仍然有效的意图授权凭证。

注：当前协议中仅定义了由智能体向支付服务方发起支付请求的模式，后续将扩展支持由商户向支付服务方发起支付请求的模式。

适用场景与前置条件

本组件适用于用户不在场（Human-Not-Present）且购买标的已在初始交互中明确的定向委托支付场景。

在平台型智能体场景中，为防范跨用户越权与身份混淆，支付核验宜同时关注平台智能体身份与具体委托人身份的绑定关系；在专属型智能体场景中，支付核验通常直接锚定专属智能体身份，并可进一步结合专属子账户实现资金隔离。

进入本组件前，应满足以下前置条件。

• 委托人应已完成意图确认并向买方智能体签发有效的意图授权凭证（IAC）；买方智能体也应已在商业交互域完成规则前置检验与购物车确认，获得待支付的商户侧订单信息。
• 在支付工具层面，买方智能体应已持有可用的支付工具引用，或已具备可用的智能体专属子账户及其支付授权密文。
• 对于请求签名保护、身份绑定、授权凭证校验和底层密钥调用机制，本组件不重复定义其安全实现，相关能力可由 ASL 的身份、连接、授权和密钥管理能力提供支撑。

流程步骤

第一步是智能体端规则自检。

买方智能体在构造委托支付请求前，应结合当前持有的 IAC 执行本地预检，至少包括：IAC 处于有效状态、当前时间落在 IAC 授权有效期范围内、本次支付金额不超过单笔金额上限、本次金额与本地缓存的累计扣款确认额之和不超过授权总额上限、目标商户位于允许范围内，以及拟使用支付方式属于允许支付方式列表。

本地预检是买方智能体的前置过滤机制；若预检未通过，买方智能体不应继续发起委托支付请求。本地缓存的累计扣款确认额，应以支付服务方返回的支付成功交易金额计算；首次支付前默认为零。

第二步是构造并发送委托支付请求。

买方智能体向支付服务方发起委托支付请求时，请求内容宜至少包括：请求唯一标识、商户侧订单号、购物车信息、完整的意图授权凭证及其委托标识、本次支付金额与币种、支付工具凭据、请求时间戳，以及买方智能体身份标识和对关键要素的签名。

当未使用专属子账户时，支付工具凭据通常为 PSD-PMT-BND 输出的支付工具引用；当使用专属子账户时，支付工具凭据应为子账户标识及其专属密钥生成的支付授权密文。

签名覆盖范围宜至少包括请求唯一标识、委托标识、商户侧订单号、支付金额、币种和请求时间戳，以保障关键要素不可被篡改。

第三步是支付服务方侧授权核验。

支付服务方接收到委托支付请求后，应按顺序完成防重放校验、买方智能体签名验证、IAC 有效性核验、金融层约束核验，以及必要时的语义层约束核验。其中：

• IAC 有效性核验至少包括：验证 IAC 签名有效、IAC 未过期未吊销未暂停、IAC 中受托智能体标识与请求中买方智能体身份标识一致，以及委托模式属于本协议定义的有效枚举值。
• 金融层约束核验至少包括单笔金额校验、累计额度校验和支付方式匹配校验。
• 语义层约束核验可按实现需要执行，例如核验收款商户是否位于允许商户范围内，或比对购物车信息与用户原始意图是否一致。
• 若使用专属子账户，支付服务方还应对子账户专属密钥生成的支付授权密文进行有效性验证。

任一核验未通过时，支付服务方应拒绝本次请求，并返回相应失败语义。

第四步是支付执行与状态回传。

所有核验通过后，支付服务方应完成资金扣划或额度冻结；在采用专属子账户时，资金应直接从该子账户划扣或冻结。

支付服务方应将支付结果同步返回买方智能体，返回内容宜至少包括支付服务方生成的全局唯一交易流水号、本次支付关联的委托标识、商户侧订单号、交易状态以及交易时间戳。

买方智能体在收到成功响应后，应以支付服务方返回的支付成功交易金额确认额更新本地累计扣款缓存。

支付服务方还应同步将支付结果通知商户侧系统，以支持订单状态更新和后续履约处理。

支付交易完成后，支付服务方宜异步上报 act:payment:transaction-completed 存证事件，以支持后续争议处理和审计追溯。

处理要求

买方智能体在发起委托支付前，应先完成本地预检，不应将明显超出 IAC 授权边界的请求继续发送给支付服务方。

买方智能体构造的委托支付请求，应确保支付金额、支付币种、商户侧订单信息和购物车信息与前序确认结果保持一致。

支付服务方在执行资金处理前，应完成 IAC 有效性核验和约束核验，不应将未通过核验的请求继续进入扣款阶段。

当采用专属子账户模式时，支付服务方除核验 IAC 外，还应校验子账户状态及其支付授权密文是否有效，并确认其与当前买方智能体身份及子账户绑定关系保持一致。

支付服务方对累计额度的判断，应以其自身确认的历史成功交易金额为准，而不应仅依赖买方智能体本地声明。

委托支付的授权效力应严格受限于 IAC 所定义的边界，不应因为支付请求被程序化执行而突破原始授权范围。

错误响应

在PSD-PAY-INS 组件定义的错误响应语义基础上，本节主要扩展定义与使用意图授权凭证（IAC）和额度边界相关的错误响应语义。

语义类别	说明	重试建议
IAC 已过期	意图授权凭证已超过有效期，不可继续作为本次委托支付的授权依据。	不应直接重试；应重新取得有效授权。
IAC 已吊销	意图授权凭证已被吊销，不可继续用于支付。	不应直接重试。
IAC 已暂停	意图授权凭证当前处于暂停状态，不可用于新的支付请求。	通常不应直接重试；应等待恢复或重新授权。
智能体身份不匹配	IAC 中受托智能体标识与请求中的买方智能体身份标识不一致。	不应直接重试；应修正绑定关系或更换合法发起方。
单笔金额超限	本次支付金额超出 IAC 设定的单笔金额上限。	不应直接重试；应调整金额或重新授权。
累计金额超限	本次支付金额与已确认累计金额之和超出 IAC 设定的授权总额上限。	不应直接重试；应调整额度或重新授权。
余额不足	扣款账户或专属子账户余额不足，无法完成本次支付。	可按业务策略决定是否在补足余额后重试。
商户不在范围内	收款商户不在 IAC 允许的商户范围内。	不应直接重试；应更换商户或重新授权。
金额与购物车快照不一致	请求金额与购物车确认结果所覆盖的金额不一致。	不应直接重试；应修正请求或重新确认购物车。

PSD-PAY-AUP：自主化支付

概述

自主化支付（Autonomous Payment，AUP）规定买方智能体在自主委托任务下，围绕付费资源或服务访问所发起的支付交互机制。本组件适用于委托人不在场，且买方智能体依据 BOUNDED 模式意图授权凭证，在授权边界内自主开展多轮商业决策与支付的场景。卖方一侧可以是商户、平台、卖方智能体或其代理接口，在本组件中，统一称为卖方服务方。

本组件采用“基础框架层 + 支付方法层”的双层分离设计，以兼顾通用互操作性与不同支付方法的差异性。基础框架层规定与具体支付方法无关的通用 HTTP 交互骨架、支付授权结果凭证传递机制与履约回执机制。支付方法层由各具体支付方法规范文档独立定义。

参与方与前置条件

本组件涉及买方智能体、卖方服务方、支付服务方 PSP，以及在需要时提供上游授权依据的委托授权域相关能力。其中，买方智能体负责自主决策与支付发起，卖方服务方负责提供资源或服务，PSP 负责支付受理、核验、资金处理与结果返回。

进入本组件前，应满足以下前置条件。

• 委托人已完成自主委托任务确认，并签发有效的 BOUNDED 模式意图授权凭证。
• 买方智能体已完成任务拆解，并获得待访问的资源或服务目标。
• 在需要时，买卖双方可依据 CID-PCA-NEG 完成支付能力协商，明确后续支付所采用的支付方法、支付服务方、目标接口地址及对应的载荷结构说明。
• 买方智能体已具备可用的支付工具；在自主委托场景下，宜结合智能体专属子账户及其配套专属密钥能力完成支付授权。

交互流程

以下流程描述单次自主化支付过程；在一个完整任务执行周期内，该过程可循环发生多次。

步骤一：卖方服务方返回支付诉求。

买方智能体向卖方服务方请求资源或服务时，若该资源或服务需要付费，卖方服务方应返回 HTTP 402 Payment Required 状态码，并通过 Payment-Needed 响应头声明本次支付的核心参数。该响应用于向买方智能体明确本次访问所对应的支付要求、支付时间窗口以及后续请求构造依据。

步骤二：买方智能体执行规则实时自检。

买方智能体在决定是否继续支付前，应结合当前持有的意图授权凭证及本地任务状态执行规则实时自检。自检内容至少包括当前时间是否仍在授权有效期内、累计支付金额与本次金额之和是否超出总额上限、交易对手及服务类别是否满足约束，以及拟使用支付方式是否在授权范围内。

任一条件不满足时，买方智能体不应继续发起支付，并应按预设策略终止本次交易、切换交易对手或通知委托人处理。

步骤三：买方智能体提交支付请求。

若自检通过，买方智能体应依据本组件及相应支付方法规范构造支付请求，并向 PSP 提交处理。

支付请求中应包含本次支付所依据的意图授权凭证、交易标识信息、支付金额、支付工具凭据、请求时间信息，以及买方智能体对关键要素的签名。

若使用智能体专属子账户，请求中还应包含子账户标识及其专属密钥生成的支付授权密文。

步骤四：PSP 核验与资金处理。

PSP 接收到支付请求后，应依次完成防重放校验、买方智能体签名验证、意图授权凭证有效性核验、金额与累计额度边界核验，以及账户状态、余额和风控策略校验。若使用专属子账户，PSP 还应验证子账户专属密钥生成的支付授权密文的有效性，并核验该子账户余额或可用额度状态。

全部核验通过后，PSP 执行资金扣划或额度冻结，并向买方智能体返回支付授权结果凭证。

步骤五：买方智能体携带凭证再次访问资源。

买方智能体获得支付授权结果凭证后，再次请求卖方服务方的资源或服务时，应在请求头中携带 Payment-Proof，其中包含支付授权结果凭证。该请求用于证明指定订单或资源已完成合法支付，并触发卖方服务方进入凭证验证与履约阶段。

步骤六：卖方服务方验证凭证并返回资源。

卖方服务方收到携带支付授权结果凭证的请求后，应向 PSP 发起验证，以核验凭证有效性、防重复性以及其与当前资源访问请求的一致性。验证通过后，卖方服务方通过 Payment-Validation 响应头返回验证结果，并放行付费资源或启动服务履约。

若验证失败，卖方服务方应拒绝付费资源访问，并返回可被买方智能体识别的错误语义。

步骤七：履约与归档。

服务履约、履约回执及归档确认的具体交互机制由相应支付方法规范文档定义。

支付交易完成后，PSP 宜异步上报 act:payment:transaction-completed 存证事件，为后续审计、争议处理和任务账单回溯提供事实依据。

支付方法（method_id）

本组件通过 method_id 标识具体支付方法，并由对应的方法规范文档独立维护相关规则。

每个支付方法对应独立的方法规范文档，用于定义该方法的请求构造方式、扩展字段要求、签名算法、PSP 核验逻辑、支付授权结果凭证返回方式及错误码分配规则。

在进入本组件前，买卖双方可通过 CID-PCA-NEG 协商并确认 method_id、psp_id、endpoint 与 method_schema_url，作为后续支付请求构造与执行的直接输入。

HTTP Header 扩展字段

本组件使用以下三类 HTTP Header 字段。

Header 名称	使用方	使用时机
Payment-Needed	卖方服务方	HTTP 402响应时，用于声明支付诉求及核心参数。
Payment-Proof	买方智能体	买方携带支付授权结果凭证再次请求资源或服务时使用。
Payment-Validation	卖方服务方	卖方在 支付授权结果凭证验证完成后的 结果返回。如验证通过直接返回付费资源或服务；如验证未通过返回错误码。

支付载荷（Payload）结构

自主化支付过程中用于构造、签名、传递和验证的支付载荷，在结构上划分为两个层次：基础载荷字段与支付方法扩展字段。基础载荷字段用于定义各支付方法共享的标准要素集合，以保证不同实现之间的互操作性。支付方法扩展字段用于承载具体支付方法特有的业务参数，但不得改变基础载荷字段的标准语义。

基础载荷字段

字段	类型	说明
method_id	string	支付方法标识符，用于标识本次交易采用的具体支付方法。
out_trade_no	string	外部订单号，用于幂等控制和交易关联。
amount	string	支付金额，宜采用字符串格式以避免浮点精度问题。
currency	string	交易币种，宜采用标准货币代码表示。
resource_id	string	资源标识，用于绑定支付与资源访问，防止凭证挪用。
pay_before	string	支付截止时间，用于限定支付有效时间窗口并降低重放风险。
seller_unique_id	string	卖方服务方唯一标识。
buyer_unique_id	string	买方智能体唯一标识。
payment_proof	string	支付授权结果凭证，用于标识支付授权成功结果。
trade_no	string	交易流水号或交易唯一标识号，由 PSP 生成并用于交易追踪。
expires_at	string	支付授权结果凭证的有效截止时间。
signer_id	string	签名者唯一标识，用于标识生成报文签名的主体。
signature_content	string	签名值，用于保证报文完整性与来源可验证性。
signature_type	string	签名算法类型，用于指示报文签名验证所需的算法标识。

支付方法扩展字段

支付方法扩展字段用于适配具体支付方法的业务场景，可由买卖双方及 PSP 在方法规范允许范围内附加方法特定参数。

这类扩展参数可包括账户标识映射键、商品信息、签名覆盖范围声明或其他方法专属属性。

扩展字段的定义、约束及使用方式，应由对应的支付方法规范文档独立说明。

交易状态

本组件定义下述交易状态，各支付方法内部状态应映射到下列状态后再对外输出。

状态码	状态名	说明	可转入状态
CREATE	创建	初始状态	WAIT_BUYER_PAY
WAIT_BUYER_PAY	等待买家支付	买方尚未完成支付	WAIT_SELLER_FULFILLMENT、TRADE_CLOSED
WAIT_SELLER_FULFILLMENT	等待卖方履约	买方已支付，等待卖方服务方履约	WAIT_BUYER_RECEIPT、TRADE_CLOSED
WAIT_BUYER_RECEIPT	等待买家回执	卖方已履约，等待买方确认	TRADE_FINISHED、TRADE_CLOSED
TRADE_FINISHED	交易完成	终态	无
TRADE_CLOSED	交易关闭	终态，适用于退款或取消后的关闭状态	无

错误响应

错误响应宜覆盖签名校验、请求参数、身份校验、额度与资产、风控、交易状态、支付授权结果凭证验证及系统异常等语义类别。买方智能体和卖方服务方可依据错误语义决定是否重试、切换支付方式、更换交易对手或终止本次交易。

语义类别	说明	重试建议
签名校验错误	签名验证失败，或签名类型不受支持	一般不建议直接重试，应先检查签名材料、签名者标识及算法配置
请求参数错误	参数非法、金额格式错误、时间格式错误，或请求已过期	修正报文后可重试；若已过期，应重新获取支付诉求
协议校验错误	协议不存在、协议无效，或方法规范不匹配	不建议直接重试，应先校验支付方法配置与协议版本
智能体身份校验错误	买方智能体或卖方服务方身份验证失败	不建议直接重试，应先检查身份文档、公钥材料及绑定关系
额度与资产校验错误	额度不足、余额不足，或资产账户校验失败	可在补足余额、调整额度或更换支付工具后重试
限权与风控错误	用户被限权、命中风控策略，或授权边界不满足	一般不建议立即重试，应先等待风控解除或重新取得授权
交易状态错误	交易不存在，或当前交易状态不允许继续处理	不建议直接重试，应先查询交易状态并做幂等处理
退款错误	退款金额超限，或退款处理失败	视失败原因处理；必要时转人工或走后续补偿流程
履约回执错误	履约失败，或履约结果回执异常	可结合幂等策略与履约状态查询结果决定是否重试
支付授权结果凭证验证错误	凭证为空、凭证已过期或不存在、凭证状态无效，或其与当前主体、交易、资源不一致	一般不建议直接重试，应重新获取有效凭证或重新发起支付
系统错误	系统内部异常或下游服务故障	可按指数退避策略有限次重试，超过阈值后转人工或告警