如果一次支付发生在API调用的间隙，时长不过几百毫秒，那么围绕这次支付所发生的一切：报价、付款、验证、结算，都必须在这个时间窗口内完成。这对支付协议的设计提出了不同于传统支付的约束：流程必须足够轻量，响应必须足够迅速，中间环节必须足够精简。

PayGo提出的请求级结算，正是为这一场景而设计。本次盘点梳理了几个在机器支付领域进行探索的项目，不对比技术指标的优劣，而是观察一个更基础的问题：当支付被压缩进请求的间隙，不同协议在流程设计上做出了哪些不同的选择。

一、PayGo：把支付流程收敛为一次请求响应。PayGo的流程设计基于HTTP 402状态码。客户端请求资源，服务端在未收到有效支付凭证时返回402，并在响应中附带结构化的报价信息。客户端解析报价后自动完成链上支付，携带凭证重试原请求，服务端验证后返回资源。

这个流程的特点在于简洁。支付不需要跳转，不需要额外的会话保持，不需要在多个系统间传递状态。一次402响应加一次携带凭证的请求，支付即完成。对于调用方来说，402是一个可被程序自动处理的信号；对于服务方来说，402是一个标准化的收费入口。

在组件层面，Facilitator承担了流程中的验证工作——报价结构化、凭证标准化、校验缓存、防重放攻击，但不触碰资金。结算资产直接进入服务方地址。这一设计将验证与资金流转拆成两条并行的线，互不阻塞。

二、Google Cloud与Coinbase(AP2协议与x402轨道)：支付流程嵌入谷歌云Agent工作流，报价与支付通过Coinbase托管轨道完成，流程复杂度由云端基础设施消化。

三、Lightning Labs(L402协议)：基于闪电网络实现402支付，支付实时性依赖闪电网络节点的响应速度与通道状态。

四、Nevermined：支付作为AI服务计费的一环，流程涵盖计量、报价、支付、访问控制，侧重全链路管理。

五、Visa(Visa TAP)：在传统清算流程中增加代理身份验证环节，支付链路延续卡组织现有的授权与清算步骤。

当支付被置于请求的间隙，流程的简洁性本身就构成了协议的核心竞争力。PayGo的做法是将支付收敛为一次标准的HTTP交互——不需要额外会话、不设中间账户、不引入人工操作。这种流程上的收敛，是它在本次盘点中值得被关注的原因。