什么是 HTTP 402(Payment Required)?

一句话:服务器在说"这页内容需要付费才能访问"。

提示:402 在标准中被标注为 Reserved(保留),并非所有网站/浏览器都会使用它。

HTTP 402 完整指南

HTTP 402 Payment Required 是 HTTP 规范中最神秘且最少被使用的状态码之一。与广为人知的 404(未找到)或 401(未授权)不同,402 状态码的设计初衷是前瞻性的:在网络上实现原生支付机制。

当服务器返回 402 响应时,它传达的信息很明确:"这个资源存在,你的凭证也正确,但你需要付费才能访问。" 这与其他 4xx 客户端错误码有本质区别,后者通常表示身份验证或授权问题。

HTTP 402 的历史

402 状态码有着一段有趣的历史,反映了早期对网络商务的乐观期望:

1990年代:最初的愿景

HTTP 402 被包含在最初的 HTTP/1.1 规范(RFC 2068,1997年发布)中,明确注明"保留供将来使用"。当时的想法是,随着电子商务的发展,一种标准化的支付请求方式将变得不可或缺。HTTP 的设计者们预期数字微支付将变得普遍。

2000-2010年代:沉寂期

尽管 402 作为规范的一部分存在了二十多年,它仍然基本没有被使用。由于缺乏标准化的数字支付系统,加上实现跨平台支付流程的复杂性,网站们开发了各自的专有解决方案。

2020年代:复兴

随着加密货币、USDC 等稳定币以及 x402 等协议的兴起,402 状态码终于找到了它的用武之地。现代区块链技术提供了缺失的那块拼图:一个可以与 HTTP 无缝协作的标准化、可编程支付层。

HTTP 402 与 401、403、404 有何不同?

理解这些状态码之间的区别对于正确的网站开发和 API 设计至关重要:

状态码 含义 常见场景 用户需要采取的操作
401 Unauthorized 需要身份认证 未登录、令牌失效 登录或刷新凭证
403 Forbidden 已认证但无权限 账号无权访问 向管理员申请权限
402 Payment Required 需要付费 按次付费、微支付 完成支付交易
404 Not Found 资源不存在 链接错误、内容已删除 检查 URL 或联系支持

关键区别

为什么 HTTP 402 很少被使用?

尽管自 1997 年以来就是 HTTP 规范的一部分,402 状态码的采用率一直很低。原因如下:

1. 没有标准支付协议

HTTP 规范定义了状态码,但没有规定支付应该如何进行。没有标准化的支付头、请求格式或响应结构,每个实现都与其他实现不兼容。

2. 传统支付的复杂性

信用卡支付需要与支付处理器的复杂集成、PCI 合规性、循环计费逻辑和反欺诈系统。这种开销使得 402 对于小额交易不切实际。

3. 微支付的摩擦

传统支付系统有最低交易费用,使得微支付(1美元以下)在经济上不可行。当交易成本为 0.30 美元时,0.05 美元的文章访问费就行不通了。

4. 替代解决方案

公司们开发了替代方案:订阅模式、广告支持的内容、基于 OAuth 的访问令牌,或者返回 200 OK 并使用 JavaScript 控制访问的自定义付费墙。

HTTP 402 的技术规范

根据 RFC 9110(当前的 HTTP 规范),402 状态码定义如下:

RFC 9110 第 15.5.3 节:
"402 (Payment Required) 状态码保留供将来使用。"

响应头

虽然没有官方标准化,但实现通常包括:

x402 协议头

x402 协议通过全面的支付协商系统标准化了这些头。当你从启用 x402 的服务器收到 402 响应时,响应包含自动完成支付所需的所有信息。

HTTP 402 的实际应用场景

402 状态码特别适合以下几种新兴应用场景:

1. API 变现

按调用付费的 API 可以使用 402 对每个请求收费。AI 服务、数据 API 和高级功能可以在没有订阅的情况下访问——只需为你使用的部分付费。

2. 内容微支付

新闻文章、研究论文和优质内容可以通过小额支付解锁。无需订阅——只需为单篇内容付费。

3. 机器对机器支付

自主代理和机器人无需人工干预即可访问付费资源。402 响应提供自动支付处理所需的一切信息。

4. 去中心化服务

Web3 应用可以使用 402 来限制对去中心化资源的访问,支付以 USDC 或其他稳定币在链上结算。

5. 游戏和数字商品

游戏内购买、数字资产和高级功能可以通过 402 响应触发的即时支付解锁。

浏览器和平台支持

所有现代浏览器都将 402 识别为有效的 HTTP 状态码,尽管它们没有内置的处理方式:

平台 状态 备注
Chrome/Edge ✅ 已识别 显示为客户端错误
Firefox ✅ 已识别 显示为客户端错误
Safari ✅ 已识别 显示为客户端错误
Node.js/fetch ✅ 完全支持 可以编程处理
cURL ✅ 完全支持 返回状态码 402

虽然浏览器不会自动处理 402 支付,但客户端库和浏览器扩展可以拦截 402 响应并触发支付流程。

如何把 402 变成实际支付体验?

这正是 x402 要解决的问题:将"需要付费"的信号转换为自动、无缝的结账体验。

x402 如何与 HTTP 402 协作

  1. 请求: 客户端请求受保护的资源
  2. 402 响应: 服务器返回 402,头信息中包含支付详情
  3. 支付: 客户端钱包签署 USDC 支付交易
  4. 重试: 客户端重新发送请求,头信息中包含支付证明
  5. 访问: 服务器验证支付并返回资源

整个流程在几秒钟内完成,通常无需任何用户交互。这就是 HTTP 402 设计时的愿景,现在通过现代加密货币基础设施终于实现了。

了解更多关于 x402 →

在你的应用中实现 HTTP 402

如果你是一名想要在应用中实现 402 的开发者,这里是一个快速概述:

服务端(返回 402)

// Express.js 示例
app.get('/premium-content', (req, res) => {
  if (!isPaid(req)) {
    return res.status(402).json({
      error: 'Payment Required',
      price: '0.10',
      currency: 'USDC',
      paymentAddress: '0x...'
    });
  }
  res.json({ content: '高级内容在这里' });
});

客户端(处理 402)

// JavaScript 示例
const response = await fetch('/premium-content');
if (response.status === 402) {
  const paymentInfo = await response.json();
  // 触发支付流程
  await processPayment(paymentInfo);
  // 带支付证明重试
  return fetch('/premium-content', {
    headers: { 'X-Payment-Proof': proof }
  });
}

HTTP 402 的未来

有了像 x402 这样的协议,HTTP 402 的未来一片光明:

网络最初对原生支付的愿景终于成为现实,而 HTTP 402 正处于这一变革的中心。

延伸阅读

官方文档

背景与历史

x402 协议