HTTP 402 重生：Web 原生支付协议技术解析

一、一个沉睡了近三十年的状态码

在 HTTP 状态码家族里，402 是一个特殊的存在。它在 HTTP/1.0 规范时代就被预留，语义为 Payment Required（需要付费），但规范从未定义其具体使用方式。此后近三十年，绝大多数 Web 服务从未真正返回过它，它长期处于“占位”状态。

要理解它的位置，可以先回顾状态码的分工逻辑：

• 2xx：请求成功，资源已返回；
• 3xx：重定向，资源换了位置；
• 401：未认证，服务器不知道你是谁；
• 403：已认证但无权限，知道你是谁，但你不被允许访问；
• 404：资源不存在；
• 402：语义上恰好卡在 401/403 之后——身份已经没问题了，差的是“钱”这一步。

换句话说，HTTP 的设计者很早就意识到，“访问控制”与“付费控制”是两件不同的事：前者解决“你是谁、能不能看”，后者解决“你付没付钱”。只是受限于当年的支付基础设施，402 一直停留在纸面上。

二、为什么是现在：402 复活的三个技术动因

一个预留状态码被重新启用并非偶然。近两年它重新进入开发者视野，背后有三个清晰的动因。

1. API 经济要求更细的计费粒度

Web 服务货币化的形态经历了从“卖软件”到“卖订阅”再到“卖调用”的演进。当服务能力以 API 形式输出时，最自然的计费单位是“一次调用”。但传统支付体系的最小结算粒度远大于此：一笔通道手续费、一次对账成本，都足以让“单次几分钱”的计费在财务上不成立。微支付需要一条手续费趋近于零、结算近乎实时的通道。

2. 智能体让“机器间自动付费”成为刚需

传统支付流程是为“人”设计的：注册账户、实名认证、绑卡、跳转收银台、确认支付。这些环节对人来说只是繁琐，对自动化程序来说几乎是不可逾越的障碍——大量支付条款要求本人操作，程序代付既不稳定也不合规。而自动化智能体的典型工作模式恰恰是：自主发现服务、评估成本、按需调用、即用即付。这要求付费动作本身必须是一个机器可自主完成、无人工介入、以请求为单位的原子操作。

3. 区块链补齐了最后一块基础设施

早期微支付尝试失败的关键原因，是缺少一个低成本、最终性强的结算层。链上稳定币与签名授权机制的出现，使“逐笔请求、逐笔结算、无需预先建立账户关系”在技术上成为可能：付款方用私钥签署支付授权，收款方验证签名并提交结算，全程无需人工确认。

三、协议核心交互流程

这类基于 402 的 Web 原生支付协议，设计哲学可以概括为一句话：把“付费”塞进 HTTP 本身的语义里，让标准的请求—响应循环天然承载一次商业交易。典型流程分五步：

1. 首次请求：客户端向付费资源发起普通请求；
2. 402 挑战：服务端不返回资源，而是返回 402，并在响应中附带结构化的“支付要求”，说明收多少钱、收给谁、接受什么资产、有效期多久；
3. 本地签名：客户端用私钥对支付凭证签名（或签署一笔链上授权），无需任何人工介入；
4. 携带凭证重试：客户端将签名凭证放入请求头，重新发起同样的请求；
5. 验证与放行：服务端校验签名、金额、有效期与防重放参数，提交结算并确认到账后，返回 200 与资源内容。

支付要求的数据结构是协议的关键，一个示意性定义如下（字段为通用示意，非任何具体实现）：

{
  "paymentRequired": {
    "amount": "0.01",
    "asset": "stablecoin",
    "payTo": "0x收款方地址",
    "network": "目标结算网络",
    "maxTimeoutSeconds": 60,
    "nonce": "b3f9c1...",
    "resource": "/api/summarize"
  }
}

客户端重试时，凭证以请求头形式携带：

GET /api/summarize HTTP/1.1
X-Payment: <Base64 编码的签名支付凭证>

服务端验证逻辑的伪代码骨架：

def handle_payment(request):
    proof = decode(request.headers["X-Payment"])
    # 1. 验签：确认凭证确实由付款方私钥生成，未被篡改
    assert verify_signature(proof)
    # 2. 核对业务要素：金额、收款方、资产与目标资源是否与本单一致
    assert match_payment_requirement(proof, pending_order)
    # 3. 防重放：nonce 未被使用过，且在有效期内
    assert proof.nonce not in used_nonces and not expired(proof)
    # 4. 提交结算并等待确认
    settle(proof)
    # 5. 标记 nonce，返回资源
    used_nonces.add(proof.nonce)
    return resource

还需注意错误语义的边界：402 表达“差一步付费”，而不是“没权限”。已付费但凭证无效，通常应返回 402 并附带失败原因；身份本身不合法，则应回到 401/403 的语义轨道。清晰的错误边界，是自动化客户端能否正确重试的前提。

四、与传统支付机制的本质区别

1. 账户体系：从“强账户”到“密钥即身份”

传统支付以账户为核心：开户、实名、绑卡、风控审查，双方必须先建立持久的账户关系。原生协议以密钥为核心：谁能用私钥完成有效签名，谁就是合法付款方，收款方无需知道对方是谁。账户关系被压缩为一次性的密码学验证，“陌生人之间按次交易”成为默认能力。

2. 结算时序：从“事前充值/事后账单”到“事中原子结算”

传统模式只有两种时序：预充值（先存钱后消费）或账单期（先消费后结算），两者都依赖账户余额或授信作为缓冲。原生协议实现了第三种时序：每笔请求独立结算，钱货两讫，不存在余额、账单、账期这些中间状态。对服务方而言，坏账风险在交付前已被消除。

3. 计费粒度：从“包月套餐”到“单次请求”

传统渠道的固定成本决定了计费粒度的下限，因此主流模式只能停留在订阅与套餐。当结算成本趋近于零，“一次调用、一条数据、一次推理”都可以成为独立计费单位，定价模型从“打包批发”走向“按用量零售”。

4. 信任机制：从“制度信任”到“密码学信任”

这是最本质的区别。传统支付的信任是制度性的：你相信银行不会挪用资金，相信清算机构会准确对账，相信平台会兑现退款承诺——每一层信任都对应一个中介机构，每笔交易在多个封闭账本间流转，需要事后对账弥合差异。原生协议的信任是密码学性的：签名不可伪造由非对称加密保证，账本不可篡改由共识机制保证，到账与否可通过公开状态确定性查询。信任验证从“依赖机构声誉 + 人工对账”变为“执行数学验证 + 程序自动确认”，成本从天级压缩到秒级，且验证过程对任何一方都是无差别的。

5. 集成成本：从“收银台工程”到“一个 HTTP 头”

对接传统支付通常意味着申请商户资质、集成 SDK、处理异步回调、维护对账系统。原生协议里，服务端本质上只是多处理一个状态码与一个请求头，客户端只需具备签名能力，集成面显著收窄。

五、信任变革的边界：必须正视的四个局限

1. 结算延迟与手续费波动：链上确认时间与费用并非恒定，高频小额场景需要做批量结算或聚合处理的工程权衡；
2. 交易不可逆：传统体系中的拒付、退单、争议仲裁机制被削弱，“先付款后交付”把更多风险转移给付款方，服务方的 SLA 与退款策略必须重新设计；
3. 合规不可绕过：反洗钱、税务、外汇管制等要求不会因技术形式变化而消失，面向真实用户的商业化仍需在协议之外叠加合规层；
4. 密钥管理责任前移：传统模式下账号被盗可挂失冻结，私钥模式下密钥即资产，客户端侧的安全存储与授权额度控制成为新的工程重点。

六、落地实践要点

服务端侧：

• 幂等与防重放：nonce 必须全局唯一且只能消费一次，验证与结算之间要处理并发竞态；
• 金额校验“以我为准”：以服务端生成的支付要求为准核对金额，不信任凭证中客户端声明的数字；
• 超时与有效期：支付要求应带 TTL，过期凭证直接拒绝，避免长期挂单造成价格套利；
• 明确的失败语义：为“凭证无效”“金额不足”“结算未确认”设计可区分的错误响应；
• 审计与对账：即便结算层自动化，业务层的订单、交付、异常记录仍需完整留存。

客户端与智能体侧：

• 预算控制：为自动付费行为设置单次与累计上限，防止循环调用导致资金损耗；
• 凭证生命周期管理：签名前先完整读取支付要求，校验收款方与金额后再签名，不做“盲签”；
• 密钥隔离：付费密钥应与身份凭据隔离，遵循最小授权原则。

七、结语

402 状态码近三十年的沉睡与苏醒，反映的是一条清晰的技术脉络：当网络的主要使用者从人扩展到机器，为“人”设计的支付与信任体系必然要被为“机器”设计的体系补充。把付费能力内嵌进 HTTP 语义、用密码学信任替代多层中介对账，这类 Web 原生支付协议给出的是一种新的默认选项，而非对传统支付的全面替代。对开发者而言，真正值得关注的不是某个具体协议的细节，而是它代表的三个方向：访问控制与付费控制正在分离，计费粒度正在逼近单次请求，信任验证正在从制度流程变成可以写进代码的确定性运算。这三条趋势，将直接影响下一阶段 API 服务与智能体应用的基础架构设计。