Solana Agent 支付：先选 HTTP 付款流程，再选钱包

一家模型推理 API 想先按次收费，之后再提供长时间计量会话。运营方已经使用 Solana 收稳定币。下一步不只是挑钱包 SDK，还要决定 HTTP 客户端与服务端究竟支持哪一种商业交互。

资料边界： 本文于 2026 年 11 月 1 日核对 Solana 官方支付文档，没有购买推理请求、执行钱包签名或进行链上结算。

先看交互，不要只看共同的状态码

Agent 支付概览同时介绍 Solana 上的 MPP 与 x402。虽然都可以从 HTTP 402 开始，但头字段与数据模型不同。服务可以提供多个付款选项，客户端仍需选定一套完整且支持的交互。

HTTP 角色	MPP	x402 V2
付款挑战	WWW-Authenticate: Payment	PAYMENT-REQUIRED
客户端凭证	Authorization: Payment	PAYMENT-SIGNATURE
回执	Payment-Receipt	PAYMENT-RESPONSE

这些名称直接影响运行。代理删除一个必要头字段、客户端使用另一个协议版本，或 Facilitator 不支持选定方案，都可能让流程失败，即使各方都支持 Solana 钱包。

推理服务应先决定：每个请求价格固定，还是按实际用量计算最终费用。然后选择协议实现，并核对所有组件是否支持该模型。仅有一个最大金额字段，不能证明计量结算已经接通。

链结算价值，服务交付资源

单次收费流程概念示意，非在线推理或结算实测。会话模式可能先确认用量，再于后续结算。

付款与某个请求的关联属于服务端责任。即使转账确实到了正确地址，如果已经用于另一项购买，也不能再放行。应持久保存请求标识、付款凭证、交易结果和交付响应之间的关系。

对于可重试的 API 工作，我们建议区分“重新交付”与“再授权一笔费用”。推理已经完成但连接中断时，买方应有明确的结果取回或争议路径。自动发起新付款，可能把一次传输失败变成重复收费。

MPP 区分单次收费与计量会话

Solana MPP 指南介绍了单次 charge，以及基于累计凭证的 session。会话可以把多次使用合并结算，不一定每个事件都单独上链。相关规范仍是持续演进的 Internet-Drafts。

指南还区分两种路径：客户端交出已签交易，由服务端提交；或客户端先广播，再提交交易签名作为凭证。它们的费用承担与重试责任不同。如果产品承诺买方不用准备 SOL，就更需要明确采用哪一种。

计量推理应向用户解释预留金额、已用额度和未用资金的恢复方式，服务也需要在重启后保留已接受的用量状态。如果只是多次离散调用最后结算，统一称为“流式付款”容易造成误解。

x402 需要支付方案匹配，不只是网络匹配

x402 V2 指南区分固定金额的 exact 与 upto，后者需要核对客户端、服务端和 Facilitator 的共同支持。文档也提醒，新 V2 接入不能直接沿用 V1 头字段与网络名称。

Facilitator 是一种验证与提交组件，资源服务也可以自行承担这项职责。应决定谁运行所选路径、服务不可用时怎么办，以及卖方如何独立对账。外包验证，不会免除卖方防止同一凭证重复兑换权益的责任。

交易有效期必须进入重试设计

Solana 的生产指南区分提交与确认，也说明 recent blockhash 过期。重新发送同一笔已签交易，与重新构建一笔交易，是不同动作。仅凭本地超时，不足以决定哪种操作安全。

对于这里的 API，建议至少验收：

• 同一付款凭证用于第二个请求时，不产生新权益。
• 多个服务实例共用付款消耗记录。
• 交易过期后，先核对旧结果，再请求新的替代授权。
• 检查要求的 commitment 级别，而不只是看到签名存在。
• 手续费赞助方验证它准备签署的完整交易。

这些是设计要求，不是本文已经执行的测试。成本上也应分开记录 API 价格、交易费用、适用时的账户相关费用，以及基础设施运营成本。

我们的判断

当团队的资产、钱包和支付客户端已经匹配 Solana 生态时，它是值得评估的结算选择。接入工作仍集中在边界：协议版本、方案支持、签名权限、防重放和履约。先做一条固定价格的沙盒路线，再增加会话或多种支付选项，会更容易定位问题。

相关资料见 Solana 支付目录页、MPP 与 x402。MPP 指 Machine Payments Protocol；MCP 是另一种工具访问协议，不应混用名称。