x402 协议深度解析：用一个 HTTP 状态码，重建互联网的支付层
x402 协议深度解析：用一个 HTTP 状态码，重建互联网的支付层
导语
互联网有一个"遗憾"。
1997 年，HTTP/1.1 规范定义了一个状态码——402 Payment Required。设计者的初衷是：当客户端访问一个需要付费的资源时，服务器返回 402，客户端完成支付后重试请求。
但 28 年来，这个状态码一直处于"保留"状态，从未被正式启用。原因很简单：当时没有原生的互联网支付基础设施。 信用卡体系是离线的，PayPal 是中心化的，没有一种支付方式能像 HTTP 请求一样即时、无摩擦、可编程。
直到 2025 年。
区块链上的稳定币（USDC、USDT）提供了可编程的即时支付能力，AI Agent 创造了海量的机器对机器微支付需求——HTTP 402 终于等到了它的时代。
2025 年 5 月，Coinbase 推出了 x402 协议——一个将 HTTP 402 状态码变成真正可用的互联网原生支付标准的开源协议。2025 年 12 月，x402 V2 发布，从"单一 API 调用付费"进化为"统一互联网支付层"。
截至目前，x402 已处理超过 1 亿笔支付，覆盖 API、应用程序和 AI Agent 场景。
本文是系列最后一篇，将深入 x402 的技术内核。
官方网站：https://x402.org
GitHub：https://github.com/coinbase
一、HTTP 402：沉睡 28 年的状态码
1.1 HTTP 状态码的设计哲学
HTTP 协议为不同的响应场景预留了数百个状态码。我们熟悉的：
200 OK：请求成功404 Not Found：资源不存在403 Forbidden：没有权限401 Unauthorized：未认证
而 402 Payment Required 的含义是：资源存在，你也认证了，但你需要付费才能访问。
1.2 为什么 402 从未被启用？
| 时期 | 障碍 | 具体原因 |
|---|---|---|
| 1997~2010 | 无互联网原生支付 | 信用卡需要人工输入卡号，无法嵌入 HTTP 流程 |
| 2010~2020 | 中心化支付的限制 | PayPal/Stripe 需要注册账户、预存信息，不适合即时微支付 |
| 2020~2024 | 微支付经济不成立 | 传统支付的每笔手续费（$0.30+）高于微交易本身 |
三个条件在 2025 年同时成熟：
- 稳定币：USDC 等链上稳定币实现了即时、低成本、可编程的价值转移
- AI Agent：创造了海量的机器对机器微支付需求（API 按次调用、Agent 间服务交易）
- Layer 2 网络：Base、Solana 等高性能链将交易成本降至几乎可忽略
x402 的核心洞察：互联网缺失的不是支付的"能力"，而是支付的"协议层"。 HTTP 早已预留了接口（402），现在终于有了与之匹配的基础设施。
二、x402 的设计哲学：五个零
x402 的设计遵循"五个零"原则，与传统支付形成鲜明对比：
| 原则 | 含义 | 对比传统支付 |
|---|---|---|
| 零协议费 | 使用 x402 协议本身不收费，只需支付底层链的 gas 费 | 信用卡收 2~3% 手续费 |
| 零等待 | 支付速度等同于互联网传输速度 | 信用卡结算需要 T+1~T+3 |
| 零摩擦 | 无需注册账户，无需填写个人信息 | 需要注册、绑卡、KYC |
| 零中心化 | 任何人都可以构建和扩展 x402 | 依赖 Stripe/PayPal 等中心化平台 |
| 零限制 | 中立标准，不绑定特定区块链 | 绑定特定支付网络 |
用一句话概括 x402 的设计哲学：让支付像访问网页一样自然——发送 HTTP 请求，付费，获取数据。
三、核心工作流：402 支付循环
3.1 基本流程
x402 的支付流程极其简洁，只有四步：
3.2 402 响应的结构
当服务端返回 HTTP 402 时，响应中包含支付要求的详细信息：
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402": {
"version": "2",
"accepts": [
{
"network": "base",
"asset": "USDC",
"amount": "0.001",
"payTo": "0x1234...abcd",
"description": "Weather data - single query"
},
{
"network": "solana",
"asset": "USDC",
"amount": "0.001",
"payTo": "5xyz...9abc",
"description": "Weather data - single query"
}
],
"resource": "/weather",
"scheme": "exact"
}
}
关键设计点：
- 多链支持：
accepts数组可以列出多个链和币种选项，客户端选择自己方便的 - 金额明确：精确到链上的最小单位
- 收款地址透明：直接指定链上地址，没有中间商
- 资源绑定：明确标注这笔支付对应哪个资源
3.3 支付凭证的传递
客户端完成链上支付后，在重试请求中通过 HTTP Header 携带支付凭证：
GET /weather?city=beijing HTTP/1.1
X-402-Payment: {"network":"base","txHash":"0xabc...123","asset":"USDC","amount":"0.001"}
服务端验证交易哈希的有效性（确认链上转账已完成），然后返回数据。
四、服务端集成：一行代码
4.1 极简中间件模式
x402 最吸引开发者的特性之一是极其简洁的服务端集成。以 Node.js 为例：
import express from 'express';
import { paymentMiddleware } from '@x402/middleware';
const app = express();
// 一行代码为路由添加付费墙
app.use(paymentMiddleware({
"GET /weather": {
accepts: [
{ network: "base", asset: "USDC", amount: "0.001" },
{ network: "solana", asset: "USDC", amount: "0.001" }
],
description: "Weather data query"
},
"GET /premium-analysis": {
accepts: [
{ network: "base", asset: "USDC", amount: "0.05" }
],
description: "Premium market analysis report"
}
}));
// 正常的业务逻辑，无需修改
app.get('/weather', (req, res) => {
res.json({ city: "beijing", temp: "22°C", condition: "sunny" });
});
app.get('/premium-analysis', (req, res) => {
res.json({ analysis: "..." });
});
app.listen(3000);
开发者只需要做一件事：在路由配置中声明"这个接口要收多少钱"。 支付验证、402 响应生成、凭证校验全部由中间件自动处理。
4.2 客户端集成
对于 AI Agent 或自动化客户端：
import { x402Client } from '@x402/client';
const client = new x402Client({
wallet: myWallet, // 链上钱包
preferredNetwork: 'base'
});
// 自动处理 402 流程：请求 → 收到 402 → 支付 → 重试
const weatherData = await client.fetch('https://api.example.com/weather?city=beijing');
console.log(weatherData);
// 输出：{ city: "beijing", temp: "22°C", condition: "sunny" }
对于 AI Agent 而言，x402 是完全透明的： Agent 只需要正常发起 HTTP 请求，x402 客户端库自动处理支付流程。Agent 甚至不需要"知道"它在付费——一切都内嵌在 HTTP 交互中。
五、V1 到 V2：从 API 付费到互联网支付层
5.1 V1 的局限
x402 V1（2025 年 5 月）实现了基本的"402 支付循环"，但存在几个明显的局限：
| 局限 | 具体表现 |
|---|---|
| 单一调用模式 | 只支持"一次请求一次支付"，不支持订阅和批量 |
| 单链支持 | 每次部署只能支持一条链 |
| 无会话管理 | 每次请求都需要重新验证，高频场景效率低 |
| 架构耦合 | 协议、SDK 和支付服务商的代码混在一起 |
5.2 V2 的关键升级
2025 年 12 月，x402 V2 发布，带来了五大升级：
升级一：模块化架构
V2 将整个系统拆分为三层：
┌──────────────────────────────────────────┐
│ 协议规范（Protocol Spec） │
│ 定义 402 响应格式、支付凭证格式等 │
├──────────────────────────────────────────┤
│ SDK 实现（多语言） │
│ TypeScript / Rust / 更多语言支持 │
├──────────────────────────────────────────┤
│ 支付服务商（Providers） │
│ Base / Solana / ACH / 卡网络（可插拔） │
└──────────────────────────────────────────┘
好处： 添加一条新的区块链支持，只需要开发一个新的 Provider 插件，不需要改动协议规范或 SDK——真正的"即插即用"。
升级二：会话复用
V1 的每次请求都需要独立完成一轮支付验证。对于 AI Agent 高频调用 API 的场景（每秒数十次），这带来了巨大的开销。
V2 引入了钱包会话（Wallet Session）机制：
首次请求：完整的 402 支付流程
↓ 建立会话
后续请求：复用会话，跳过支付验证
↓ 会话内请求按预授权额度扣费
会话到期：重新建立
这对 AI Agent 至关重要： Agent 与某个 API 建立会话后，后续的调用几乎是零延迟的——支付完全嵌入了 HTTP 流程，Agent 感知不到任何中断。
升级三：动态路由与定价
V2 支持根据请求参数动态计算价格和路由目标：
app.use(paymentMiddleware({
"GET /translate": {
accepts: [{ network: "base", asset: "USDC" }],
// 动态定价：根据文本长度计费
pricing: (req) => ({
amount: Math.ceil(req.query.text.length / 100) * 0.001
}),
// 动态路由：多租户场景
payTo: (req) => getProviderAddress(req.query.provider)
}
}));
升级四：生命周期钩子
V2 在支付流程的关键节点提供了钩子，开发者可以插入自定义逻辑：
| 钩子 | 触发时机 | 典型用途 |
|---|---|---|
beforePayment |
支付发送前 | 条件验证、反欺诈检查 |
afterPayment |
支付发送后 | 记录日志、触发后续流程 |
beforeSettlement |
结算验证前 | 自定义验证逻辑 |
afterSettlement |
结算验证后 | 指标监控、故障恢复 |
六、x402 vs 传统支付 vs AP2
6.1 三方对比
| 维度 | 传统支付（Stripe 等） | AP2 | x402 |
|---|---|---|---|
| 注册要求 | 需要商家注册 + 用户绑卡 | 需要多方角色注册 | 无需注册 |
| 支付方式 | 信用卡、银行转账 | 信用卡、银行转账、稳定币 | 链上稳定币 |
| 最小交易金额 | ~$0.50（受手续费限制） | 中大额为主 | $0.001 起 | ||
| 结算速度 | T+1 ~ T+3 | 依赖支付网络 | 即时 |
| 手续费 | 2~3% + $0.30/笔 | 依赖支付网络 | 链上 gas 费（<$0.01） |
| 适合场景 | 电商、订阅 | Agent 代人购物 | API 微支付、Agent 间交易 |
| 开发者集成 | SDK + 控制台配置 | 多角色对接 | 一行中间件代码 |
| 用户体验 | 输入卡号 → 付款 | 签署 VDC 凭证 | 完全透明（自动 402 流程） |
6.2 AP2 与 x402：互补而非竞争
AP2 和 x402 面向完全不同的支付场景，互补关系清晰：
┌─────────────────────────────────────────────────────────┐
│ AI Agent 支付场景 │
├───────────────────────┬─────────────────────────────────┤
│ AP2 的领地 │ x402 的领地 │
│ │ │
│ • 代人在电商购物 │ • Agent 调用付费 API │
│ • 订阅 SaaS 服务 │ • Agent 间按次购买推理能力 │
│ • 大额消费授权 │ • 内容微支付（按篇/按段） │
│ • 需要用户明确授权 │ • 自动化微交易（$0.001级别） │
│ • 需要争议解决机制 │ • 无需人工介入的机器间交易 │
│ │ │
│ 支付方式：信用卡/银行 │ 支付方式：链上稳定币 │
│ 信任机制：VDC 签名 │ 信任机制：链上验证 │
│ 结算：依赖支付网络 │ 结算：即时链上结算 │
└───────────────────────┴─────────────────────────────────┘
一个混合场景的例子：
你的 Agent 要帮你规划旅行：
- [A2A] 你的 Agent 与航空公司 Agent、酒店 Agent 通信
- [x402] 你的 Agent 调用天气预报 API（$0.002/次）和目的地评分 API（$0.005/次）
- [AP2] 确定方案后，Agent 用你的信用卡预订机票（$800）和酒店（$500）
x402 处理"小额高频"，AP2 处理"大额授权"——两者共同覆盖了 Agent 支付的全场景。
七、生态现状与数据
7.1 关键数据
| 指标 | 数值 |
|---|---|
| 累计交易笔数 | 1 亿+ |
| 累计交易金额 | $2,400 万+ |
| 买方数量 | ~9.4 万 |
| 卖方数量 | ~2.2 万 |
| GitHub Stars | 5,300+ |
7.2 技术实现
| 实现 | 语言 | 说明 |
|---|---|---|
| 官方实现 | TypeScript | Coinbase 维护，最完整的 SDK |
| 社区实现 | Rust | x402-rs，支持 V1 和 V2 |
| 中间件 | Node.js | Express/Koa 中间件 |
7.3 支持的网络
| 网络 | 结算速度 | Gas 费用 |
|---|---|---|
| Base（Coinbase L2） | ~2 秒 | <$0.01 |
| Solana | ~0.4 秒 | <$0.01 |
| 更多网络 | 通过 V2 Provider 插件扩展 | - |
八、开发者快速入门
8.1 5 分钟搭建一个 x402 付费 API
Step 1：安装依赖
npm install express @x402/middleware
Step 2：创建服务
import express from 'express';
import { paymentMiddleware } from '@x402/middleware';
const app = express();
app.use(paymentMiddleware({
"GET /joke": {
accepts: [
{ network: "base", asset: "USDC", amount: "0.001" }
],
description: "Get a random programming joke"
}
}));
app.get('/joke', (req, res) => {
const jokes = [
"Why do programmers prefer dark mode? Because light attracts bugs.",
"There are 10 types of people: those who understand binary and those who don't.",
];
res.json({ joke: jokes[Math.floor(Math.random() * jokes.length)] });
});
app.listen(3000, () => console.log('x402 API running on port 3000'));
Step 3：测试
# 不带支付凭证，收到 402
curl http://localhost:3000/joke
# 返回：HTTP 402 { "x402": { "accepts": [...] } }
# 带支付凭证，获取数据
curl http://localhost:3000/joke \
-H 'X-402-Payment: {"network":"base","txHash":"0x...","asset":"USDC","amount":"0.001"}'
# 返回：HTTP 200 { "joke": "..." }
九、写在最后
x402 的魅力在于它的简洁。
在 AP2 用复杂的角色分离和加密凭证来解决"Agent 代人花钱"的信任问题时，x402 选择了一条完全不同的路径：不需要信任——链上验证就是一切。
你不需要注册账户，不需要签署授权，不需要信任任何中间方。你只需要发送一笔链上转账，交易哈希就是你的"通行证"。这种极简主义让 x402 成为了机器对机器交易的最佳选择——AI Agent 不需要理解复杂的授权流程，它只需要一个钱包和一个 HTTP 客户端。
当然，x402 的适用边界也很清晰：它不适合大额消费（缺乏消费者保护和争议解决），不适合需要用户明确授权的场景（没有 VDC 那样的意图证明机制）。这正是 AP2 和 x402 互补的原因：AP2 管"大事"，x402 管"小事"。
回到开头的那个故事：HTTP 402 等了 28 年，终于等到了属于它的时代。而这个时代的关键词不是"在线购物"，而是 AI Agent 经济——数十亿个 Agent 每天进行数万亿次微交易，每一次交易都像访问网页一样自然。
x402 就是为这个未来而生的协议。
关注公众号「coft」，获取更多 AI 时代的深度洞察和技术实战干货。
浙公网安备 33010602011771号