Brain Sandbox

一个关于技术与生活的思考实验场

1. 简介:为什么 x402 如此重要?

在当今的互联网上,执行支付——尤其是小额微支付或由 AI 代理驱动的自动化支付——往往充满了摩擦。传统支付方式不仅费用高昂、结算缓慢,而且流程复杂,需要账户注册、信用卡绑定和手动授权,这成为了 AI 驱动的自动化经济发展的巨大障碍。

为了解决这些痛点,x402 协议应运而生。你可能会觉得 x402 是你将遇到的最无聊的技术,但它所解锁的可能性才是真正令人兴奋的地方。它巧妙地激活了在 1997 年 HTTP/1.1 规范中被长期保留、几乎被遗忘的 402 Payment Required 状态码。这并非一个全新的想法——像 Marc Andreessen 和 Brian Armstrong 这样的行业先驱都曾尝试在互联网底层构建原生支付,但直到现在,技术(如稳定币)和需求(如 AI 代理)才真正成熟。x402 协议的本质,按其定义来说,是 “一个为互联网原生支付设计的开放标准 (an open standard for internet native payments)”。它旨在让资金的流动像数据一样无缝、即时且低成本。本指南将逐一拆解 x402 的核心支付流程,帮助你建立清晰、扎实的技术认知。

在深入了解具体步骤之前,让我们先来认识一下 x402 生态系统中的四个关键参与者。

2. 核心概念:认识流程中的四大关键角色

在一次完整的 x402 支付交互中,有四个核心实体协同工作,每个实体都扮演着不可或缺的角色。

客户端 (Client): 一个想要为资源付费的实体 (An entity wanting to pay for a resource),例如 AI 代理或 Web 应用。

资源服务器 (Resource Server): 提供受保护资源(如 API、网页内容或文件)的 HTTP 服务器,它要求客户端在访问前完成支付。

协调器服务器 (Facilitator Server): 一个第三方服务,它帮助资源服务器验证和结算链上支付,极大地简化了服务器端的集成工作,使其无需直接与区块链节点或钱包交互。

区块链 (Blockchain): 作为最终的信任账本,负责记录和确认支付交易,确保交易的不可篡改性和最终性。

了解了这些角色后,现在让我们通过一个完整的请求生命周期,看看它们是如何一步步交互以完成支付的。

3. 核心支付流程:一次完整的 x402 交互(12个步骤)

整个支付流程被精心设计为一系列标准的 HTTP 交互,确保了其通用性和易于集成的特性。值得注意的是,如果客户端已经缓存了资源的支付要求,那么步骤1和步骤2是可选的,这可以进一步提高交互效率。

以下是完整流程的12个步骤分解:

  1. 客户端 → 资源服务器:发起初始请求 客户端(例如一个 AI 代理)向资源服务器的受保护端点(如 /api)发起一个标准的 HTTP GET 请求,希望能获取资源。
  2. 资源服务器 → 客户端:响应 402 Payment Required 资源服务器检测到该请求未包含有效的支付信息,因此拒绝了初始请求。它返回一个 402 Payment Required 状态码,并在响应体中附带一个 JSON 对象,详细说明了可接受的支付方式、金额和收款地址。
  3. 客户端:创建支付负载 (Payload) 客户端解析服务器返回的支付要求,选择一种自己支持的支付方式,并据此创建一个包含签名授权等信息的支付负载(Payment Payload)。
  4. 客户端 → 资源服务器:携带支付信息再次请求 客户端再次向同一资源端点发起请求。这一次,它将上一步生成的支付负载通过一个自定义的 X-PAYMENT HTTP 头部(Header)发送给资源服务器。
  5. 资源服务器 → 协调器:请求验证支付 资源服务器自身不直接处理复杂的链上验证。它将从客户端收到的支付负载和自身的支付要求一并发送到协调器服务器的 /verify 端点,请求验证该支付的有效性。
  6. 协调器 → 资源服务器:返回验证结果 协调器服务器根据指定的支付方案(Scheme)和网络(Network)对支付负载进行密码学验证,并将验证结果(有效或无效)返回给资源服务器。
  7. 资源服务器:处理有效请求 如果验证通过,资源服务器开始执行请求所需的核心工作(例如,查询数据库、生成报告等)。如果验证失败,它将直接返回 402 错误,流程终止。
  8. 资源服务器 → 协调器:请求结算支付 在准备好最终响应数据后,资源服务器向协调器服务器的 /settle 端点发起请求,要求其将这笔已经验证过的支付真正在区块链上进行结算。
  9. 协调器 → 区块链:将交易提交至区块链 协调器服务器将支付交易广播到相应的区块链网络(例如,提交一笔 USDC 转账交易到智能合约)。
  10. 区块链:确认交易 区块链网络处理这笔交易,并在确认后将其记录在链上,实现资金的最终转移。
  11. 协调器 → 资源服务器:通知服务器结算完成 协调器服务器等待区块链的交易确认,一旦确认完成,它会向资源服务器返回一个包含交易哈希(txHash)等信息的成功响应。
  12. 资源服务器 → 客户端:返回最终资源 资源服务器收到结算成功的通知后,向客户端返回一个 200 OK 的成功响应。响应体中包含了客户端最初请求的资源,同时通过 X-PAYMENT-RESPONSE 头部返回结算详情(如交易哈希),完成整个支付闭环。

现在你已经了解了完整的交互流程,接下来让我们深入剖析在这些步骤中传递的关键数据——支付要求和支付负载——究竟包含了什么信息。

4. 关键数据结构解析

在 x402 协议中,信息的传递依赖于两个核心的 JSON 数据结构。

1. 402 响应体:Payment Required Response

当服务器返回 402 状态码时,其响应体包含一个 JSON 对象,用于告知客户端如何支付。

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "string",
      "network": "string",
      "maxAmountRequired": "string",
      "resource": "string",
      "description": "string",
      "mimeType": "string",
      "outputSchema": {},
      "payTo": "string",
      "maxTimeoutSeconds": 60,
      "asset": "string",
      "extra": {}
    }
  ],
  "error": "string"
}

下表解释了其中最重要的几个字段:

字段 描述
accepts 一个支付要求列表。服务器可以同时接受多种链或多种代币的支付,客户端可从中选择一种。
maxAmountRequired 访问资源所需支付的最高金额,以资产的最小单位(atomic units)表示。这是客户端构建支付负载时最关键的依据。
payTo 接收付款的钱包地址。这是资源提供方最终收到资金的地方。
asset 支付所用资产的合约地址。例如,在 EVM 链上,这通常是 USDC 等 ERC20 代币的合约地址。

2. X-PAYMENT 请求头:Payment Payload

The X-PAYMENT custom HTTP header carries the payment information. Its value is the Payment Payload JSON object, which has been encoded into a Base64 string.

{
  "x402Version": 1,
  "scheme": "string",
  "network": "string",
  "payload": "<scheme dependent>"
}

理解了这些技术细节后,我们来看看 x402 协议究竟能为开发者和未来的互联网应用带来哪些颠覆性的改变。

5. 这对开发者意味着什么?x402 解锁的核心优势

x402 不仅仅是一个技术规范,它为开发者构建下一代互联网应用(尤其是 AI 应用)提供了强大的能力。

6. 总结与下一步

x402 是一个专为 AI 和机器原生支付设计的、构建于 HTTP 之上的开放协议。它通过激活沉睡已久的 402 状态码,为互联网打造了一个统一、无摩擦的价值层。这不仅仅是一次技术升级,它关乎未来互联网经济的形态。据 A16Z 预测,到 2030 年,代理驱动的商业(agentic commerce)可能创造一个高达 30万亿美元 的支付市场。x402 正是为迎接这一未来而构建的基础设施。

通过本指南,你已经掌握了 x402 的核心交互流程和关键概念。现在是开始实践的最佳时机。我们鼓励你访问官方资源,探索示例代码和更深入的技术规范,开启你的互联网原生支付之旅。