HTTP 402：支付所需

撰文：Token Dispatch, Nishil

编译：Block unicorn

 

前言

 

上周我的社交媒体上全是 Monad 的盒子。有没有人和我一样，每天都忍不住登录去开一个？感觉就像回到了童年，拆盲盒、板球卡、宝可梦卡包——所有这些刺激感都浓缩在了点击几下鼠标里。我们长大了，但有些习惯却永远不会消失。

 

说到旧事物，我常常想，如果 2000 年代的人现在尝试使用支付应用和银行服务，他们几乎感觉不到任何差别。为什么即时通讯发展到今天，任何人只需轻轻一点就能给世界上任何人发信息，但当我尝试汇款时，互联网却突然显得过时了呢？

 

这是因为互联网的初衷是为了信息共享，而金钱始终是次要的。我们通过广告、订阅和支付网关来弥补资金缺口。这些方法很巧妙，但并非真正的根本解决方案。

 

我一直觉得很奇怪，互联网让沟通摆脱了地域限制，但资金流动却仍然要通过过时的银行系统。我们已经开发出足够智能的 AI 代理，可以在几秒钟内找到最佳航班，但它们仍然需要等待行动迟缓的人类输入信用卡号才能完成购买。

 

如今，人工智能代理商承担了我们曾经负责的任务，如果还指望他们使用过时的金融系统，那将严重阻碍人工智能的发展。代理需要一种能够像传输数据一样便捷地在网络上转移资金的方式，而我们需要为它们构建这种系统。

 

这就是 Coinbase 试图用 x402 填补的空白。

 

现在就让我们进入正题。

 

被遗忘的状态代码

 

x402 是基于 HTTP 协议中一个早已被人遗忘的部分——它最初的目的是为了让支付像加载图片或视频一样轻松便捷。但要理解 x402 是什么，我们首先需要深入了解 HTTP 本身的工作原理以及 402 状态码的用途。

 

HTTP 是现代网络的基础，它定义了客户端（例如你的浏览器）和服务器之间数据传输的规则。为了管理这种通信，HTTP 使用状态码，这些简短的信号会告诉浏览器在尝试访问页面时发生了什么。你可能已经见过其中的一些状态码：

• HTTP 200 – OK：页面加载成功。

• HTTP 404 – Not Found（未找到）：资源不存在。

• HTTP 500 – Internal Server Error（内部服务器错误）：服务器端出现故障。

 

这些代码帮助浏览器理解交互过程，并将其清晰地传达给用户。

 

 

除了大家熟知的常用代码之外，HTTP 标准还包含一些其他已定义但很少使用的代码，其中之一是 HTTP 402：Payment Required（需要支付）。

 

402 标准本身非常简单明了。它为网页通过 HTTP 标准传递支付相关信息开辟了空间，就像 <img> 标签告诉浏览器在哪里可以找到图片一样。

 

难以置信的是，这个想法竟然沉寂了几十年。我认为它只是需要合适的、能够实现互联网规模化发展的金融工具，也就是区块链。

 

 

但真正的问题是：点击支付后到底会发生什么？

 

根据标准，服务器会返回「HTTP 402：Payment Required（需要支付）」。单独看这似乎微不足道，但如果与能够像网络信息传输一样快速便捷地转移资金的基础设施相结合，则可能带来颠覆性的改变。

 

等等，Stripe 和 PayPal 不就是在做这个吗？让网络支付成为可能？

 

不，Stripe 的运作方式与 x402 的提议有很大的不同。

 

虽然像 Stripe 和 PayPal 这样的互联网支付解决方案实现了网页上进行一键支付，但要实现这一目标，过程中仍然存在很多阻碍。

 

这些解决方案绕过了用户正在交互的 HTTP 服务器，并将用户重定向到它们自己的 API 和接口。这会将商家和用户都限制在一个封闭的生态系统中，需要进行 KYC 验证才能进入，需要信用卡才能支付，并且会收取各种费用，使得小额支付变得困难。

 

如果每次在商店购物都必须从指定的 ATM 机取款，那我干脆什么都不买了。这种体验和现在的 PayPal 很像，只不过是线上版的。

核心问题不在于 PayPal 的设计，而在于传统银行业务本身的可扩展性不足以支持在线商业的流动性。

我可以向世界任何地方的任何人发送表情符号，而且从成本和时间上看，这与发送文章是一样的。但在线支付的情况就不同了。

大多数银行卡和 PayPal 等服务除了固定费用外，还会收取大约 3% 的手续费。这笔费用使得网上小额交易几乎不可能。发送 0.01 美元的费用可能超过 0.30 美元，这简直太荒谬了。

区块链不存在这些限制。最令我兴奋的是，随着稳定币和每秒可处理数千笔交易的高吞吐量网络的出现，一切终于就绪。我们现在拥有了让互联网上的资金转移像发送短信一样便捷的基础设施。

HTTP 遇上区块链 - x402

归根结底，x402 只是对早已被人遗忘的 20 世纪 90 年代状态代码的现代升级。它支持基于 HTTP 的原生支付，并由区块链的轨道提供支持。

让我来给你讲解一下它的工作原理：

请求：当客户端（无论是人还是人工智能）请求某些内容而没有有效的付款时，服务器会回复 HTTP 402 需要付款消息以及 JSON 有效负载，解释需要支付什么、如何支付以及支付给谁。

支付：然后客户进行付款（通常是在支持的网络上使用 USDC），并重新发送带有确认付款授权标头的请求。

验证：支付服务商检查链上支付，如果有效，服务器将释放请求的数据。

重要的是，x402 本身并不处理资金，它只定义握手协议。结算由客户端配置的支付「服务商」（支付处理器或链上合约）完成。

x402 的强大之处在于，它让我的 Web 2.0 开发者朋友们无需进行任何新的集成，也无需复杂的设置，就能将稳定币支付添加到他们现有的网站上。它实际上比配置 Stripe 或 PayPal 还要简单，这让我向他们推介 Web 3 技术变得容易多了。

与此同时，我使用的 AI 系统让我终于可以一键浏览和支付，让网上购物像收发邮件一样轻松便捷。这对我和我的 AI 助手来说都毫不费力。

在线支付方式的这种转变最令我兴奋的是，我终于可以掌控我的资金在网络上的流动方式。我可以制定清晰的策略，明确定义我的资金用途。

我只想为阅读的那篇《华尔街日报》文章付费，而不是每月订阅却积攒成垃圾邮件。我希望我的流媒体应用只按实际观看秒数收费，不再受年度合约的束缚。我希望我的人工智能代理能够按需付费地从付费资源获取研究资料并访问 API。这种程度的控制权令人感到自由。

虽然从单位经济效益来看，允许企业接受小额支付可能对企业来说并不划算，但小额支付能够帮助企业扩大规模，并最终超越目前的营收规模，这一点值得我们关注。尤其当我们关注分级交易如何将被动的互联网用户转化为积极的经济参与者，并有可能在此过程中成倍提升在线 GDP 时，这种优势就更加明显了。

Coinbase 于今年 5 月推出了 x402 标准。自此之后，多个项目开始基于该标准进行开发。一些有趣的用例包括：

1. Questflow：一款多代理编排工具，它使用 x402 协议让代理在复杂的工作流程中自主地为 API 付费。

2. Anchor Browser：允许浏览器内代理通过支付来支付付费墙内容或启动新的浏览会话。

3. Pinata：使用 x402 进行无需账户的 IPFS 上传和检索。无需账户或 API 密钥即可付费使用私有或公共 IPFS 存储和检索。

 

依我看，我们目前所看到的只是冰山一角。一旦资金像数据一样流动，我们就会看到资金在网络上变得可以自由组合。搜索、发现和支付将越来越多地转移到代理手中。

 

这并不令人震惊，但目前 x402 的大多数用例都围绕加密应用。要想吸引外部需求，我们需要合适的网络效应。

 

就像 eBay 是推动 PayPal 早期采用的跳板一样，x402 现在也需要自己的「eBay 时刻」，一个能够推动主流采用的旗舰平台。

 

幸运的是，Coinbase 在 x402 领域发挥了主导作用，这有利于建立重要的 Web 2.0 合作伙伴关系，并使我们离找到能够引发广泛应用的旗舰平台更近一步。其中一些合作意义重大：

• Cloudflare：最近与 Coinbase 合作成立了独立的 x402 基金会。

• 谷歌：将 x402 集成到其新的代理支付协议 2 (AP2) 标准中，以及

• Visa：Visa在其可信代理协议 (TAP) 中添加了对 x402 的支持。

 

我的看法什么？

 

几年后，我会让我的 AI 助手生成一份市场报告。它会悄无声息地访问各种数据源、新闻报道、Reddit 帖子，只需支付几美分就能购买文章并跨过付费墙，同时还能通过我预先设定的策略检查。无需结账窗口，无需支付表单，也无需在后台潜伏任何追踪 cookie 来获取广告收入。一切都按照我的意愿自主完成，自动执行。

 

这是我设想 x402 能开启的未来——一个支付成为网络原生组成部分的世界。

 

一旦 x402 规模化，我们将看到在当今金融体系下无法实现的全新应用场景涌现。用户会将资金存入平台的用户界面，并在网络上随处使用该账户。试想一下，社交媒体的点赞数可以作为创作者的收入来源；健身代理会追踪你的运动装备使用情况，并为你购买符合健康饮食需求的食品；可穿戴设备会监听你的日常对话，并为你推荐潜在的 Polymarket 交易机会；或你的个人代理可以与其他代理沟通，协商并支付机票，帮你预订房间等等。

 

这只是冰山一角。

 

有了 x402，我可以看到一个能够像传递信息一样轻松地传递资金的网络，无论是美分还是美元，无论是代理还是人类。

 

我浏览器里的代理们为此兴奋，并且我本人也是。