遇到 HTTP 402 付费接口或代理支付时，用 OKX…

当请求返回 402 Payment Required、需要调用付费 Agent/A2MCP 端点、处理 x402/MPP 支付通道、订阅计费或 a2a 支付链接时，按协议路由完成支付。

适用场景

解决思路

1. 检测到 402 或触发词后，在输出第一张用户可见卡片（Step A3.5 推荐卡或 Step A4 确认卡）之前，输出零用户可见文本：不说“收到 402”“触发 OKX Agent Payments Protocol”“检测到 N 种方案”，不枚举方案/网络/代币/金额，不说“加载技能”，任何语言同理；技能加载工具调用可以执行但不输出周边文字。
2. 每次支付只运行一张确认卡：A3.5 推荐卡（2 个以上候选且用户选 yes）或 A4 确认卡（单一候选，或用户从 A3.5 展开列表选了替代项）；不得以“用户过往偏好”“简化流程”“已确认过一次”为由跳过；不得连续渲染两张相同信息的卡；A3.5.5 选 yes 后直接进入 Step A5。
3. 用户可见术语规则 1：始终称其为 **OKX Agent Payments Protocol** 并加粗，无论用户语言都保留这个英文名词短语。
4. 规则 2：不要向用户叙述内部协议检测（检测到哪个 header、加载哪个 reference、选了哪个 scheme/intent、TEE 还是本地密钥路径）；用户只需看到：付什么、要确认什么、结果。
5. 规则 2 例外：仅在 Step A3.5 展开的 alternatives 列表中，可向用户暴露 exact / aggr_deferred / charge 字面量；不得出现在默认推荐卡、“N 其他方法”摘要行、状态叙述、错误显示、支付后摘要等。
6. 规则 3：外部定义的协议字面量必须逐字节精确：JSON 字段 x402Version、HTTP 头 X-PAYMENT / PAYMENT-SIGNATURE / PAYMENT-REQUIRED / WWW-Authenticate: Payment、参考 URL https://x402.org 必须原样出现；CLI 子命令名（onchainos payment pay / pay-local / charge / session ... / a2a-pay ...）在 CLI 调用和代码中按当前名称引用，但不要对用户说出。
7. 进度叙述也算用户可见，规则 1-3 仍适用：长流程中每条进度行都是面向用户的；不要回显 Step 标签和 reference/scheme 名称；按对照表：不说“检测到 HTTP 402，触发 OKX Agent Payments Protocol”/“检测到 PAYMENT-REQUIRED，加载 exact”，保持静默；不说“CLI 选了 exact，组装 PAYMENT-SIGNATURE 头”/“走 TEE 路径”，说“签名完成，正在重放请求”；不说“检测到 2 种方案：exact (USD₮0)、aggr_deferred (USDG)”/“检查余额过滤候选”，保持静默；不说“进入 session / charge 模式”，说“通道已打开”，描述用户可见效果；不说“按过往偏好，不再确认直接支付”，禁止，无此偏好，每次都必须过确认门。
8. 触发词完整列表：EN 的 402、payment required、x402、x402Version、X-PAYMENT、PAYMENT-REQUIRED、PAYMENT-SIGNATURE、WWW-Authenticate: Payment、permit2、upto、metered billing、open/close/topup/settle channel、voucher、session payment、channelId、channel_id、paymentId、a2a_、create payment link、payment link、payment status；subscribe/subscription/recurring payment/recurring charge/“pay every month”/cancel subscription/upgrade plan/downgrade plan 路由到 period scheme（见 references/subscription.md）；例外：消息含 jobId/subId/ASP/provider/trial/renew/deliver/periodCount/subscription task 时属于 Agent Commerce 订阅任务，路由到 okx-ai；其他语言的等价触发词同理。
9. 例外：来自 agent marketplace 的 AI 服务/ASP 订阅（上下文 ASP/Agent#N/任务/试用期/服务方，且无 402 offer/resource URL/paymentId）属于 okx-ai（onchainos agent my-subscriptions / subscribe-detail），不是 period scheme；仅有“my subscriptions / 我的订阅”且无信号时，先问用户一次，不要假设 period。
10. 任何 close/topup/settle/voucher/refund 靠近 channel_id 或 session 上下文 = MPP 会话中操作 → references/session.md。
11. 预检：每个线程开始时完成 ../okx-agentic-wallet/_shared/preflight.md 中的检查；缺失则读取 _shared/preflight.md。
12. 按信号路由命令与 reference：402 + PAYMENT-REQUIRED (v2) / body x402Version (v1) 且一个或多个 accepts[] scheme（exact / exact+Permit2 / upto / aggr_deferred）→ 主路径 Path A：payment quote <url> → 确认 → payment pay --payment-id --yes；单方案和多方案走同一 quote 流程；即使已 curl 到原始 402，也重新通过 payment quote <url> 进入，绝不手工组装 header，绝不直接跳到 sign-only；兼容路径仅在 quote 不可用时用 payment pay --payload [--selected-index]；成功路径不加载 reference，references/accepts-schemes.md 仅用于支付后按 scheme 读 receipt、Permit2 allowance insufficient 一次性 approve、pay-local、pay --payload 兼容路径或旧版 x402 v1。
13. 402 offer 的 accepts[] 条目 scheme == "period"（又名 permit2_subscription）即循环/订阅计费 → payment subscription subscribe/access/change/cancel/cancel-pending/my-subscriptions/allowance-status，见 references/subscription.md。
14. 402 + WWW-Authenticate: Payment 且 intent="charge" → payment charge --challenge，见 references/charge.md。
15. 402 + WWW-Authenticate: Payment 且 intent="session"（或会话中 channel_id）→ payment session open/voucher/topup/close，见 references/session.md。
16. paymentId / a2a_… 链接 / 创建或检查支付链接 → payment a2a-pay create/pay/status，见 references/a2a_charge.md。
17. A2MCP / 402 端点 URL、“pay this endpoint”、入口 A/B 支付节点 → payment quote <url> [--param k=v ...] [--method GET | POST | ...]（内联 Path A）。
18. A2MCP MCP 传输端点（URL 以 /mcp 或 /sse 结尾、返回 text/event-stream / JSON-RPC，或有工具名）→ payment quote <url>（发现 → mcpTools[]）→ payment quote <url> --tool <name> --param k=v（触发 402）→ payment pay --payment-id <id> --yes，见 references/a2mcp-mcp.md。
19. 用户确认了报价支付（已选币种/金额/方案）→ payment pay --payment-id <id> [--selected-index <n>] --yes（内联 Path A）。
20. 需要解码 PAYMENT-RESPONSE 头或 charge receipt → payment decode-receipt (--header <b64> | --receipt <json>)（内联，只读）。
21. 成功路径不要加载 reference：主 Path A 流程中 onchainos payment pay --payment-id --yes 直接签名、重放并返回结算 receipt，完全跳过 references/accepts-schemes.md（单 accepts[] scheme 与多方案同理）；兼容 pay --payload 路径 CLI 返回 authorization_header 由你自己重放，同样成功不加载 reference；仅在失败/旧版路径加载 references/accepts-schemes.md：Permit2 allowance insufficient → 一次性 approve，或旧版 x402 v1 原始 proof → 其“Legacy: x402 v1”章节；charge / session / a2a_charge 总是加载，因为是多阶段流程。
22. 会话中通道操作（close/topup/settle/voucher/refund 与活跃 channel_id 一起出现，无论是否有新 402）→ 留在本技能，直接跳到 references/session.md 对应阶段；不要寻找单独的 close-channel / topup-channel / settle-channel 工具，它们都是 onchainos payment session ... 子命令。
23. Path A（accepts 型）quote → confirm → pay 两轮流程：Step A1 从用户提示（入口 A）或任务支付节点（入口 B）提取端点 url 和已知业务参数，不要自己 curl、解码或转换；Step A2 运行 onchainos payment quote <url> [--param key=value ...] [--method GET|POST|...]，CLI 探测端点、解析 402、检查钱包余额、排序候选并写入 paymentId。
24. 探测方法：CLI 默认用 GET 探测；当服务声明或用户意图表明端点初始调用不是 GET（如 Bazaar outputSchema.method / 业务思维导图声明 "POST"，或用户说“POST this endpoint”）时传 --method POST（或正确动词），已知业务参数放在 JSON body 而非 query string；用默认 GET 探测仅 POST 的 A2MCP 端点可能返回 405/非 402 响应 → endpoint_unreachable 而非支付挑战；付费重放仍按 outputSchema.method 执行，此 flag 只修复初始探测。
25. MCP 传输 A2MCP（tools/call 门控）：若 payment quote 返回 data.mcpTools[]（端点为 MCP 型：URL 以 /mcp|/sse 结尾，或回复 text/event-stream / JSON-RPC），付费墙在工具调用层而非裸 URL；读 references/a2mcp-mcp.md 并遵循：按用户意图从 mcpTools[] 选工具（不明确时用 AskUserQuestion），从工具 inputSchema 组装 --param key=value，重新运行 payment quote <url> --tool <name> --param … 触发 402 并得到 paymentId；然后恢复 Step A3 确认 → Step A4 payment pay --payment-id <id> --yes；不要手写 JSON-RPC 或解析 SSE，CLI 内部完成 initialize → tools/list → tools/call 握手和 SSE 解析。
26. 读取 quote 返回的 data：summary 是人类可读一行，needsConfirm 恒为 true；candidates[]（含 recommended:true）和 alternatives[] 是排序后的方案，每个带 acceptsIndex（其在 accepts[] 中的位置，排序顺序不同于 accepts[]，绝不要把候选列表位置当作索引）；每个候选还带 balanceStatus（sufficient/insufficient/unavailable）、availableAmount、requiredAmount、shortfall；用户选择方法前只显示状态和（不足时）shortfall，不要显示 depositAddress、生成二维码或发送资金通知；missingParams[] + merchantBody 是 CLI 无法填充的参数，其余在 merchantBody 找；walletError 若为 login_required 则让用户登录后重新 quote；所有候选 recommended:null 表示各处余额都不足，展示列表并询问。
27. Step A3 确认（第 2 轮）强制不可跳过：确认完整支付条款（与 Step A4 相同集合），让买家在签名前始终看到资金去向；对 sufficient 候选用 AskUserQuestion；insufficient 候选的资金卡替代它作为唯一确认面：网络 chainName (chainId)、代币/金额 amountHuman tokenSymbol（upto 方案这是授权上限，渲染为“最多 amountHuman”而非固定扣款）、方案 scheme、收款方 challenge recipient (payTo 地址)、任何 missingParams。
28. 若所选候选 insufficient，使用一张资金优先卡：运行 onchainos agent funding-notice --chain <chainName> --currency <tokenSymbol> --available <availableAmount> --required <requiredAmount> --shortfall <shortfall> --deposit-address <depositAddress> --deposit-chain <chainName> --reason payment-402 --format json；本地化 contentCanonical，保留余额、地址、四个资金选项和一行 gas 说明：X Layer = 平台代付 gas，无需 OKB 或其他原生代币；其他链 = 通用 gas 警告；按 displayMode 执行：image-notify → 调用 user-notify --image-path 一次；terminal-unicode → 包含 terminalQr；二维码失败 → 完整文本 + 地址。
29. 提供 funded、cancel，以及仅在可用时提供 choose another payment method；绝不宣传 pay anyway 或询问通用 yes/no；路由：funded → 重新 quote；alternative → 从 candidates[] + alternatives[] 展示其他 sufficient 条目（过期先重新 quote），然后用 acceptsIndex 确认一次；cancel → 停止；用户主动、明确要求尽管不足仍支付即为该单次授权，含糊的 yes 不算；不要运行 funding-check 或添加硬性余额门。
30. 将所选候选的 acceptsIndex 作为 --selected-index 传入（不是其在 candidates[]/alternatives[] 中的位置），让 CLI 精确签署用户批准的条目；必须在支付前停下确认，不要自动支付。
31. Step A4 支付：运行 onchainos payment pay --payment-id <id> --selected-index <n> --yes [--param key=value ...]；--yes 必需（资金移动确认门）；pay 签署报价 payload、重放并返回 receipt，绝不重新获取 402；读取 data.status：success → 报告 txHash，（入口 B）任务系统标记节点已支付；failed → 展示 data.error，提供重试；pending → 轮询/等待终态后继续。
32. 随时解码返回的 PAYMENT-RESPONSE 头或 charge receipt：运行 onchainos payment decode-receipt (--header <b64> | --receipt <json>)。
33. Step A1 旧版/WWW-Authenticate 细节：你已有原始 HTTP 响应；若不是 402，直接返回 body；否则进入 Step A2；捕获用户提示提供的请求参数（如“weather in San Francisco” → city=San Francisco、token=0x…；“translate to Chinese” → lang=zh），记录为 name → value 供 Step A3-Params 计划使用，此处给出的值绝不重新询问，只在确认卡展示；即使首次请求不需要也保留，卖家可能在付费重放时要求。
34. Step A2 检测协议：优先级 1 response.headers['WWW-Authenticate'] 以 "Payment " 开头 → 进入 Step A3-WWW-Authenticate；优先级 2 response.headers['PAYMENT-REQUIRED'] base64 编码 JSON → 进入 Step A3-Accepts (v2)；优先级 3 response body JSON 有 "x402Version" → 进入 Step A3-Accepts (v1)；否则不是支持的支付协议，停止。
35. 两个指示器同时存在时按 WWW-Authenticate intent 分支：intent="session" 与 accepts 型选项同时提供 → 停下询问用户选择会话（多请求，开通道并按请求发 voucher）还是一次性购买；选 1 → Step A3-WWW-Authenticate 会话路径；选 2 → 丢弃 session intent，用 accepts 选项进入 Step A3-Accepts；intent="charge" 与 accepts 型选项同时提供 → 所有选项都是一次性，不显示 session-vs-one-shot 提示，解码两个协议族（Step A3-Accepts 和 Step A3-WWW-Authenticate），合并候选，让 Step A3.5 处理推荐。
36. Step A3-Accepts 解码：仅为展示和推荐自行解码 402 payload，不做 CLI 往返：raw_402 = response.headers['PAYMENT-REQUIRED']（v2，base64 编码 JSON）或 response.body（v1，已是纯 JSON）；decoded = JSON.parse(atob(raw_402))（v2；v1 已是 JSON：JSON.parse(response.body)）；提取 accepts = decoded.accepts、option = decoded.accepts[0]（仅展示）；逐字保留 raw_402，Step A6 直接传给 onchainos payment pay --payload（CLI 重新解码并签名）；本地解码仅用于展示，绝不重新编码或组装。
37. Step A3-WWW-Authenticate 解码：解析 WWW-Authenticate 头 Payment id="...", realm="...", method="evm", intent="...", request="<base64url>", expires="..."；base64url 解码 request 得到 JSON body；保存 intent（charge|session）、amount（基本单位字符串）、currency（ERC-20 合约地址）、recipient（商户收款地址）、methodDetails（chainId EVM 链 ID；escrowContract 会话必需、charge 缺失；feePayer true 交易模式/false 哈希模式；splits 可选仅 charge 最多 10 项；minVoucherDelta 可选仅 session；channelId 可选仅 session topUp/voucher 已有通道）、suggestedDeposit（可选仅 session）、unitType（可选 request|second|byte 等）。
38. 方法检查：仅支持 method="evm"；若为 "tempo"、"svm"、"stripe" 等 → 停止并告知用户此 dispatcher 无法处理。
39. 挑战过期：若 expires=...（ISO-8601）已过期，挑战失效：重新发送原始请求获取新 402 再签名；过期挑战会以 30001 incorrect params 失败；将 amount 从基本单位转换为人类可读（见 _shared/amount-display.md）。
40. Step A3-Params 构建请求参数计划（在 Step A3 解码后、任何确认卡之前）：除支付条款外，卖家可能声明付费重放必须携带哪些参数及方式；构建 param plan 让用户随支付一起确认参数，重放时正确附加；param plan 是 { name, value, carrier, required, source } 列表，carrier ∈ {query, body, header, path}；无卖家声明参数且用户未命名 → 空计划，重放不变。
41. 来源 1 Bazaar outputSchema.input（优先）：若解码的 402（或任何 accepts[i]）带 outputSchema.input，解析：input.type "http" → 在此处理，"mcp" → 超出范围跳过参数组装；input.method 重放方法（可能不同于原始），GET/HEAD/DELETE → 参数放 query，POST/PUT/PATCH → 放 body（input.bodyType: json/form-data/text）；input.queryParams / input.body / input.pathParams / input.headers 对应载体参数；JSON Schema properties + required 给出每个参数类型和是否必需；每个声明参数一条计划条目。
42. 来源 2 非 Bazaar（保守）：无 outputSchema.input → 仅在明确卖家信号时添加参数，绝不臆造：响应 body 列出要求（required/params/parameters/fields/inputSchema），或错误消息指出缺失参数（如 missing required query param "city"），或文档化响应头要求；含糊 → 不添加，重放不变。
43. 填充值：每条目解析 value：(1) 用户提示（Step A1）→ source=prompt，不重新询问；(2) 对话上下文 → source=context；(3) 仍缺失且必需 → 询问用户，所有缺失项合并为一个分组问题（合法门，不算叙述，ZERO-TEXT-ON-TRIGGER 不禁止）；可选且未解析 → 丢弃。
44. Step A3.5 多方案推荐（适用时）：仅当合并候选池包含 2 个或以上 {exact, aggr_deferred, charge, period} 时适用；否则直接跳到 Step A4 用单一可用候选；当 402 accepts[] 含 2 个或以上 {exact, aggr_deferred, charge, period} 时加载 references/multi-scheme.md；将 period 视为循环计费选项，仅当用户意图是持续订阅而非单次调用时推荐；适用时加载 references/multi-scheme.md 并端到端遵循，它返回所选候选并告知恢复位置：Step A4（用户选了替代项）或直接 Step A6（用户以 yes 接受，A5 钱包检查已满足）。
45. Step A4 展示支付详情并停止：若用户在 A3.5.5 以 yes 接受推荐则完全跳过（卡片已显示网络/代币/金额/收款方），直接 Step A5（若 A3.5.2 已处理登录则无操作）→ A6；正常运行条件：Step A3.5 未运行（单候选路径），或用户从 A3.5 展开列表选了替代项（所选候选仍需完整详情确认）；运行时强制：展示详情并停止等待用户明确确认；用户确认前不要调用 onchainos wallet status 或任何其他工具；对 quote 流程候选也显示 balanceStatus，不足时显示 availableAmount、requiredAmount、shortfall，然后遵循 Step A3 的单一资金优先卡和动作表。
46. accepts 型 402 展示模板：此资源需通过 **OKX Agent Payments Protocol** 支付：网络 <chain name> (<option.network>)；代币 <token symbol> (<option.asset>)；金额 <human-readable amount>（v2 来自 option.amount，v1 来自 option.maxAmountRequired，按代币精度从最小单位转换；upto 方案此金额是授权上限而非固定扣款，渲染为“最多 <amount>”）；收款方 <option.payTo>；请求参数（若 Step A3-Params 计划为空则整行省略）：每参数一行 <name> = <value> → <carrier: query | body | header | path>；是否继续支付？(yes / no)。
47. WWW-Authenticate: Payment 402 展示模板：此资源需通过 **OKX Agent Payments Protocol** 支付：支付类型 <one-shot payment | session (multiple requests)>（渲染为“一次性支付”/“会话（多请求）”，绝不用“single purchase”，翻译到其他语言也保持此区分）；网络 <chain name> (eip155:<chainId>)；代币 <symbol> (<currency address>)；每请求金额 <human-readable>（原子：<amount>）；收款方 <recipient>；谁付 gas <server (transaction mode) | you broadcast it yourself (hash mode)>；分账收款方（仅一次性，若存在）<N other parties also receive a share>；建议预付余额（仅会话，若存在）<human-readable>；请求参数（若 Step A3-Params 计划为空则整行省略）：每参数一行 <name> = <value> → <carrier: query | body | header | path>；是否继续支付？(yes / no)。
48. 用户确认 → Step A5；用户拒绝 → 停止，不支付，不检查钱包。
49. Step A5 仅在用户明确确认后检查钱包状态：运行 onchainos wallet status；已登录 → Step A6；未登录（accepts 型路径）→ 让用户选择 (1) 钱包登录（TEE 签名）或 (2) 本地私钥（onchainos payment pay-local，支持 exact + EIP-3009、exact + Permit2 和 upto，不支持 aggr_deferred，需要 TEE 会话密钥）；用户选择前不要读文件或检查环境变量；未登录（WWW-Authenticate: Payment 路径）→ 让用户通过 onchainos wallet login 登录；此路径仅 TEE，无本地密钥回退（仅 accepts 型路径有）。
50. Step A6 交给 scheme/intent reference：accepts 型（PAYMENT-REQUIRED v2 / x402Version v1）主路径应已在 payment quote <url> → 确认 → payment pay --payment-id --yes 流程（Path A 顶部），它签名、重放并返回 receipt，无手工组装，成功不加载 reference，单 accepts[] scheme 与多方案相同；兼容/回退仅在 quote 不可用或明确旧版请求时：运行 onchainos payment pay --payload '<raw_402 from Step A3>'；若 Step A3.5 运行且用户选了 accepts 型候选，加 --selected-index <index in decoded.accepts> 让 CLI 精确签署该条目；单候选省略（CLI 自动选择）；CLI 解码、从所选账户签名并返回 {authorization_header, header_name, scheme, wallet}，无手工组装，然后进入 Replay；若用户选本地密钥回退，运行 onchainos payment pay-local --payload '<raw_402>'（同样成功规则，支持 exact + EIP-3009、exact + Permit2 和 upto，aggr_deferred 仅 TEE）；Permit2 allowance insufficient 错误（upto / exact+permit2，该代币首次支付）→ 加载 references/accepts-schemes.md 做一次性 approve，然后重试 pay；旧版 v1 CLI 返回原始 proof（signature+authorization，无 authorization_header）→ 加载 references/accepts-schemes.md 并遵循其“Legacy: x402 v1”章节组装 X-PAYMENT 头。
51. period（订阅 / permit2_subscription）→ 在 references/subscription.md 的“Decide operation”加载（subscribe vs access vs change vs cancel）；首次 offer → payment subscription subscribe；已激活资源 → payment subscription access（绝不重新订阅）；升级/降级 → change；拆除 → cancel / cancel-pending。
52. WWW-Authenticate: Payment intent="charge" → 在 references/charge.md 的“Decide mode”加载。
53. WWW-Authenticate: Payment intent="session" → 在 references/session.md 的“Phase S1: Open Channel”加载（若用户会话中已有活跃 channel_id 则跳到 S2 / S2b / S3）。
54. Replay（成功路径，无需 reference）：用返回的头重发原始请求（<header_name>: <authorization_header>，或旧版 v1 组装的 X-PAYMENT），期望 HTTP 200，本地解码任何 PAYMENT-RESPONSE 头（echo '<value>' | base64 -d | jq .）读取 status / transaction / amount / payer；向用户展示结算详情；以对话方式建议后续，绝不暴露内部字段名或技能 ID。
55. Path B a2a-pay（基于 paymentId，无 402）：用户明确调用此路径——提到 paymentId / a2a_... 链接、要求“创建支付链接”或查询 a2a 支付状态；Step B1 识别角色：用户说“create payment link”/“generate payment”/--amount/--recipient → 加载 references/a2a_charge.md → “Seller — Create”，角色 Seller；提供 paymentId / a2a_... 要支付 → “Buyer — Pay”，角色 Buyer；提供 paymentId 并询问状态 → “Status — Query”，角色 Either；若用户只说“I want to pay”而无 paymentId → 停下让用户提供卖家签发的 paymentId，不要尝试其他。
56. Step B2 钱包状态：create 和 pay 都需要活跃钱包会话；运行 onchainos wallet status：已登录 → 继续（加载 reference 并遵循）；未登录 → 让用户通过 onchainos wallet login 登录；没有活跃会话不要签名。
57. Step B3 交给 references/a2a_charge.md：该 reference 有完整 create/pay/status 流程（含自动轮询和信任委托说明）；买方侧信任委托给上游——买方签署服务端挑战声明的任何内容。
58. 读取卖家错误（WWW-Authenticate: Payment / a2a-pay）：卖家拒绝时不要显示原始 JSON 或仅数字代码；按优先级提取人类可读解释，用第一个非空匹配：1 body.reason（mppx, OKX TS Session）；2 body.detail（RFC 9457 ProblemDetails）；3 body.message；4 body.msg（OKX SA API）；5 body.error；6 body.title（RFC 9457 短标题，仅回退）；7 兜底——格式化整个 body 并加 HTTP 状态；格式：卖家拒绝：<reason text>（代码 <code if present>，HTTP <status>）。
59. 金额展示：所有用户可见金额同时用人类和原子形式：<human> (<atomic>)，如 0.0004 USDC (400)；精度表和未知符号回退见 _shared/amount-display.md。
60. 建议后续步骤：支付并响应成功后以对话方式建议：payment quote 返回 needsConfirm:true → 确认一次：sufficient 时用 AskUserQuestion，insufficient 时用自适应二维码增强确认（image-notify PNG / terminal-unicode），然后 payment pay --payment-id <id> --selected-index <n> --yes；payment quote 返回 data.mcpTools[]（MCP 传输，无 paymentId）→ 按用户意图选工具，然后 payment quote <url> --tool <name> --param k=v … 触发 402（见 references/a2mcp-mcp.md）；payment pay 返回 status:"success" → 报告 txHash，若有 PAYMENT-RESPONSE 头则 payment decode-receipt --header <b64>；payment pay 返回 status:"pending" → payment a2a-pay status --payment-id <id> --wait（a2a）或等待 facilitator 回调；成功 HTTP 402 重放 → 通过 okx-agentic-wallet 检查余额影响，或对同一资源再发请求；成功 a2a 支付 → 通过 okx-agentic-wallet 验证支付后余额；重放时 402（过期）→ 用新签名重试；通道会话进行中 → 下一请求到达时再发 voucher，完成后关闭通道。

适用边界 · 注意事项

• 不适用于非 402 且非 a2a-pay 的普通 HTTP 响应：若响应不是 402，直接返回 body，不进入支付流程。
• 不适用于 method 非 "evm" 的 WWW-Authenticate 挑战（如 tempo、svm、stripe）：dispatcher 无法处理，应停止并告知用户。
• 不适用于来自 agent marketplace 的 AI 服务/ASP 订阅（上下文 ASP / Agent#N / 任务 / 试用期 / 服务方，且无 402 offer / resource URL / paymentId）：属于 okx-ai，不是 period scheme。