x402 和 MPP 让软件能够为 Web 服务支付费用，但客户端需要支持所选的协议和支付方式。在选择之前，请对比计费工作流、支持的实现方式和恢复路径。
固定价格的查询和计量的浏览器会话需要不同的会计处理。无论是协议名称还是稳定币选项，都无法告诉你你的商户技术栈是否同时支持两者。
支付请求出现的场景
x402 使用 HTTP 402 响应来传达资源的支付要求。兼容的客户端提供支付负载，卖家在选定的方案下进行验证和结算。V2 为该交换指定了与支付相关的标头。x402 HTTP 流。
MPP 也定义了 HTTP 支付挑战和客户端响应，并提供记录成功支付的收据。其设计将请求的支付意图与用于完成支付的支付方式分离。机器支付协议 (Machine Payments Protocol)。
这些共同目标并不建立协议传输层面的兼容性。客户端和服务器必须支持相同的协议、版本和方法。宣传支持两者的服务需要正确实现两者，而不是假设一个标头可以重命名为另一个。
智能体框架可以支持多个支付客户端。这是产品集成的选择，涉及测试和维护成本。智能体仍需要策略来决定它可以接受哪些报价。
在选择协议前选择计费路径
单次付费请求和持续的计量计费会话需要不同的授权和会计处理。
协议与处理器有所不同
协议描述参与者如何进行通信。商户集成提供了一种验证支付、转移资金并记录交易的可行方式。商业费用、客户资格和运营支持可能取决于该集成。
Stripe 与 Tempo 共同编写了 MPP，并通过其 PaymentIntents API 描述了一种集成方式。其公告包括稳定币和法定货币支付选项，并使用共享支付令牌（Shared Payment Tokens）用于支持的传统支付方法。Stripe MPP 公告。
x402 同样支持不同的促进者路径。商户可以使用托管服务、运行自己的促进者或在其服务器内执行结算功能。支持的方案和网络取决于所选组件。x402 促进者路径。
这在比较费用时非常重要。一个规范可以是开放的，而便捷的托管路径可能会收取运营服务的费用。“免 Gas”的买家体验可能涉及另一方支付网络成本。完整的报价应识别这些相关方。
会话改变了计费问题
会话允许服务在一系列交互中维持商业关系。这适用于流式输出、租赁基础设施或重复使用工具。客户需要支出上限、停止使用的手段以及累计费用的记录。
MPP 在其记录的方法生态系统中提供面向会话的支付路径。这不应被泛化到支持每个会话功能的每个商户实现中。方法支持需要在客户端和服务器端进行检查。MPP 会话文档。
x402 不仅限于每次 HTTP 调用的一个固定费用。其当前的方案集包括精确（exact）、最高（up-to）、批量结算（batch settlement）和授权捕获（auth-capture）。仅将聚合归因于 MPP 的比较忽略了当前 x402 设计的一部分。x402 支付方案。
实际问题是您的服务如何计量。为一项数据定义收费很容易。为开放式的研究会话收费则需要针对取消的调用、未使用的预算和变动成本操作制定规则。
比较客户的完整购买
| 问题 | x402 路径 | MPP 路径 |
|---|---|---|
| 服务器如何请求付款？ | 带有方案和支付要求的 HTTP 402 | 带有意图和方法信息的 HTTP 支付挑战 |
| 您应该检查哪些计费模式？ | 支持精确、最高、批量结算和授权捕获 | 一次性费用和特定于方法的会话 |
| 谁执行支付操作？ | 选定的促进者或服务端实现 | 选定的支付方式和服务集成 |
| 买方必须使用特定的链吗？ | 取决于接受的方案/网络对 | 取决于所选方法，而非仅取决于 MPP 名称 |
| 哪些需要额外的产品工作？ | 预算策略、交付、发现和收据 | 预算策略、交付、发现和收据 |
该表格描述了截至 2026 年 10 月 13 日的设计问题。它并不保证每个 SDK 或处理器都支持每个选项。集成审查应确定实际版本和支持的路由。
对于固定价格的天气查询，两条路由都需要一个明确的报价和一次可恢复的购买。对于按分钟租用的浏览器，提前取消会话并检查最终费用和未使用的授权。该测试旨在揭示集成是否支持客户预期的计费行为。
MPP 还记录了现有 x402 服务的适配器。这些适配器可以在保留底层协议区别的同时减少集成工作；它们并不会使每个客户端自动与每种方法兼容。在 x402 中使用 MPP。
失败案例决定工作量
考虑一个在网络超时前刚刚被接受的支付授权。买方不知道卖家是否完成了请求。使用新支付进行重试可能会导致重复收费；在信息不足的情况下重试可能会导致任务处于未解决状态。
集成需要稳定的购买身份和对账路径。协议收据可以帮助描述支付结果，但资源服务仍需将其与交付的工作相关联。x402 支付标识符。
对于一个会话，包含一个停滞的客户端和一个继续计费的卖家。在智能体失去连接后，支出边界应保持可强制执行。如果智能体已崩溃，“智能体将关闭会话”是一种较弱的保护措施。
这些是正常的商业操作，而非奇特的攻击。测试这些操作比在纯净的演示中计算成功的请求更能提供更好的就绪状态证据。
支付方式不判断报价
智能体可以在低质量的数据集上成功支出。它可以从多个服务购买相同的答案，或者接受高于任务价值的价格。支付机制不会判定该购买是浪费的。
该决策属于智能体的策略和服务选择过程。钱包文章将交易限制与更广泛的任务预算分开。身份文章检查智能体在判断另一个智能体或服务时可使用的证据。
对于商家来说，可预测的响应质量和定价可能比微小的支付开销差异更重要。客户应能够在支付前确定其将收到什么。卖家指南侧重于该报价。
选择支持的路径，然后进行比较
写下支付资产、方法、计费单位和最大风险敞口。询问谁提交结算以及卖家如何记录失败的交付。然后，在两种候选集成下，在相同的约束条件下测试该路径。
已经使用支付平台的商家可能会看重其会计和支持。针对稳定币原生客户的服务可能更倾向于不同的操作路径。任何偏好都不会使底层协议变得普遍更好。
财务比较是下一步。我们的微支付计算器显示，即使客户支付相同的每请求价格，结算频率也能改变结果。
有用的兼容性测试
选取一个固定价格端点和一个计费会话。针对每个候选集成，记录客户端版本、商户版本、接受的方法、最大授权以及取消行为。
通过固定价格测试的客户端已证明了该路由。它尚未证明流式传输、会话关闭或协议宣传的所有方法。相反，处理 x402 支付的适配器并不与每一个 x402 方案建立通用兼容性。支持的交集才是您可以部署的产品。MPP 与 x402 的集成。