HTTP 协议中有一些状态码为开发者所熟知：200 表示成功，404 表示未找到，500 表示服务器内部错误。但有一个状态码——402 Payment Required——自 HTTP 1.0 时代便被预留，却在长达二十余年的时间里未被广泛使用。它的语义明确而直接：请求的资源需要付费。PayGo 所做的工作，是将这个长期处于“预留”状态的 402 状态码，变成一套可实际运行的请求级结算方案。

PayGo 对 402 的使用方式并不复杂。当一个客户端请求某项付费资源时，服务端若未检测到有效的支付凭证，便返回 402 状态码，并在响应中附带报价信息，包括价格金额、计价币种、收款地址以及后续验证所需的字段。客户端收到 402 响应后，按照报价内容完成链上支付，随后将支付凭证附在原请求中重试。服务端对凭证进行验证，确认支付有效后返回 200 状态码及所请求的资源。整个交互过程在一次 HTTP 请求与响应的闭环中完成，支付不再是一个需要跳出或等待的外部动作，而是协议交互的自然环节。这一设计使得机器与机器之间的调用可以在无需人工介入的前提下完成支付与结算。

对于服务方而言，将现有 API 接口升级为支持 402 付费的端点，PayGo 提供了 Server SDK 作为接入工具。根据资料，该 SDK 封装了按次或按量的定价配置、402 响应模板的自动生成、支付凭证校验以及防重放保护与限流等功能。服务方引入 SDK 后，无需自行处理链上交易查询或支付验证逻辑，即可使接口具备按请求计费的能力。目前 SDK 的语言支持以 Node.js/TypeScript 为首发，Go 与 Java/Spring 处于规划阶段。调用方一侧则有 Client SDK，负责识别 402 响应并解析报价、执行链上支付、将支付凭证携带于重试请求中，同时提供预算控制功能以设定支出上限。在钱包适配方面，Client SDK 兼容浏览器插件钱包、服务端钱包及面向 Agent 场景的专用钱包三种形态。

PayGo 架构中设有一个独立的验证组件 Facilitator，其职责聚焦于凭证层面的协调与校验，包括报价结构化、凭证标准化、校验结果缓存与防重放攻击拦截。Facilitator 在设计上有一个明确的边界：不托管资金。调用方支付的稳定币资产直接进入服务方地址，Facilitator 不持有、不中转任何结算款项，验证服务与资金托管在架构上彼此分离。在结算资产方面，PayGo 采取 USDT/USDC First 策略，优先支持这两种稳定币作为支付与计价单位，服务方收取的款项为链上稳定币，对账直观且价值稳定。PayGo 协议设有原生代币，但其职能被定位为治理与安全工具，不承担支付或计价职能，协议代币的经济模型与服务方的商业收入彼此独立。

此外，PayGo 在架构中设置了 Agent/MCP Adapter 组件，目标是为 MCP 工具服务器提供机器可读的报价格式与可验证的结算结果，推动形成“AI 可购买工具”的开放市场。这一组件为请求级结算在智能体自主调用工具的场景中预留了标准化的接口层。

PayGo 的实践本质上是对 HTTP 402 状态码的一次工程化兑现。它没有停留在协议定义的讨论阶段，而是通过 Server SDK、Client SDK、Facilitator 及 Agent/MCP Adapter 等组件，将 402 从一行规范文本变成一套可供服务方直接使用的工具链。对于希望将 API 或工具升级为按请求计费模式、又不愿在支付系统上投入过多自研资源的服务方而言，这套方案提供了一种相对完整的参考实现。

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。