原文标题:Stripe's MPP vs. x402: What Actually Happened Today
原文作者:Nick Sawinyh,defiprime.com
编译:Peggy,Blockbeats
编者按:围绕 Agent 如何支付这一问题,x402 与 MPP 给出了两种几乎相反的路径。
x402 走的是协议最小化:把支付直接嵌入 HTTP 请求,用最简单的方式实现请求即付费。没有账户、没有中间商,更像互联网早期那种开放、无许可的设计,适合长尾开发者和去中心化场景。
MPP 则是系统最大化:通过会话(sessions)、流式支付与合规体系,解决高频交易、风控和法币接入问题。它不追求纯粹,而是优先满足现实商业需求,更适合企业级与规模化应用。
两者的差异,本质上是同一个问题的两种解法:是把支付做成协议的一部分,还是做成系统的一层。
也正因此,它们并非完全竞争关系,而更像分布在不同区间,x402 覆盖开放网络的长尾需求,MPP 承接高频与商业化流量。在一个尚未成型的 Agent 经济里,这种分化或许是必然的。
以下为原文:
HTTP 状态码 402 自 20 世纪 90 年代末在 HTTP/1.1 规范中被定义以来,就一直在等待一个用武之地。它的含义是需要支付(Payment Required)。当初的设想是:将支付能力嵌入到 Web 的协议层,让机器能够像请求网页一样去购买资源。
但这一设想大多并未实现。多年来,这个状态码只在一些边缘场景中偶尔出现,比如 Shopify 的限流响应、Apple Mobile Me 的计费错误等,却始终没有人真正构建出它所暗示的微支付未来。取而代之的,是信用卡、订阅制付费墙,以及 API Key 机制,这些系统本质上都是为有人手操作的人类设计的。
而今天,这一未来出现了两种彼此竞争的实现路径,并且在同一天发布。接下来,我想梳理它们分别是什么、有什么差异,以及为什么 Stripe 会同时押注这两条路线。
x402:更简单的一种方案
Coinbase 于 2025 年 5 月正式推出了 x402,其核心思路几乎可以说是极简到激进。客户端请求一个资源;服务器返回 HTTP402,并告知客户端:需要支付多少费用、使用什么代币、在哪条链上完成支付。客户端在链上完成支付后,将支付凭证附在重新发起的请求中,服务器随即交付资源。
就这么简单。没有账户体系,没有 API Key,也没有订阅机制。只是一次 HTTP 请求往返,中间插入了一笔支付。
如今,Stripe 已在其支付体系中提供对 x402 的原生支持,商家可以通过现有后台直接接收这类支付。不过,从本质上来说,x402 仍然是 Coinbase 主导的协议,由其与 Cloudflare 于 2025 年 9 月共同发起的 x402 Foundation 负责治理。该协议完全开源(Apache 2.0 许可),并提供 TypeScript、Go 和 Python 等多语言 SDK。
在支持范围上,Coinbase 的官方文档显示,目前已在 Base、Polygon 和 Solana 上支持 ERC-20 支付。同时,生态也在探索将其扩展至 Avalanche、Sui 和 Near 等其他链,但成熟度不一。
再来看 adoption 数据,这部分就稍微复杂一些。Coinbase 表示,x402 已通过其 Agentic Wallet 基础设施处理了超过 5000 万笔交易。听起来很亮眼,但根据 CoinDesk 在 3 月 11 日援引 Artemis 的链上分析数据:日交易量约为 13.1 万笔,总金额约 2.8 万美元,单笔平均支付仅约 0.20 美元,其中大约一半更像是测试或游戏化行为,而非真实商业交易。
但这未必是坏事。因为这个协议本来就是为一个尚未真正存在的市场设计的,一个由 AI agent 进行微额支付(甚至低于 1 美分),用于 API 调用和数据查询的世界。而服务这一市场的商家,也才刚刚开始出现。
例如,Google 的 Agentic Payments Protocol(AP2,属于 A2A 框架)已经集成了 x402;Lowe's Innovation Labs 还展示了一个 demo:AI agent 可以在一个流程中完成商品发现、调研到下单的全过程。同时,World(由 Sam Altman 发起)本周发布了 AgentKit,为 x402 钱包增加人类身份证明能力。
其背后的核心假设是:只要把支付变得像 HTTP 请求一样轻量,应用场景自然会出现。至于这是否成立,还有待验证。
MPP:全栈方案
Stripe 和 Tempo 选择了一条不同的路径。Machine Payments Protocol(MPP)于今日随 Tempo 主网上线一同发布。与作为现有区块链之上轻量封装层的 x402 不同,MPP 是专门为高频交易的智能体(agents)这一场景而设计的。
其核心机制是会话(sessions)。不同于每次请求资源都要发起一笔链上交易,agent 可以先一次性授权一个支出额度,然后在该额度内持续进行微支付。如果你是一个每小时需要查询上千次数据源的 AI,就绝不希望每次都签名并广播一笔链上交易,而 sessions 正是为了解决这一问题。
Tempo 这条链也是围绕这一需求构建的。它支持每秒数万笔交易,具备亚秒级确认时间,而且没有原生 gas 代币。用户可以直接用稳定币支付手续费,省去了为了转账还要先购买某种随机代币的繁琐步骤。
另一个值得理解的组件是:Stripe 的 Agentic Commerce Suite 中包含 Shared Payment Tokens(SPTs)。这并不是 MPP 本身的一部分,而是 Stripe 的扩展机制,但可以与其协同使用。SPT 允许 agent 在不暴露真实数据的情况下,将用户的银行卡或钱包凭证安全地传递给商家。这些凭证仅限单次交易、且有时间限制,可以理解为一种可编程、自毁式授权。在实际使用中,这意味着一个通过 MPP 支付的 agent,既可以使用 Tempo 上的 USDC,也可以使用用户绑定的 Visa 卡,甚至两者结合。
根据 Tempo 主网上线博客披露,其合作方包括 Anthropic、DoorDash、Mastercard、Nubank、OpenAI、Ramp、Revolut、Shopify、渣打银行(Standard Chartered)和 Visa。《The Block》则报道称,MPP 上线时支付目录中已有超过 100 项服务,包括 Alchemy、Dune Analytics、Merit Systems 和 Parallel Web Systems。Tempo 与 Paradigm 的联合创始人 Matt Huang 在接受《Fortune》采访时表示,这一领域仍处于早期阶段,MPP 的设计目标是未来可以扩展到 Tempo 之外的更多链上环境。
为什么 Stripe 同时支持两者
如果你已经接入了 Stripe,最实际的答案是:你不需要在两者之间做选择。
Stripe 通过两条独立的集成路径分别支持 x402 和 MPP,而不是将它们抽象成一个统一接口。对于 x402,其文档主要涵盖充值地址生成、链上监控以及资金结算至 Stripe 账户的流程——你负责返回 402 响应,底层的加密支付基础设施由 Stripe 处理。目前支持 Base 上的 USDC,未来还会扩展。对于 MPP,商家则可以通过同一套 PaymentIntents API,接收基于会话的流式支付。
Stripe 于 2025 年 12 月发布的 Agentic Commerce Suite 构建在这两条支付轨道之上。商家只需上传商品目录,选择希望接入的 AI agents,Stripe 就会负责商品发现、结账流程、反欺诈以及税务处理。目前,URBN、Etsy、Coach、Kate Spade 和 Ashley Furniture 已经在使用,Wix、WooCommerce、BigCommerce、Squarespace 和 commercetools 等平台也已完成集成。
其策略其实很清晰:掌控抽象层,让底层协议自由竞争。
对比来看
从宏观上看,这两种协议在做同一件事:让机器可以通过 HTTP 为资源付费。但真正的差异,体现在细节之中。
x402(由 Coinbase 主导)vs MPP(Stripe + Tempo)
标准化
x402:完全开源(Apache 2.0),由 x402 Foundation 推动多方参与(Coinbase、Cloudflare、Visa、Google)。
MPP:开放标准,由 Stripe 与 Tempo 共同制定,属于 Stripe Agentic Commerce Suite 的一部分。
HTTP 机制
x402:复活 HTTP 402,通过 PAYMENT-REQUIRED 头发起请求,使用 PAYMENT-SIGNATURE 完成重试。
MPP:同样采用 challenge-response 机制,但使用的是 Payment HTTP Authentication Scheme(IETF 草案),通过 HMAC 绑定 challenge ID。
支付底层(Rails)
x402:设计上链无关,目前在 Base、Polygon、Solana 上已有支持,其他链仍在探索中。
MPP:基于 Tempo 区块链——一个为支付优化的 L1,支持 1 万+ TPS、亚秒级确认,无原生 gas 代币;长期目标是实现跨链兼容。
支付方式
x402:纯稳定币,完全链上。
MPP:支持 Tempo 上的 USDC + SPT(Stripe 的机制),实现加密与法币混合(银行卡、钱包、BNPL)。
结算方式
x402:按链上结算(约 200ms 至数秒),由 Coinbase 等 facilitator 负责验证与结算。
MPP:Tempo 亚秒级确认,Stripe 自动入账并处理合规。
商户接入
x402:开源中间件(Express、Hono、Next.js 等),可自建或使用 facilitator。
MPP:直接接入 Stripe 的 PaymentIntents API,风控、税务、退款、报表全部内置。
核心创新
x402:极致简洁、无厂商绑定,类似支付领域的 Unix 哲学。
MPP:高吞吐 + 法币融合,通过 session 实现流式支付、微支付聚合,以及基于 SPT 的可编程支出控制。
关键合作方
x402:Coinbase、Cloudflare、Google(A2A/AP2)、Visa、World、Anthropic(MCP)。
MPP:Stripe、Visa、Lightspark、Anthropic、DoorDash、Mastercard、OpenAI、Shopify、Revolut、渣打银行。
x402 更像是你在构建开放系统时的首选方案:独立开发者 API、去中心化数据市场,或者任何不希望依赖支付处理商的服务。它的规范可以写进一篇白皮书,接入只需要一个中间件和一个钱包地址。这种纯粹性很有吸引力——尽管纯加密的限制也意味着它的受众更窄。
MPP 则是另一种完全不同的范式。如果你的 agent 需要在一次会话中进行数百甚至上千次交易,而不希望每次都上链,那么它就是更合理的选择。session 机制让大部分交互保持在链下,直到最终结算;Stripe 的合规体系负责风控和税务;而 SPT 的混合模式,则让 agent 不再局限于稳定币,还可以直接调用用户的 Visa 等支付方式。它不那么优雅,但更贴近现实。
有意思的是,它们其实并不完全是竞争关系。x402 覆盖长尾开放场景,MPP 覆盖企业级高频流量。Stripe 的策略也很明确:不押注单一协议,而是确保无论哪条路径胜出,资金最终都流入 Stripe 的账户体系。
现实情况:现在到底发展到哪一步了?
说实话,目前几乎还没有真正的规模化交易。
根据 Coinbase 的 x402 发布信息,早期合作方包括 Hyperbolic(GPU 推理付费)和 Anthropic(MCP 协议集成)。Stripe 的博客提到按 API 调用付费的 agent 场景(例如 CoinGecko)。Tempo 上线时目录中有 100+ 服务。Cloudflare 的 Agents SDK 已原生支持 x402,一些 Base L2 上的小项目也在尝试用 x402 做付费网关。
但整体来看:交易量很小,商户数量有限,大多数活动仍停留在实验阶段。
这其实并不意外。任何新的支付基础设施,早期都是这样。所谓合作伙伴名单,有时从签了意向书到已经上线生产之间差距很大,而这些发布通常不会特别区分。
更值得关注的是基础设施背后的重量级参与者。Stripe 在 2025 年处理了 1.9 万亿美元的支付,总量同比增长 34%。同时,Coinbase、Cloudflare、Visa、Google,以及 Tempo 的一整套合作网络都已入场。
也就是说,轨道已经铺好。问题只剩一个:2026 年,AI agent 是否真的需要在这个轨道上大规模交易?还是这更像 1998 年铺设光纤——需求还没来,但基础设施先行。
那该选哪一个?
如果你在构建一个开放、无需许可的系统——x402 是更自然的选择。无需注册平台、无需对接支付商,导入中间件、绑定钱包即可收款。代价是:合规、风控、法币结算都要自己处理。
如果你已经在 Stripe 体系内,并希望接入 agent 流量——MPP 更合适。session、流式支付、法币+加密混合,以及完整的合规体系,本质上更像配置升级,而不是系统重构。
如果你只关心一件事:不管 agent 用哪种协议,我都能收钱。那答案其实就是:用 Stripe。它两边都支持。
HTTP 402 终于派上用场了。只不过,它等了差不多 27 年。
