Coinbase 在前几天公布了新的支付协议：x402。由于 x402 由 coinbase 发起，所以理所当然的支持 base sepolia，并且默认可用。并且已经对 Solana 链提供了支持，证明了 x402 并不绑定某个链。

https://github.com/coinbase/x402

为了弄清楚流程，我新建了一个仓库（https://github.com/gin-lsl/x402-solana-demo），里面包含全部的 Server、Client 和 Facilitator。这里选择 Koa 作为基础框架，实现 client 能够通过支付 Devnet 的 USDC（自定义的 Token），获取服务器提供的某个接口的访问权限。

一些说明

首先我使用 spl-token 工具创建了相应的 token，可以在这里看到 https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

这里选择 Solana 是因为这条链对开发者很友好，几乎提供了无限量的测试代币供所有人开发和测试，它不设置任何门槛，不需要登录、不需要绑定任何社交账号、不需要钱包在主网上有余额。

如果需要运行项目，需要创建一个 .env 并填写所需的环境变量，然后在终端启动服务器并运行客户端代码：

代码解释

由于只是作为演示所用，所以仅仅是简单的将它们放在了同一个地方。下面是一些主要的文件说明：

 

solana.ts

它提供了一个「 /solana/get-balance 」接口，我们假设这是一个很有价值的接口，调用它需要支付一小笔钱。作为 Server 的角色，对应序列图中 (5) ~ (8) 部分，更深入地说，是其中的 (7)。

 

通常 Server 只涉及到业务需求的处理，不需要涉及到链上交易等逻辑。所以，如果某个系统的开发人员不懂 Web3，也能够在尽量不改动自己的业务代码的前提下，接入 Web3 的支付方式。

 

facilitator.ts

它实现了 Facilitator 的能力，主要是提供了 /supported, /verify, /settle 接口，分别用于查询当前支持的链、验证交易数据以及上链结算能力。这里是与链交互的地方，它需要私钥以便能够支付链上交易的费用。它在架构上是独立于 Server（也就是 solana.ts）的，对应序列图中的 (9) 和 (10)；

 

哪怕你决定自己提供 Facilitator 服务，这部分的代码实际上也是标准化的，基本可以直接使用官方提供的模式而不需要自行实现。不过目前官方只对 base 有完整的支持，如果想要使用其他链，则需要一些适配工作。其中主要是需要将模拟交易发送到链上来验证交易（如果是「 x402 」已经支持的链，则可以直接调用 verify 函数），以及将交易正式提交到链上并等待交易最终确认（如果是「 x402 」已经支持的链，则可以直接调用 settle 函数）。

 

对于 Solana 链来说，在请求走到 POST /settle 后，调用了「 x402/facilitator 」中的 settle 函数，里面经过一些验证后，调用了 rpc 上的 sendTransaction 发送交易，然后通过 waitForRecentTransactionConfirmation 等待并确认交易结果，所涉及到的代码通过 @solana/kit 提供。EVM 部分也是类似的逻辑。

 

x402-middleware.ts

用于将 Server 和 Facilitator 关联起来，它作为一个 Koa 中间件，能守卫需要付款才能调用的接口，代码参考了官方提供的「 x402-express 」。作用是自动返回 402 状态、转发 /verify 和 /settle 请求；

 

我在这部分的代码实际上只是在拼装各种参数，并将其转发给 facilitator 或返回给客户端。为了方便测试，避免涉及太多细节，我将大部分参数写成了固定值。其中包括：

• 将 maxAmountRequired 设置的非常大，这个值实际上在 client 中会被校验，如果用户需要支付的金额高于它，则直接会抛出异常。
• 将 asset 设置为了我们自己创建的 Token: 9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo，而不是 x402 中内置的 Token 地址。在主网，它应该是 USDC 官方的地址。

 

有意思的是，x402-express 通过重写 Response 上的函数，实现了类似 Koa 的洋葱模型。所以在他们对 express 提供的中间件中，实际流程是 verify -> 业务逻辑 -> settle。提交上链是在执行业务逻辑之后进行的，这确实符合上面的序列图。在 Koa 中实现这个逻辑非常简单，Express 中则需要一些额外的代码，这可能也是他们优先提供了 express 中间件的原因吧。

 

payment-client-fetch.ts

充当客户端角色，对服务器发起请求，对应流程图中 1 ~ 4。其中使用了「 x402-fetch 」提供的帮助函数，自动处理 402 状态、使用客户端钱包的私钥生成签名并重新发送等；

 

它会尝试直接请求接口，遇到 402 错误后，会读取返回的内容（里面应该包含服务器支持的 x402 版本，目前固定为 1, 以及服务器需要的必填参数），通过你的私钥对交易签名，然后将交易信息序列化后通过 X-PAYMENT Header 再次发送到原 url。

 

了解项目的基本结构后，我们可以通过以下命令运行 Server 和 Client：

客户端的执行结果及日志：

思考

个人认为，如果说 Web3 开发者们之前所做的努力，是为了降低普通用户使用 Web3 的门槛，让最终用户能够更方便的使用 Web3 的生态（支付、投资等）。那么现在的 x402，则是为了能够降低 Web2 开发者们接入 Web3 支付渠道的门槛而诞生的。

x402/client 部分提供的帮助函数虽然有用，但也只是做了它应该做的事情。现在用户能够通过钱包支付 USDC 等，实际上已经很方便了。所以相对来说，x402 对于开发者和服务提供方的意义可能更大。

但是 x402 真正大范围应用依然会遇到很多问题。一些大型公司内部会有结算系统，在如何对接新的标准方面，会有自己的态度和节奏，想要将一个新的支付方式集成到自己现有的系统中，必然还需要很远的路要走。并且大型公司在对接支付时，必然要考虑监管方面的影响，这也可能会导致他们不得不放弃更加方便的支付方式，依旧使用流程复杂的传统方案。

也许 Node RPC 提供方会对它更加青睐，RPC 提供方除了提供基础接口，还会提供许多 Advance API、交易加速接口等，这部分如果能通过 x402 提供，也许能让更多人体验他们的服务。

最后请注意，x420 本身只是一个基础的支付协议，它的意义是提出了一套规范的技术标准，而有了公认的标准后，则能更方便的让开发者和各个大中小型公司一起针对标准完善整个生态。我们应该理性的看待新标准的提出，避免陷入炒作者们的叙事陷阱中。

本文由 ZAN Team（X 账号 @zan_team）撰写。