# 什么是 x402 协议？面向 AI 代理的 HTTP 402 支付 > x402 协议技术指南：HTTP 402 支付握手如何运作、PAYMENT-REQUIRED 和 PAYMENT-SIGNATURE 请求头、facilitator、支付方案，以及 x402 如何与银行卡通道协同工作。 - **Author**: Ayush Agarwal - **Published**: 2026-09-08 - **Category**: AI, Payments - **URL**: https://dodopayments.com/blogs/zh/x402-protocol --- 一个自主代理正在执行任务。它需要调用一次付费的市场数据 API、一次付费的地理编码服务，以及一次付费的图像模型。这些端点都要求 API 密钥，而每个 API 密钥背后都需要注册表单、绑定信用卡，以及开具给某位人类的月度账单。 代理没有这些东西。它只有一个钱包和一项任务。 这正是 x402 协议存在的全部原因。传统的 API 访问控制假设某个人过去签署过合同，并且账单会在月底统一结算。机器对机器的流量打破了这两个假设：消费者可能是临时的，金额可能不到一美分，而付款决定必须在单次请求周期内完成。 本指南将介绍 x402 是什么、握手流程在请求头层面究竟如何运作、facilitator 的作用，以及----坦率地说----对于同时向人类销售软件的公司而言，它没有解决什么问题。 ## 什么是 x402 协议？ x402 是一种开放支付标准，最初由 Coinbase 开发。它重新启用了长期保留的 HTTP 402"Payment Required"状态码，让客户端无需账户、API 密钥、会话或订阅，即可为单次请求付款。服务器会用 402 响应未付款请求，并返回机器可读的说明，告知可接受的付款方式。客户端签署付款信息，携带签名重试请求，然后获取资源。 这里最重要的设计选择是：付款成为请求本身的属性，而不是预先存在的关系的属性。没有入驻流程、密钥轮换或套餐等级。只要客户端能够付款，请求就会成功。 流程中有三个角色： - 客户端：需要资源的一方，可以是由人类驱动的应用，也可以是自主运行的 AI 代理。 - 资源服务器：卖方，也就是持有可售资源的 API 或端点。 - Facilitator：可选的第三方，负责验证付款载荷，并代表资源服务器完成结算，让卖方无需自行运行链基础设施。 x402 也与传输方式无关。HTTP 是最初的传输方式，但同样的握手流程也可以运行在 MCP（Model Context Protocol）和 A2A（agent-to-agent）传输之上。如果你已经在思考[代理如何通过 MCP 发现并调用付费工具](https://dodopayments.com/blogs/mcp-payments-ai-agents)，那么 x402 正好属于同一个讨论范畴。 ## x402 支付流程如何运作 整个流程是一个中间包含付款步骤的重试循环。客户端的第一次请求预期会失败，而失败响应会携带第二次尝试成功所需的指令。 完整流程如下： 1. 客户端在不附加付款信息的情况下请求资源。 2. 服务器返回 HTTP 402，并通过 `PAYMENT-REQUIRED` 请求头携带经过 base64 编码的 `PaymentRequired` 对象。 3. 客户端从提供的 `PaymentRequirements` 条目中选择一个，并签署 `PaymentPayload`。 4. 客户端重试相同的请求，这次附带 `PAYMENT-SIGNATURE` 请求头。 5. 服务器在本地验证载荷，或将其 POST 到 facilitator 的 `/verify` 端点。 6. 验证成功后，服务器执行实际工作。 7. 服务器直接在链上完成付款结算，或通过 facilitator 的 `/settle` 端点完成结算。 8. 服务器返回 200 OK，并通过 `PAYMENT-RESPONSE` 请求头返回经过 base64 编码的 `SettlementResponse`。 ```mermaid sequenceDiagram participant C as Client (AI agent) participant S as Resource Server participant F as Facilitator C->>S: GET /resource (no payment) S-->>C: 402 Payment Required PAYMENT-REQUIRED header Note over C: Select a PaymentRequirements entry and sign a PaymentPayload C->>S: GET /resource PAYMENT-SIGNATURE header S->>F: POST /verify F-->>S: verification result Note over S: Perform the requested work S->>F: POST /settle F-->>S: SettlementResponse S-->>C: 200 OK + resource PAYMENT-RESPONSE header ``` 有两点值得特别说明。第一，验证和结算是分开的步骤，这意味着服务器可以先确认付款有效，再消耗计算资源，完成工作后再结算。第二，如果服务器愿意自行运行相关基础设施，也可以完全跳过 facilitator，自行验证或结算。 错误类型被有意控制得很少：Payment Required 对应 402，Invalid Payment 对应 400，Payment Failed 对应 402，Server Error 对应 500，Success 对应 200。客户端只需要区分"你还没有付款""付款格式不正确"和"付款没有成功"。 ## x402 的三个请求头 所有协议信息都通过请求头传递，而不是放在响应正文中。这是一项有意的限制：这意味着启用了 x402 的端点可以继续返回原本会返回的任何正文----JSON、图像或流式生成结果----而不会让支付层污染载荷结构。 | 请求头 | 方向 | 载荷 | | ------------------- | -------------- | ---------------------------------------------------------------- | | `PAYMENT-REQUIRED` | 服务器到客户端 | 描述可接受付款选项的 Base64 编码 `PaymentRequired` 对象 | | `PAYMENT-SIGNATURE` | 客户端到服务器 | 与所提供 `PaymentRequirements` 之一匹配的已签名 `PaymentPayload` | | `PAYMENT-RESPONSE` | 服务器到客户端 | 确认结算完成的 Base64 编码 `SettlementResponse` | 将协商过程放在请求头中，正是 x402 能够改造现有系统的原因。你可以在现有端点前面加入 x402，而无需改变该端点与内部非付费调用方之间已经建立的契约。 ## 402 响应内部是什么样的 `PaymentRequired` 对象的结构小而固定。在 v2 中，`x402Version` 必须为 2。`error` 是可选字段，用于解释请求被拒绝的原因。`resource` 是描述所售内容的 `ResourceInfo` 对象。`accepts` 是 `PaymentRequirements` 数组，`extensions` 为可选字段。 每个 `PaymentRequirements` 条目都包含 `scheme`、采用 CAIP-2 格式的 `network`、以代币最小单位字符串表示的 `amount`、代币合约地址或 ISO 4217 代码形式的 `asset`、`payTo`、`maxTimeoutSeconds`，以及可选的 `extra`。 ```json { "x402Version": 2, "error": "Payment required to access this resource", "resource": { "url": "api.example.com/v1/forecast", "description": "Single forecast query", "mimeType": "application/json" }, "accepts": [ { "scheme": "exact", "network": "eip155:84532", "amount": "1000", "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "payTo": "0x1234567890AbcdEF1234567890aBcdef12345678", "maxTimeoutSeconds": 60 } ] } ``` 由于 `accepts` 是一个数组，服务器可以同时公布多种付款方式----不同网络、不同资产或不同方案----然后由客户端选择其钱包和 facilitator 都支持的方式。这种协商是 x402 最接近结账页面的部分。 ## 支付方案与网络 方案定义了付款的语义：对于这笔交易来说，"付款"究竟意味着什么。方案被设计为可扩展，因此协议可以增加新的付款行为，而无需推出新的协议版本。 首个发布的方案是 `exact`：转账一笔明确的固定金额。这适用于端点按次收取固定费用的常见场景。在 EVM 链上，`exact` 通过 EIP-3009 `transferWithAuthorization` 实现，从而支持免 Gas 的 ERC-20 转账----付款方只需签署授权，而不必提交并支付自己的交易。这些签名遵循 EIP-712，因此钱包可以用人类可读的形式展示授权内容，而不是显示不透明的十六进制字符串。 理论上的 `upto` 方案可以根据实际消耗的资源，转账不超过指定上限的金额。这与 LLM 推理非常匹配，因为生成完成前你并不知道代币数量。任何构建过[基于模型封装器的计量计费](https://dodopayments.com/blogs/metered-billing-gpt-wrapper)的人都会理解这个问题：价格取决于输出，而不是输入。协议设计空间中还存在延迟结算方向，让验证和结算在时间上进一步分离。 在网络方面，x402 与具体链无关。网络使用 CAIP-2 格式标识，例如 `eip155:84532`，协议可跨 EVM 链和 Solana 运行。实际应用中最常见的资产是 USDC，但卖方可以接受 EVM 上的任意 ERC-20，或 Solana 上的任意 SPL 代币。 这一切都有一个硬性约束：客户端和 facilitator 必须同时支持相同的 `(scheme, network)` 组合。服务器可以公布任意数量的组合，但只有当客户端能力与 facilitator 能力重叠时，付款才能完成。规划 `accepts` 数组时，应围绕这种重叠来设计，而不是围绕你希望得到的支持范围。 发现功能由单独的层负责。"Bazaar"发现层让买方能够找到可用的 x402 服务，而不要求每个代理事先知道哪些端点接受付款。这一点比听起来更重要：没有目录的支付通道，只能在双方已经找到彼此的情况下发挥作用。 ## Facilitator 究竟做什么 要自行运行链基础设施来接受付款，会带来真实的工程负担。你需要 RPC 访问、nonce 管理、结算监控以及链重组处理。Facilitator 的存在，就是让资源服务器可以跳过这些工作。 Facilitator 向卖方提供两个重要端点： - `/verify`：服务器 POST 客户端的付款载荷，并获得付款是否有效且能够结算的判断结果。 - `/settle`：服务器请求 facilitator 实际执行结算，并返回 `SettlementResponse`。 将验证与结算拆分开，服务器就可以安全地执行成本较高的工作：先验证，再生成响应，最后结算。如果工作失败，资金还没有转移。 Coinbase Developer Platform 提供托管式 facilitator。它支持 Base、Polygon、Arbitrum、World 和 Solana 上的 ERC-20 付款：USDC 和 EURC 使用 EIP-3009，任意 ERC-20 使用 Permit2。定价为每月 1,000 笔交易的免费额度，之后每笔交易 $0.001。 正是这项按交易收取的费用，让 x402 对微支付很有吸引力。每次结算只需十分之一美分时，按 API 调用收取几分之一美分在算术上是可行的；而对于银行卡通道，交换费中的固定部分会为合理的最小交易金额设置硬性下限。如果你曾尝试以真正小额的增量[收取 API 访问费用](https://dodopayments.com/blogs/charge-for-api-access)，就会遇到这个下限。 ## x402 与传统银行卡通道的对比 这两者并不是同一种产品。进行比较的主要价值，在于明确各自究竟解决了什么问题。 | 维度 | x402 | 传统银行卡通道 | | ------------------ | -------------------------- | ---------------------------------- | | 结算 | 链上以稳定币结算，几乎即时 | 以法定货币批量结算，存在结算延迟 | | 可行的最小支付金额 | 可低至几分之一美分 | 受每笔交易固定费用限制 | | 拒付 | 没有拒付机制 | 持卡人拥有争议和拒付权利 | | 税务处理 | 协议不涉及 | 由商户、PSP 或 MoR（名义商户）处理 | | 交易对手 | 可以是拥有钱包的自主代理 | 假设是已识别的人类或企业账户 | | 最适用场景 | 机器对机器的按请求付款 | 人类的周期性订阅和一次性购买 | 应将这张表理解为分工，而不是排行榜。银行卡通道提供消费者保护、税务基础设施以及付款方的法律身份。x402 则移除所有这些内容，让交易成本低到机器可以按次付款。每项取舍都是有意为之。 这里更广泛的变化，就是人们谈论[代理式商业](https://dodopayments.com/blogs/agentic-commerce)时所指的内容：软件代表自己进行交易，而不是作为人类已保存凭据的前端。x402 是这一世界在支付层面的一种具体尝试，同时也与关于[买方变成代理后计费如何变化](https://dodopayments.com/blogs/agentic-billing)的更广泛问题并行存在。 ## x402 在 AI 产品计费栈中的位置 这里是大多数 x402 文章都会略过的部分：AI 产品几乎从来不只有一种买方。 你既有按请求调用的代理，也有按月付费的人类用户。这两种收入流的要求不同，现实中也需要不同的支付通道。 x402 很适合处理第一种情况：按请求、低于一美分、无需入驻、以稳定币结算，并且可以在从未见过面的双方之间运行。如果你的产品是供其他机器使用的 API，这种匹配度很高；它可以补充更广泛的 [API 变现策略](https://dodopayments.com/blogs/api-monetization)，而不是取代它。 但它完全不处理第二种情况，而且它本来也不是为此设计的。x402 不涉及： - MoR（名义商户）职责，以及谁是交易的法定记录卖方。 - 间接税：VAT、GST 和销售税的计算、收取与申报缴纳。 - 拒付和争议处理。 - 财务团队可以对账的发票和收据。 - 向银行账户发放法定货币。 这些并不是协议遗漏的内容，而只是超出了支付握手的范围。无论由哪种通道完成资金结算，它们仍然是你的责任。 直说吧：Dodo Payments 不实现 x402。我们负责的是计费栈的另一半。Dodo Payments 是一家 [MoR（名义商户）](https://dodopayments.com/payments/merchant-of-record)，这意味着我们会成为你交易的法定卖方，并负责覆盖 190 多个国家/地区的税务合规、开票和分析。定价为美国境内交易 4% + 40 美分，国际交易另加 1.5%，订阅另加 0.5%，没有固定月费。我们支持 40 多种支付方式、80 多种货币，以及 220 多个国家和地区。 在计量方面，我们内置了[按用量计费](https://dodopayments.com/billing/usage-based-billing)。因此，如果你的产品按代币、调用次数或计算资源收费，而不是按席位收费，计量和发票就可以集中在一个地方。如果你还在选择计费模式，可以参考我们的 [SaaS 按用量计费指南](https://dodopayments.com/blogs/usage-based-billing-saas)以及更具实操性的[按用量计费实现教程](https://dodopayments.com/blogs/implement-usage-based-billing)。 还有一个值得指出的相邻领域。Dodo 发布了面向 AI 代理的 [MCP 服务器](https://docs.dodopayments.com/developer-resources/mcp-server)，因此代理可以通过与其他操作相同的协议层来使用计费操作；我们还为调用 API 的编码代理提供 agent skills。这是对代理式工作流的协议层支持，但它不是 x402，我们不会假装两者相同。 如今，大多数 AI 公司的诚实架构是并行运行两条通道：一条类似 x402 的代理支付通道，用于机器对机器的微支付；另一条带有 MoR（名义商户）覆盖的法定货币计费通道，用于每月向你付款的人类客户。选择[AI 计费平台](https://dodopayments.com/blogs/ai-billing-platforms)，实际上是在选择第二条通道，而不是第一条。 ## 在基于 x402 构建前需要了解的限制 这些都不是避开 x402 的理由，而是你需要在产品进入生产环境前准备好答案的问题。 **稳定币风险敞口。**结算使用代币，而不是法定货币。你现在持有的是稳定币余额，并且需要负责后续的兑换、资金管理和会计流程。我们的[稳定币支付指南](https://dodopayments.com/blogs/stablecoin-payments-guide)介绍了相关运营问题，[SaaS 加密支付](https://dodopayments.com/blogs/crypto-saas-payments-2026)文章则分析了它对软件企业在哪些情况下有意义、哪些情况下没有意义。 **没有拒付机制。**一旦结算，就已经完成结算。这对卖方的收入确定性非常有利，但也意味着你无法向买方提供银行卡所能提供的追索权。对于代理之间的流量，这通常没有问题；但对于面向消费者的交易，这是一个明显缺口。 **税务和 MoR（名义商户）职责仍由你承担。**协议负责转移价值，但不会判断供应发生地、计算正确的 VAT 税率、申报纳税或开具合规发票。如果你不清楚这些意味着什么，可以先了解[MoR（名义商户）究竟做什么](https://dodopayments.com/blogs/what-is-a-merchant-of-record)。 **钱包体验。**客户端需要一个有资金的钱包以及签名方式。EIP-712 让签名更易读，这会有所帮助，但你仍然要求付款方持有并管理密钥。对于自主代理，这是一个已经解决的配置问题；但对于首次购买的人类客户来说，与输入银行卡相比，这是一种额外摩擦。 **方案与网络支持矩阵。**由于付款只有在客户端和 facilitator 同时支持相同 `(scheme, network)` 组合时才能成功，因此你公布的 `accepts` 数组实际上是在押注买方拥有的组合。范围过窄会失去付款方；公布 facilitator 无法结算的组合，则会在完成工作后于 `/settle` 步骤失败。 **协议成熟度。**除 `exact` 之外的方案仍在发展，重放保护和信任最小化也是规范中明确的持续关注点，而这一标准本身还很年轻。构建时应预期其接口会发生变化。如果你希望自己的集成保持灵活，我们的[集成指南](https://docs.dodopayments.com/developer-resources/integration-guide)可以作为一个合理范例：将支付通道隔离在稳定的内部接口之后。 ## 常见问题 ### 用简单的话说，x402 协议是什么？ x402 是一种开放支付标准，使用 HTTP 402"Payment Required"状态码，让客户端无需账户、API 密钥或订阅即可为单次请求付款。服务器会向未付款请求返回付款说明，客户端则附带已签名的付款信息重试请求。 ### 使用 x402 需要加密钱包吗？ 需要。客户端必须在支持的网络上持有支持的资产（最常见的是 USDC），并通过钱包完成签名。对于已经配置好的自主代理来说，这很简单；但与输入银行卡相比，首次使用的人类客户会遇到明显摩擦。 ### x402 可以取代现有的订阅计费吗？ 不可以。x402 处理机器对机器的按请求付款，不提供订阅、开票、间接税、拒付或法定货币提现机制。大多数 AI 产品会让 x402 与法定货币计费通道并行运行，而不是用 x402 取代后者。 ### x402 facilitator 做什么？ Facilitator 通过 `/verify` 端点验证付款载荷，并通过 `/settle` 端点执行结算，因此资源服务器无需自行运行链基础设施。Coinbase Developer Platform 运营着一个托管式 facilitator，每月前 1,000 笔交易免费，之后每笔交易收费 $0.001。 ### Dodo Payments 支持 x402 协议吗？ Dodo Payments 不实现 x402。Dodo Payments 是一家 MoR（名义商户），负责法定货币支付、覆盖 190 多个国家/地区的税务合规、开票和按用量计费，并提供 MCP 服务器，让 AI 代理可以直接操作计费功能。 ## 最终结论 x402 为一个具体且真实的问题提供了简洁的解决方案：机器需要为单次请求付款，而流程中没有人类来签署合同或管理 API 密钥。重新启用 HTTP 402、将协商完全放在请求头中，以及分离验证和结算，都是合理的工程决策。Facilitator 模式也为卖方移除了大部分基础设施负担。 但它不是计费系统。它只是在两个已经就金额达成一致的主体之间转移价值。它不会告诉你是否需要在德国缴纳 VAT，不会生成客户财务团队认可的发票，也不会把稳定币兑换到你的运营账户。 如果你正在发布供代理使用的 API，那么趁每次结算成本仍然很低，现在值得对 x402 进行原型验证。如果你还将产品按月销售给人类客户，那么底层仍然需要另一条通道。这正是 [Dodo Payments](https://dodopayments.com/pricing) 所处理的层，而[开发者文档](https://docs.dodopayments.com)是了解两者如何配合的最快方式。 --- - [More AI articles](https://dodopayments.com/blogs/category/ai) - [All articles](https://dodopayments.com/blogs)