支付服务域
范围
本域定位
支付服务域（Payment Services Domain, PSD）规定智能体在完成支付前商业确认后，向支付服务方发起支付、接受支付核验、获取支付结果并处理相关状态的交互规则，为智能体商业中的支付执行阶段提供统一、可校验、可衔接的支付服务语义。
本域职责范围
本域覆盖以下内容：
- 支付方式绑定及支付工具引用管理；
- 智能体专属子账户及其相关验证能力管理；
- 基于 HTTP 402 的通用支付接入交互（PSD-PAY-A402）；
- 不同在场性与自主度下的三类支付场景：用户即时支付、用户定向委托支付和自主化委托支付；
- 支付请求构造、支付工具引用、授权核验、支付执行和状态回传；
- 支付执行阶段所需的关键对象、状态语义和跨域引用关系。
本域不规范以下内容：
- 商户内部订单履约、库存处理和业务系统实现；
- 底层清算网络报文、资金清算结算处理及通道内部机制；
- 支付服务方内部风控策略实现、路由策略和账户核心系统实现。
本域组件列表与关系
组件总览
支付服务域由六个协议组件构成，分为支付接入方案组件与支付场景组件两类，它们共同完成从支付工具准备、账户隔离与支付授权，到支付执行与结果状态管理的完整链路。
支付场景组件：
- PSD-PMT-BND：支付方式绑定。 负责规范委托人向支付服务方完成智能体支付能力开通，并为智能体建立可用支付标记或等价支付工具引用的过程。
- PSD-AGT-SUB：智能体专属子账户管理。 负责规范为特定智能体开立具有资金隔离能力的专属子账户，并管理其配套验证密钥及生命周期的过程。
- PSD-PAY-INS：用户即时支付。 负责规范委托人实时在场情况下，发起即时支付、完成支付确认并接收支付结果的过程。
- PSD-PAY-DEL：用户定向委托支付。 负责规范委托人不实时在场情况下，买方智能体依据 SPECIFIED 模式 IAC 发起定向委托支付并接受 PSP 核验的过程。
- PSD-PAY-AUP：自主化委托支付。 负责规范委托人不实时在场情况下，买方智能体依据 BOUNDED 模式 IAC 在授权边界内自主开展多轮商业决策与支付的过程。
支付接入方案组件：
- PSD-PAY-A402：基于 HTTP 402 的支付接入。 负责规范买方智能体、卖方服务方与支付服务方之间基于 HTTP 402 状态码的通用支付接入交互，可被各支付场景组件按需引用。
核心对象与标识
为保持本域内部处理以及与其他域之间引用关系的一致性，支付服务域使用一组标准核心对象和标识来描述支付执行阶段的关键信息。本域核心对象及其作用可概括如下。
| 对象或标识 | 含义 | 主要产生位置 | 主要使用位置 |
|---|---|---|---|
| 支付工具引用 | 支付执行时用于标识付款工具的可用引用对象，可表现为支付标记、子账户标识或其他等价支付工具凭据 | PSD-PMT-BND、PSD-AGT-SUB | PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP、PSD-PAY-A402 |
| 商户侧订单号 | 来自商业交互域的订单级确认结果，通过订单号标识本次交易的商品信息、金额等信息 | CID-CART-CFM | 支付服务域各支付执行组件 |
| 支付能力协商结果 | 来自商业交互域的支付前能力对齐结果，用于确定本次支付所采用的支付方式、支付服务方、接口端点及载荷模式 | CID-PCA-NEG | PSD-PAY-A402、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 形成的支付能力协商结果，以确定支付方式、支付服务方和接口端点。
PSD-PAY-A402 作为通用支付接入方案，可被 PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP 按需引用。
在采用智能体专属子账户的场景下，支付授权密文的生成、验证密钥绑定和密钥失效处理，可依赖 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-A402：基于 HTTP 402 的支付流程
概述
本组件定义买方智能体、商户/资源服务方与支付服务方之间基于 HTTP 402 状态码（Payment Required）的通用支付接入交互：买方智能体访问付费资源或服务，卖方服务方在未发现有效付款证明时返回 402 状态码和账单；买方完成符合所在支付场景约束的付款后，携带支付证明再次访问；卖方验证通过后交付资源，并完成履约确认。
本组件可被 PSD-PAY-INS、PSD-PAY-DEL、PSD-PAY-AUP 按需引用。当被引用时，本组件只承载支付接入交互机制，不替代各场景组件中的其他具体要求（如 IAC 约束、累计额度边界、子账户管理等）。
参与方与前置条件
本组件涉及以下参与方：
- 买方智能体：请求卖方资源或服务，解析支付诉求，执行委托人的授权校验，取得并提交支付证明。
- 卖方服务方：提供需付费资源或服务，生成付款账单，验证支付证明，并完成资源交付或服务履约。卖方一侧可以是商户、平台、卖方智能体或其代理接口，在本组件中统一称为卖方服务方。
- 支付服务方（PSP）：根据具体支付方法受理支付、生成支付证明、提供支付证明验证能力，并接收必要的履约确认。
- 委托人：在
PSD-PAY-INS场景中实时确认支付；在PSD-PAY-DEL和PSD-PAY-AUP场景中通过意图授权凭证或子账户等方式预先定义授权边界。 - 商户或资源提供方：可与卖方服务方为同一主体，也可由卖方服务方代其提供资源访问与支付接入能力。
进入本组件前，应满足以下条件：
- 卖方服务方应可稳定识别待收费的资源、服务或订单，并具备生成对应唯一的
resource_id和out_trade_no的能力。 - 买方智能体应具备识别 HTTP 402 状态码、解析 Base64URL 编码 Header、选择支持的
method_id并执行委托人授权规则校验的能力。 - 参与方之间已通过
CID-PCA-NEG或等价机制确定可用支付方式。
交互流程
以下流程描述单次支付接入过程；在一个完整任务执行周期内，该过程可循环发生多次。
步骤一：请求付费资源
买方智能体向卖方服务方发起资源、工具、API、数字内容或服务请求。请求可为 GET、POST 或其他由卖方服务方定义的 HTTP 方法。
买方智能体首次请求时通常不携带 Payment-Proof；若携带，卖方服务方应先验证其格式、有效期、交易绑定关系及是否已被重复履约。
步骤二：返回支付诉求
若当前请求没有可用支付证明，或支付证明未通过验证，卖方服务方应返回 HTTP 402 Payment Required，并在 Payment-Needed Header 中携带经 Base64URL 编码的支付账单。
HTTP/1.1 402 Payment Required
Payment-Needed: <Base64URL 编码的支付账单>
Content-Type: application/json
{
"error": "Payment Needed",
"message": "请先支付 0.01 CNY 以访问资源",
"resource_id": "RES_1739836600000_abc123"
}响应体仅用于调试、日志和人类可读提示；买方智能体用于机器处理的支付信息应以 Payment-Needed Header 为准。
步骤三：买方进行场景校验与支付
买方智能体解析 Payment-Needed 后，应先执行所在场景的前置判断：
- 在
PSD-PAY-INS场景中，应引导委托人进行实时支付确认。 - 在
PSD-PAY-DEL场景中，应校验 SPECIFIED IAC 有效性、金额、累计额度、商户范围和允许支付方式。 - 在
PSD-PAY-AUP场景中，应校验 BOUNDED IAC 有效性、任务范围、累计预算、资源类别和智能体专属子账户状态。
任一条件不满足时，买方智能体不应继续发起支付，并应按预设策略终止本次交易、切换交易对手或通知委托人处理。
校验通过后，买方智能体应依据 method_id 对应的支付方法规范向 PSP 或方法指定端点发起支付，并取得支付授权结果凭证。支付方式、支付工具、资金扣划、IAC 核验及风控策略仍由相应 PSD 场景组件和支付方法组件规定，A402 不重复定义。
步骤四：携带支付证明重试访问
支付成功后，买方智能体应对原资源或服务发起新的请求，并在 Payment-Proof Header 中携带支付证明、PSP 交易流水号和买方会话标识等信息。
GET /market/XXXX/trend HTTP/1.1
Payment-Proof: <Base64URL 编码的支付证明>步骤五：卖方验证支付证明
卖方服务方应解析 Payment-Proof，并依据 method_id 对应方法规范调用 PSP 或受信验证服务，对支付证明进行以下核验：
- 凭证有效性：核验
payment_proof的签名、有效期、吊销状态等，确认凭证本身合法有效。 - 防重放性：核验该凭证是否已被重复履约，防止同一支付证明被多次用于资源访问。
- 一致性：核验凭证中的
trade_no、resource_id等字段与当前资源访问请求的一致性，确认凭证对应的就是本次请求的付费资源。
任一核验未通过时，卖方服务方应拒绝付费资源访问，并返回可被买方智能体识别的错误语义。
步骤六：交付资源与履约确认
验凭通过后，卖方服务方应返回资源内容、启动服务履约或确认订单可继续处理。卖方服务方可在成功响应中通过 Payment-Validation Header 返回机器可读的验证及履约状态。
HTTP/1.1 200 OK
Payment-Validation: <Base64URL 编码的验证结果>
Content-Type: application/json
{
"status": "PAYMENT_VALIDATED",
"trade_no": "2026040900828111317760000001xxxx",
"resource_id": "RES_1739836600000_abc123",
"resource": "XXXXXXXXXXXX"
}卖方服务方在完成资源交付或服务履约后，应按具体支付方法规范向 PSP 发起履约确认。
支付交易完成后，PSP 宜异步上报 act:payment:transaction-completed 存证事件，为后续审计、争议处理和任务账单回溯提供事实依据。
HTTP Header 扩展字段
本组件使用以下三类 HTTP Header 字段。三个 Header 的 Header Value 应采用 Base64URL 编码的 UTF-8 JSON 格式。
| Header 名称 | 使用方 | 使用时机 |
|---|---|---|
Payment-Needed | 卖方服务方 | HTTP 402 响应时，用于声明支付诉求及核心参数。 |
Payment-Proof | 买方智能体 | 买方携带支付授权结果凭证再次请求资源或服务时使用。 |
Payment-Validation | 卖方服务方 | 卖方在支付授权结果凭证验证完成后的结果返回。如验证通过直接返回付费资源或服务；如验证未通过返回错误码。 |
支付方法（method_id）
本组件通过 method_id 标识具体支付方法，并由对应的方法规范文档独立维护相关规则。
每个支付方法对应独立的方法规范文档，用于定义该方法的请求构造方式、扩展字段要求、签名算法、PSP 核验逻辑、支付授权结果凭证返回方式及错误码分配规则。
在进入本组件前，买卖双方可通过 CID-PCA-NEG 协商并确认 method_id、psp_id、endpoint 与 method_schema_url，作为后续支付请求构造与执行的直接输入。
支付载荷（Payload）结构
支付载荷在结构上划分为两个层次：基础载荷字段与支付方法扩展字段。基础载荷字段用于定义各支付方法共享的标准要素集合，以保证不同实现之间的互操作性。支付方法扩展字段用于承载具体支付方法特有的业务参数，但不得改变基础载荷字段的标准语义。
三个 Header 的载荷均采用 Protocol + method 的两层结构（Base64URL 编码前）。
基础载荷字段
| 字段 | 类型 | 说明 |
|---|---|---|
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 在方法规范允许范围内附加方法特定参数。这类扩展参数可包括账户标识映射键、商品信息、签名覆盖范围声明或其他的支付方法专属属性。
扩展字段的定义、约束及使用方式，应由对应的支付方法规范文档独立说明。
Payment-Needed 载荷示例
采用 Protocol + method 的两层结构（Base64URL 编码前）：
{
"protocol": {
"out_trade_no": "ORDER_1739836600000_abc123",
"amount": "0.01",
"currency": "CNY",
"resource_id": "RES_1739836600000_abc123",
"pay_before": "2026-03-25T12:00:00+08:00",
"seller_signature": "YYYYxxxx=",
"seller_sign_type": "RSA2",
"seller_unique_id": "2088xxxxxxxx"
},
"method": {
"seller_name": "测试商家",
"seller_id": "2088xxxxxxxx",
"seller_app_id": "app_123456",
"goods_name": "测试商品",
"seller_unique_id_key": "seller_id",
"service_id": "xxxx_12344"
}
}Payment-Proof 载荷示例
采用 Protocol + method 的两层结构（Base64URL 编码前）：
{
"protocol": {
"payment_proof": "7cf8a6a93c924e13eaa4bf20c3a487f30d1fbdb759a1f229b4091b7d0158xxxx",
"trade_no": "2026040900828111317760000001xxxx"
},
"method": {
"client_session": "xxxxxxxxxxxxxsCiAgICAic2Vzc2lvbklkIjogInh4IiwKICAgICJzaWduYXR1cmUiOiAi5Yqg562+5ZCO57uT5p6c77yM6YCa6L+HY3JlZGVudGlhbElk5Yqg562+YWdlbnRUb2tlbiArIHNlc3Npb25JZCkiCn0="
}
}交易状态
本组件定义下述交易状态，各支付方法内部状态应映射到下列状态后再对外输出。
| 状态码 | 状态名 | 说明 | 可转入状态 |
|---|---|---|---|
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 | 交易关闭 | 终态，适用于退款或取消后的关闭状态 | 无 |
错误响应
错误响应宜覆盖签名校验、请求参数、身份校验、额度与资产、风控、交易状态、支付授权结果凭证验证及系统异常等语义类别。买方智能体和卖方服务方可依据错误语义决定是否重试、切换支付方式、更换交易对手或终止本次交易。
| 语义类别 | 说明 | 重试建议 |
|---|---|---|
| 签名校验错误 | 签名验证失败，或签名类型不受支持 | 一般不建议直接重试，应先检查签名材料、签名者标识及算法配置 |
| 请求参数错误 | 参数非法、金额格式错误、时间格式错误，或请求已过期 | 修正报文后可重试；若已过期，应重新获取支付诉求 |
| 协议校验错误 | 协议不存在、协议无效，或方法规范不匹配 | 不建议直接重试，应先校验支付方法配置与协议版本 |
| 智能体身份校验错误 | 买方智能体或卖方服务方身份验证失败 | 不建议直接重试，应先检查身份文档、公钥材料及绑定关系 |
| 额度与资产校验错误 | 额度不足、余额不足，或资产账户校验失败 | 可在补足余额、调整额度或更换支付工具后重试 |
| 限权与风控错误 | 用户被限权、命中风控策略，或授权边界不满足 | 一般不建议立即重试，应先等待风控解除或重新取得授权 |
| 交易状态错误 | 交易不存在，或当前交易状态不允许继续处理 | 不建议直接重试，应先查询交易状态并做幂等处理 |
| 退款错误 | 退款金额超限，或退款处理失败 | 视失败原因处理；必要时转人工或走后续补偿流程 |
| 履约回执错误 | 履约失败，或履约结果回执异常 | 可结合幂等策略与履约状态查询结果决定是否重试 |
| 支付授权结果凭证验证错误 | 凭证为空、凭证已过期或不存在、凭证状态无效，或其与当前主体、交易、资源不一致 | 一般不建议直接重试，应重新获取有效凭证或重新发起支付 |
| 系统错误 | 系统内部异常或下游服务故障 | 可按指数退避策略有限次重试，超过阈值后转人工或告警 |
PSD-PAY-INS：用户即时支付（L1场景）
概述
用户即时支付（Instant Payment，PSD-PAY-INS）适用于委托人实时在场，并对本次购买行为进行即时确认后完成支付的场景。
在该场景下，委托人全程参与购买决策闭环，因此无需预先签发意图授权凭证；委托人在支付服务方收银台完成的即时确认行为，本身即构成本次支付的合法授权依据。
本组件对应场景中，交易有 AI 参与，最终由人决策和执行，表现为指令驱动、笔笔确认，支付决策权保留在用户手中。资金扣划前，支付服务方应完成用户核身确认（如人脸/指纹/扫码等），智能体角色为”代为下单与发起支付请求”。从支付安全风险防控角度，本组件中所描述的场景又称为L1场景。
注：当前协议中仅定义了由智能体向支付服务方发起支付请求的模式，后续将扩展支持由商户向支付服务方发起支付请求的模式。
前置条件
本组件涉及以下参与方：委托人、买方智能体、卖方或商户侧系统，以及负责支付受理、校验和资金处理的支付服务方。
进入本组件前，应满足以下前置条件。
- 委托人已向买方智能体表达实时购买意图，且买方智能体已在商业交互域完成规则前置检验与购物车确认流程，获得待支付的商户侧订单信息。
- 买方智能体应已持有在
PSD-PMT-BND中为本次支付场景建立的有效支付工具引用。 - 支付服务方应能够校验支付工具引用有效性、验证买方智能体身份与请求完整性，并在校验通过后唤起面向委托人的支付收银台或确认界面。
- 支付交互流程可基于
PSD-PAY-A402流程，也可基于传统的商户平台下单支付流程；接口实现方式可包括 MCP 接口、API 接口等，由参与方依据能力与场景协商确定。
流程步骤
以下流程描述单次即时支付过程。买方智能体与支付服务方应依据所确定的支付交互流程（PSD-PAY-A402或传统商户平台下单支付）及对应接口实现方式（MCP 接口、API 接口等）执行相应交互规则。
步骤一：支付前置准备
买方智能体在与卖方服务方或商户侧系统完成商业交互后，应取得本次支付所必需的交易标识信息，用于连接前端商业意图与后端资金清算处理。具体形式依据所采用的支付交互流程而定：
- 当采用商户平台下单支付流程时，买方智能体应在商业交互域完成规则前置检验与购物车确认流程，并取得商户侧订单号。
- 当采用
PSD-PAY-A402接入流程时，买方智能体可在请求付费资源或服务时，由卖方服务方通过HTTP 402 Payment Required响应及Payment-Needed返回本次支付所对应的订单或资源标识（如out_trade_no、resource_id等）。
步骤二：构造并发送即时支付请求
买方智能体向支付服务方发起即时支付请求时，请求内容宜至少包含以下核心要素。
- 本次请求的全局唯一标识，用于防重放校验。
- 商户侧订单号，用于支付商品信息的一致性校验。
- 前期绑定得到的支付工具引用。
- 本次支付金额及币种。
- 请求时间戳，用于支付服务方执行时效性验证。
- 买方智能体身份标识，以及对本次请求关键要素的签名。
步骤三：支付服务方基础校验
支付服务方在接收到即时支付请求后，应先完成基础校验，基础校验至少包括请求唯一标识防重放校验、请求时间戳时效性校验、买方智能体签名有效性校验，以及支付工具引用有效性校验。
对于支付工具引用，支付服务方应确认其未过期、未失效，且与发起本次支付请求的买方智能体身份绑定关系一致。
上述任一校验未通过时，支付服务方不应继续进入收银台确认流程，而应直接返回对应失败结果。
步骤四：唤起收银台与委托人即时确认
在基础校验全部通过后，支付服务方应向委托人唤起支付收银台或确认弹窗。
收银台中至少应展示本次支付金额及币种、收款商户名称和支付方式，且展示内容应与即时支付请求中的对应字段保持一致。
委托人通过生物识别、支付密码、动态验证码或其他支付服务方支持的方式完成确认后，支付服务方应记录本次确认所使用的核身方式及确认时间戳，作为本次支付的授权证据。
本步骤为 L1 场景的核心特征：资金扣划前，支付服务方应完成用户笔笔核身确认。核身方式（如人脸/指纹/扫码/密码/验证码等）由支付服务方依据风控策略和终端环境决定，本协议不做具体规定。
步骤五：支付执行与状态回传。
委托人完成即时确认后，支付服务方应将支付工具引用解析到对应的真实支付账户，并执行资金扣划或额度冻结处理。
支付服务方应将支付结果同步返回买方智能体，返回内容宜至少包括支付服务方交易流水号、商户侧订单号、交易状态和交易时间戳。
支付服务方宜同步将支付结果通知商户侧系统，以支持订单状态更新和后续履约处理。
支付交易完成后，支付服务方宜异步上报 act:payment:transaction-completed 存证事件，以支持后续争议处理和审计追溯。
注： 支付完成后，买方智能体可依据所采用的支付交互流程访问付费资源或服务并触发履约：
- 当采用
PSD-PAY-A402接入流程时，买方智能体可携带Payment-Proof再次访问付费资源或服务，卖方服务方验证凭证后放行资源或启动履约，具体交互细节由PSD-PAY-A402规范定义。- 当采用商户平台下单支付流程时，资源访问与履约由该流程对应的接口规范定义。
无论采用何种支付交互流程，相关接口均可通过 MCP 接口、API 接口等方式实现。
处理要求
- 买方智能体在构造即时支付请求时，应确保支付金额、币种和商户侧订单信息保持一致，不应擅自修改已确认的交易核心要素。
- 支付服务方在唤起收银台前，应完成所有基础校验；未通过校验的请求不应进入收银台确认流程。
- 支付服务方展示给委托人的支付信息，应与请求中相应字段严格一致，以确保委托人是在充分知情的条件下完成确认。
- 在 L1 场景中，支付服务方应在资金扣划前完成用户核身确认；未完成核身确认的支付请求不应进入资金扣划阶段。核身方式由支付服务方依据风控策略和终端环境决定。
错误响应
即时支付中的错误响应，宜覆盖以下语义类别。
| 语义类别 | 说明 | 重试建议 |
|---|---|---|
| 请求重复 | 请求唯一标识已被使用，疑似重放攻击。 | 不应直接重试；应更换请求唯一标识后重新发起。 |
| 请求已过期 | 请求时间戳超出支付服务方接受的有效窗口。 | 可在重新生成时间戳并确认请求仍有效后重试。 |
| 智能体签名无效 | 买方智能体签名验证失败。 | 不应直接重试；应先修正签名材料或校验身份绑定关系。 |
| 支付工具引用无效 | 支付工具引用不存在、已失效、已过期或不可用。 | 不应直接重试；应先重新绑定或更换可用支付工具。 |
| 支付工具引用与智能体身份不匹配 | 当前支付工具引用与发起请求的买方智能体身份绑定关系不一致。 | 不应直接重试；应先修正绑定关系或更换合法发起方。 |
| 用户确认失败 | 委托人在收银台核身失败、取消确认或未在规定时间内完成确认。 | 可按业务策略决定是否允许用户重新发起确认。 |
| 支付执行失败 | 基础校验与用户确认通过后，资金扣划、额度冻结或通道路由阶段发生失败。 | 可根据失败原因决定是否允许重试；通道瞬时异常可重试，账户或风控异常通常不宜直接重试。 |
PSD-PAY-DEL：用户定向委托支付（L2场景）
概述
用户定向委托支付（Delegated Payment，PSD-PAY-DEL）适用于委托人不在场情形下，由买方智能体依据委托人预先签发的意图授权凭证，在授权边界内自主完成程序化支付的场景。
本组件对应场景中，交易由人先决策、由 AI 负责执行。委托人预先明确购买标的并签发意图授权凭证，买方智能体在授权边界内执行既定支付，无需用户笔笔核身。与 PSD-PAY-INS 不同，本组件的授权基础不是支付服务方收银台上的委托人实时确认，而是委托人预先签发且在支付时仍然有效的意图授权凭证。从支付安全风险防控角度，本组件中所描述的场景又称为L2场景。
注：当前协议中仅定义了由智能体向支付服务方发起支付请求的模式，后续将扩展支持由商户向支付服务方发起支付请求的模式。
适用场景与前置条件
本组件适用于用户不在场（Human-Not-Present）且购买标的已在初始交互中明确的定向委托支付场景。
在平台型智能体场景中，为防范跨用户越权与身份混淆，支付核验应同时关注平台智能体身份与具体委托人身份的绑定关系；在专属型智能体场景中，支付核验通常直接锚定专属智能体身份，并可进一步结合专属子账户实现资金隔离。
从支付交互流程角度，L2 场景通常采用传统商户平台下单支付流程（委托人预先明确购买标的，智能体在商户侧完成下单与支付）；当智能体访问的标的以付费资源或服务形式提供时，也可采用 PSD-PAY-A402 接入流程，由卖方服务方通过 HTTP 402 发起支付诉求。两种支付交互流程均可通过 MCP 接口、API 接口等方式实现。
进入本组件前，应满足以下前置条件。
- 委托人应已完成意图确认并向买方智能体签发有效的意图授权凭证（IAC）；买方智能体已在商业交互域完成规则前置检验与购物车确认，获得待支付的商户侧订单信息。
- 在支付工具层面，买方智能体应已持有可用的支付工具引用，或已具备可用的智能体专属子账户及其支付授权密文。
- 对于请求签名保护、身份绑定、授权凭证校验和底层密钥调用机制，本组件不重复定义其安全实现，相关能力可由 ASL 的身份、连接、授权和密钥管理能力提供支撑。
流程步骤
以下流程描述单次定向委托支付过程。买方智能体与支付服务方应依据所确定的支付交互流程及对应接口实现方式执行相应交互规则。
步骤一：智能体端规则自检
买方智能体在构造委托支付请求前，应结合当前持有的 IAC 执行本地预检，至少包括：IAC 处于有效状态、当前时间落在 IAC 授权有效期范围内、本次支付金额不超过单笔金额上限、本次金额与本地缓存的累计扣款确认额之和不超过授权总额上限、目标商户位于允许范围内，以及拟使用支付方式属于允许支付方式列表。
本地预检是买方智能体的前置过滤机制；若预检未通过，买方智能体不应继续发起委托支付请求。本地缓存的累计扣款确认额，应以支付服务方返回的支付成功交易金额计算；首次支付前默认为零。
步骤二：构造并发送委托支付请求
买方智能体向支付服务方发起委托支付请求时，请求内容宜至少包括：请求唯一标识、商户侧订单号、完整的意图授权凭证及其委托标识、本次支付金额与币种、支付工具凭据、请求时间戳，以及买方智能体身份标识和对关键要素的签名。
当未使用专属子账户时，支付工具凭据通常为 PSD-PMT-BND 输出的支付工具引用；当使用专属子账户时，支付工具凭据应为子账户标识及其专属密钥生成的支付授权密文。
签名覆盖范围宜至少包括请求唯一标识、委托标识、商户侧订单号、支付金额、币种和请求时间戳，以保障关键要素不可被篡改。
步骤三：支付服务方侧授权核验
支付服务方接收到委托支付请求后，应按顺序完成防重放校验、买方智能体签名验证、IAC 有效性核验、金融层约束核验，以及必要时的语义层约束核验。其中：
- IAC 有效性核验至少包括：验证 IAC 签名有效、IAC 未过期未吊销未暂停、IAC 中受托智能体标识与请求中买方智能体身份标识一致，以及委托模式属于本协议定义的有效枚举值。
- 金融层约束核验至少包括单笔金额校验、累计额度校验和支付方式匹配校验。
- 语义层约束核验可按实现需要执行，例如核验收款商户是否位于允许商户范围内，或比对请求要素与用户原始意图是否一致。
- 若使用专属子账户，支付服务方还应对子账户专属密钥生成的支付授权密文进行有效性验证。
任一核验未通过时，支付服务方应拒绝本次请求，并返回相应失败语义。
步骤四：支付执行与状态回传
所有核验通过后，支付服务方应完成资金扣划或额度冻结；在采用专属子账户时，资金应直接从该子账户划扣或冻结。
支付服务方应将支付结果同步返回买方智能体，返回内容宜至少包括支付服务方生成的全局唯一交易流水号、本次支付关联的委托标识、商户侧订单号、交易状态以及交易时间戳。
买方智能体在收到成功响应后，应以支付服务方返回的支付成功交易金额确认额更新本地累计扣款缓存。
支付服务方宜同步将支付结果通知商户侧系统，以支持订单状态更新和后续履约处理。
支付交易完成后，支付服务方宜异步上报 act:payment:transaction-completed 存证事件，以支持后续争议处理和审计追溯。
注：支付完成后，买方智能体可依据所采用的支付交互流程访问付费资源或服务并触发履约：
- 当采用
PSD-PAY-A402接入流程时，买方智能体可携带Payment-Proof再次访问付费资源或服务，卖方服务方验证凭证后放行资源或启动履约，具体交互细节由PSD-PAY-A402规范定义。- 当采用传统商户平台下单支付流程时，资源访问与履约由该流程对应的接口规范定义。
无论采用何种支付交互流程，相关接口均可通过 MCP 接口、API 接口等方式实现。
处理要求
- 买方智能体在发起委托支付前，应先完成本地预检，不应将明显超出 IAC 授权边界的请求继续发送给支付服务方。
- 买方智能体构造的委托支付请求，应确保支付金额、支付币种和商户侧订单号与前序购物车确认结果保持一致。
- 支付服务方在执行资金处理前，应完成 IAC 有效性核验和约束核验，不应将未通过核验的请求继续进入扣款阶段。
- 当采用专属子账户模式时，支付服务方除核验 IAC 外，还应校验子账户状态及其支付授权密文是否有效，并确认其与当前买方智能体身份及子账户绑定关系保持有效。
- 支付服务方对累计额度的判断，应以其自身确认的历史成功交易金额为准，而不应仅依赖买方智能体本地声明。
- 委托支付的授权效力应严格受限于 IAC 所定义的边界，不应因为支付请求被程序化执行而突破原始授权范围。
错误响应
在PSD-PAY-INS 组件定义的错误响应语义基础上，本节主要扩展定义与使用意图授权凭证（IAC）和额度边界相关的错误响应语义。
| 语义类别 | 说明 | 重试建议 |
|---|---|---|
| IAC 已过期 | 意图授权凭证已超过有效期，不可继续作为本次委托支付的授权依据。 | 不应直接重试；应重新取得有效授权。 |
| IAC 已吊销 | 意图授权凭证已被吊销，不可继续用于支付。 | 不应直接重试。 |
| IAC 已暂停 | 意图授权凭证当前处于暂停状态，不可用于新的支付请求。 | 通常不应直接重试；应等待恢复或重新授权。 |
| 智能体身份不匹配 | IAC 中受托智能体标识与请求中的买方智能体身份标识不一致。 | 不应直接重试；应修正绑定关系或更换合法发起方。 |
| 单笔金额超限 | 本次支付金额超出 IAC 设定的单笔金额上限。 | 不应直接重试；应调整金额或重新授权。 |
| 累计金额超限 | 本次支付金额与已确认累计金额之和超出 IAC 设定的授权总额上限。 | 不应直接重试；应调整额度或重新授权。 |
| 余额不足 | 扣款账户或专属子账户余额不足，无法完成本次支付。 | 可按业务策略决定是否在补足余额后重试。 |
| 商户不在范围内 | 收款商户不在 IAC 允许的商户范围内。 | 不应直接重试；应更换商户或重新授权。 |
PSD-PAY-AUP：自主化委托支付（L3场景）
概述
自主化委托支付（Autonomous Delegated Payment，AUP）适用于委托人不在场情形下，由买方智能体依据委托人预先签发的 BOUNDED 模式意图授权凭证，在授权边界内自主开展多轮商业决策与支付的场景。
与 PSD-PAY-DEL 相同，本组件的授权基础不是支付服务方收银台上的委托人实时确认，而是委托人预先签发且在支付时仍然有效的意图授权凭证。区别在于，PSD-PAY-DEL场景的购买标的已在初始交互中明确，买方智能体按照指令执行支付，而本场景的买方智能体在授权边界内自主决定交易对象、交易时点及执行路径，并可在一个任务周期内发起多笔支付。从支付安全风险防控角度，本组件中所描述的场景又称为L3场景。
参与方与前置条件
本组件涉及买方智能体、卖方服务方、支付服务方 PSP，以及在需要时提供上游授权依据的委托授权域相关能力。其中，买方智能体负责自主决策与支付发起，卖方服务方负责提供资源或服务，PSP 负责支付受理、核验、资金处理与结果返回。
在平台型智能体场景中，为防范跨用户越权与身份混淆，支付核验应同时关注平台智能体身份与具体委托人身份的绑定关系；在专属型智能体场景中，支付核验通常直接锚定专属智能体身份，并可进一步结合专属子账户实现资金隔离。
从支付交互流程角度，L3 场景下买方智能体在自主探索付费资源或服务过程中，通常采用 PSD-PAY-A402 接入流程（由卖方服务方通过 HTTP 402 发起支付诉求）；也可采用传统商户平台下单支付流程或其他接入方案。两种支付交互流程均可通过 MCP 接口、API 接口等方式实现。
进入本组件前，应满足以下前置条件。
- 委托人已完成自主委托任务确认，并签发有效的
BOUNDED模式意图授权凭证。 - 买方智能体已完成任务拆解，并获得待访问的资源或服务目标。
- 买方智能体已具备可用的支付工具；在自主委托场景下，宜结合智能体专属子账户及其配套专属密钥能力完成支付授权。
- 在需要时，买卖双方可依据
CID-PCA-NEG完成支付能力协商，明确后续支付所采用的支付方法、支付服务方、目标接口地址及对应的载荷结构说明。 - 对于请求签名保护、身份绑定、授权凭证校验和底层密钥调用机制，本组件不重复定义其安全实现，相关能力可由 ASL 的身份、连接、授权和密钥管理能力提供支撑。
流程步骤
以下流程描述单次自主化委托支付过程；在一个完整任务执行周期内，该过程可循环发生多次。流程中涉及支付接入方案交互的步骤，买方智能体与卖方服务方应依据所采用的支付交互流程（PSD-PAY-A402 或传统商户平台下单支付流程）及对应接口实现方式（MCP 接口、API 接口等）执行相应交互规则。
步骤一：卖方服务方返回支付诉求
买方智能体向卖方服务方请求资源或服务时，若该资源或服务需要付费，卖方服务方应按所采用的支付交互流程返回支付诉求。当采用 PSD-PAY-A402 接入流程时，卖方服务方应返回 HTTP 402 Payment Required 状态码，并通过 Payment-Needed 响应头声明本次支付的核心参数；当采用传统商户平台下单支付流程时，应按对应流程规范返回等价的支付诉求信息。该响应用于向买方智能体明确本次访问所对应的支付要求、支付时间窗口以及后续请求构造依据。
步骤二：买方智能体执行规则实时自检
买方智能体在决定是否继续支付前，应结合当前持有的 BOUNDED 模式意图授权凭证及本地任务状态执行规则实时自检，自检内容至少包括：
- 当前时间是否仍在 IAC 授权有效期内；
- 累计支付金额与本次金额之和是否超出 IAC 授权总额上限；
- 本次支付金额是否超出 IAC 单笔金额上限；
- 交易对手及服务类别是否满足 IAC 约束；
- 拟使用支付方式是否在 IAC 允许的支付方式列表内；
- 拟使用支付工具（含专属子账户）状态是否可用。
本地缓存的累计支付确认额，应以 PSP 返回的支付成功交易金额计算；首次支付前默认为零。
任一条件不满足时，买方智能体不应继续发起支付，并应按预设策略终止本次交易、切换交易对手或通知委托人处理。
步骤三：买方智能体提交支付请求
若自检通过，买方智能体应依据本组件场景约束及所采用接入方案的规范构造支付请求，并向 PSP 提交处理。
支付请求中应包含本次支付所依据的 BOUNDED 模式意图授权凭证及其委托标识、交易标识信息、支付金额与币种、支付工具凭据、请求时间信息，以及买方智能体对关键要素的签名。
当未使用专属子账户时，支付工具凭据通常为 PSD-PMT-BND 输出的支付工具引用；当使用专属子账户时，支付工具凭据应为子账户标识及其专属密钥生成的支付授权密文，与 PSD-PAY-DEL 的支付工具凭据规则一致。
步骤四：PSP 核验
PSP 接收到支付请求后，应依次完成以下核验：
- 防重放校验、买方智能体签名验证；
BOUNDED模式意图授权凭证有效性核验（签名有效、未过期未吊销未暂停、受托智能体标识与请求中买方智能体身份标识一致、委托模式属于有效枚举值）；- 金融层约束核验（单笔金额上限、累计额度上限、支付方式匹配）；
- 语义层约束核验（收款商户是否位于 IAC 允许范围内、请求要素与用户原始意图是否一致）；
- 账户状态、余额和风控策略校验。
若使用专属子账户，PSP 还应验证子账户专属密钥生成的支付授权密文的有效性，并核验该子账户余额或可用额度状态。任一核验未通过时，PSP 应拒绝本次请求，并返回相应失败语义。
步骤五：支付执行与状态回传
全部核验通过后，PSP 应执行资金扣划或额度冻结；在采用专属子账户时，资金应直接从该子账户划扣或冻结。PSP 向买方智能体返回支付授权结果凭证，返回内容宜至少包括支付服务方生成的全局唯一交易流水号、本次支付关联的委托标识、交易状态以及交易时间戳。
买方智能体在收到成功响应后，应以 PSP 返回的支付成功交易金额确认额更新本地累计扣款缓存。PSP 宜同步将支付结果通知商户侧系统，以支持订单状态更新和后续履约处理。
支付交易完成后，PSP 宜异步上报 act:payment:transaction-completed 存证事件，为后续审计、争议处理和任务账单回溯提供事实依据。
注：支付完成后的资源访问、凭证验证与履约交付，依据所采用的支付交互流程执行：
- 当采用
PSD-PAY-A402接入流程时，买方智能体在请求头中携带Payment-Proof再次访问资源；卖方服务方向 PSP 核验凭证有效性、防重复性及与当前资源访问请求的一致性，验证通过后通过Payment-Validation响应头返回验证结果并放行资源或启动履约。具体交互细节由PSD-PAY-A402规范定义。- 当采用传统商户平台下单支付流程时，资源访问、凭证验证与履约交付由该流程对应的接口规范定义。
无论采用何种支付交互流程，相关接口均可通过 MCP 接口、API 接口等方式实现。服务履约、履约回执及归档确认的具体交互机制由所采用接入方案的规范及相应支付方法规范定义。
处理要求
- 买方智能体在发起自主化委托支付前，应先完成本地规则自检，不应将明显超出
BOUNDED模式 IAC 授权边界的请求继续发送给 PSP。 - 买方智能体构造的支付请求，应确保支付金额、支付币种和商户侧订单号与前序商业确认结果保持一致。
- PSP 在执行资金处理前，应完成 IAC 有效性核验和约束核验，不应将未通过核验的请求继续进入扣款阶段。
- 当采用专属子账户模式时，PSP 除核验 IAC 外，还应校验子账户状态及其支付授权密文是否有效，并确认其与当前买方智能体身份及子账户绑定关系保持有效。
- PSP 对累计额度的判断，应以其自身确认的历史成功交易金额为准，而不应仅依赖买方智能体本地声明。
- 自主化委托支付的授权效力应严格受限于
BOUNDED模式 IAC 所定义的边界，不应因为支付请求被程序化执行而突破原始授权范围。
错误响应
在 PSD-PAY-DEL 定义的错误响应语义基础上，本组件的错误响应主要与 BOUNDED 模式 IAC 和自主委托边界相关，可复用 PSD-PAY-DEL 中 IAC 已过期、IAC 已吊销、IAC 已暂停、智能体身份不匹配、单笔金额超限、累计金额超限、余额不足、商户不在范围内等错误语义。接入方案相关的错误响应（如支付授权结果凭证验证错误等）由 PSD-PAY-A402 或对应接入方案规范定义。