一个沉睡近30年的状态码，被AI支付叫醒了……

文丨张盒子

出品丨支付之家 · 深度

互联网里有很多状态码。

404人人都见过，401、403也经常出现在权限和登录场景中。但有一个状态码，在标准文本里沉睡了近30年，长期没有真正走到互联网商业化的前台。

它就是HTTP 402 Payment Required。

现在，这个老状态码被AI支付重新叫醒了。

原因并不复杂，AI可能不是先学会赚钱，而是先学会花钱。

当AI智能体不再只是回答问题，而是开始替用户执行任务，支付问题就会被重新摆到台前。它要调用API、购买数据、使用MCP工具、生成图片视频、请求其他智能体服务。

每一次调用背后，都可能对应一次资源消耗，也可能对应一笔费用。

“机器”怎么付款？

这里需要补充一下，“机器”并不是指某一台具体设备，而是指AI智能体、自动化程序、API客户端等非人工请求方。

互联网其实很早就给这个问题留过一个位置。

这个位置，就是HTTP 402 Payment Required。

HTTP 402的含义很直白：付款要求。它不是一个完整支付协议，而是HTTP状态码。

早在1997年发布的HTTP/1.1早期规范RFC 2068中，402 Payment Required就已经被列出，并被标注为“reserved for future use”。

到了现代HTTP语义规范RFC 9110中，402仍然延续这一基本定位，也就是为未来用途保留。

它不像404那样成为互联网用户熟悉的错误提示，也不像401、403那样进入身份认证和权限管理的日常场景。很长时间里，402更像一个被放在标准文本里的空位。

互联网知道资源访问可能需要付款，但并没有形成一套通用商业路径。

402不是突然出现的新技术，它更像互联网早年“资源访问即付款”理想留下的接口。

互联网早就想过“访问即付费”

今天讨论HTTP 402，不能只从一个状态码讲起。

它背后站着一段早期互联网支付史。

1990年代，互联网刚进入商业化阶段，网页、电子现金、数字内容和微支付都曾被寄予很高期待。

那时的设想很简单：用户读一篇文章、下载一个文件、访问一次数据库、使用一次在线服务，只要金额足够低、流程足够轻，就可能形成新的商业模式。

在广告平台、超级App、应用商店和成熟收银台还没有接管互联网之前，很多人相信，数字内容和在线服务可以像水电一样按次、按量收费。每一次访问都有价格，每一次点击都可能是一笔小额交易。

HTTP 402就是在这样的想象中显得合理。服务器告诉客户端，想访问这个资源，需要先付款。

W3C在1995年已有Micro Payment Transfer Protocol工作草案，试图通过共同经纪方处理小额支付，让小额付款适合互动应用。

1999年前后，W3C又有过Micropayment Markup等相关探索，希望把初始化微支付所需的信息嵌入网页。

DigiCash、CyberCash、First Virtual等早期电子现金或微支付探索，也曾参与过这条路径，试图为互联网提供更轻的付款方式。

但这些尝试最终没有让小额网络支付成为主流。

那一代创业者和技术机构想解决的问题，与今天讨论402时面对的问题有相似之处：数字资源可以被定价，网络访问可以触发付款，交易不一定总要先进入传统收银台。

所以，402不是孤零零的状态码。它背后对应的是早期互联网的一种商业理想——网页、内容、数据和服务，都可以在访问时完成付款。

但后来的互联网没有沿着这条路走下去。

“微支付”没有成为主流

从结果看，402沉睡并不是支付需求消失，而是“访问即付费”没有成为主流路径。收银台、广告、订阅、平台账户和API月结账单，成为更现实的互联网商业化方式。

早期微支付最先面对的是人。

几分钱、几毛钱看起来不贵，但每一次确认都会消耗用户注意力。用户可以接受每月订阅，也可以接受看广告换取免费内容，却很难接受每一次点击都像一次结账。

人不怕花几分钱，人怕每次都被打断。

商户也不愿意处理碎片化小账。一笔几分钱的交易，也要记录、对账、退款、客服、税务和系统维护。单笔金额越小，单位处理成本越敏感。交易金额可以很小，交易责任不会因此变小。

更现实的商业模式很快胜出。

电商平台没有把每一次网页访问都变成付款请求，而是把支付放进订单流程。用户先选商品，再进入收银台，支付成为交易闭环中的一个环节。互联网没有放弃支付，而是把支付从协议层推到了收银台。

内容行业也没有普遍走向“单篇微支付”。广告把用户注意力变成收入，订阅把零散访问打包成周期付费，平台账户把支付封装在更大的生态内。内容付费没有消失，但它没有沿着402想象中的按次访问路径发展。

API经济同样如此。

API早就收费，只是收费方式长期围绕账号和账单，而不是围绕单次HTTP请求。开发者注册账号，申请API Key，绑定付款方式，购买套餐，按量统计，月度结算。对企业客户和开发者来说，这套流程虽然偏重，但可以接受。

互联网早期曾经想让“访问即付费”成为一条路，但后来的商业世界选择了更容易规模化、更适合用户习惯和商户经营的路径。

收银台赢了，402继续等待。

Web支付继续演进，但主角仍然是人

互联网支付没有停止标准化探索。

后来，浏览器、商户网站和支付服务商一直在试图让用户付款更顺畅。W3C Web Payments、Payment Request API等方向，核心目标都是降低网页支付的接入和使用成本，让浏览器、商户与支付方式之间更好协同。

但这些努力大多仍然围绕人展开。

人看见订单，人选择支付方式，人确认付款。

无论是银行卡、钱包、浏览器支付接口，还是电商收银台，主角仍然是人类用户。支付体验被优化了，但付款动作依然发生在页面、App和收银台里。

402路径的差异在于，它不是继续优化人的收银台，而是把付款要求放进资源访问过程。

过去的Web支付，重点是让人更顺畅地付款；智能体时代的402，重点是让机器读懂价格、提交付款、获得资源。

也正因为过去的支付体系主要围绕人设计，当智能体开始成为任务执行者，旧问题才以新方式重新出现。

如果访问资源的不再是人，而是机器，付款流程还要不要继续围绕收银台展开？

AI让微支付换了对象

早期微支付失败，很大程度上是因为它让人频繁为小额资源付款。

人会犹豫，会嫌麻烦，会觉得几分钱确认一次不值得。

AI智能体改变了这个前提。

机器不会因为“点击一次太麻烦”而反感流程，但机器需要清晰的价格、权限、预算和回执。它要知道付多少钱，付给谁，用什么方式付，付款后获得什么，是否符合用户授权，是否超过预算。

AI不是重新发明微支付，而是把微支付的对象从“人点击网页”换成了“机器调用资源”。

这是理解HTTP 402重新被关注的关键。

一个智能体可能调用搜索API，查询企业数据，访问风控评分，使用MCP工具，生成一张图片，完成一次模型推理，或者请求另一个智能体执行子任务。这些调用有几个共同特征：单次金额可能不高，调用频次可能很高，服务结果可以计量，交付过程可以自动化，交易记录可以留痕。

人不适合为每一次点击付款，机器却适合为每一次调用计账。

早期微支付等不到用户习惯，402等到了智能体调用。

HTTP 402等来的不是网页微支付，而是机器资源计费。

x402把402从状态码变成流程

402本身只是状态码。

严格说，HTTP 402是状态码，x402是围绕这个状态码形成的一种代表性实现。本文讨论的“402路径”，指的是把付款要求嵌入资源访问流程的这一类思路。

真正让402重新进入产业视野的，是围绕它形成的新协议和新实现，最典型的是x402。

Coinbase在2025年5月推出x402，称其为一种让API、应用和AI智能体通过HTTP直接完成即时稳定币支付的支付协议。

随后，Cloudflare、Stripe、Circle等机构围绕x402推出或接入相关能力，AWS等云服务生态也开始把智能体支付纳入企业智能体和云服务讨论中。

2026年4月，Linux Foundation宣布成立x402 Foundation，并接收Coinbase贡献的x402协议，将其置于开放治理框架下。

x402做的事情，是给402补上了一套能执行的支付流程。

智能体请求一个付费资源，服务器返回402 Payment Required，同时给出金额、币种、收款方和付款方案。客户端根据要求生成付款授权，再带着凭证重新请求。服务端或facilitator验证付款，验证通过后放行资源。

过去402只能说“需要付款”，x402试图说明付多少、怎么付、谁验证、何时放行资源。

它不是多了一个付款按钮，而是让付款进入资源访问流程。

402真正重要的地方，不是重新定义一种支付工具，而是重新定义付款发生的位置。过去付款大多发生在收银台、App和支付页面，402路径则把付款推进到资源请求、工具调用和机器协作过程中。

过去支付发生在页面上，未来一部分支付会发生在调用里。

402更适合资源调用付款

402不是AI替人买东西的第一答案，而是AI为一次资源调用付款的更直接路径。

它最先成熟的地方，大概率不是普通消费者购物，而是API、MCP、数据接口、AI内容生成和机器服务。

API、MCP工具、AI内容生成、专业数据访问和智能体协作，都是402路径更容易先跑通的场景。它们有一个共同点：服务可以被清楚计量，结果可以被自动交付，付款可以和一次调用对应起来。

搜索、数据查询、模型推理、合规核验、风控评分、企业信息查询，都可能从套餐和月结之外，增加更细颗粒度的调用计费。生成一张图片、一次音频、一段视频、一次文本处理，本质上都是资源消耗，也可以成为一次计费单元。

不是所有数据都适合订阅，有些数据只需要被调用一次。企业信息、市场数据、风险名单、研究报告，如果每次调用都能定价、付款、回执，资源服务商就有新的商业化方式。

更远一点看，智能体之间的协作，可能同时也是智能体之间的交易。一个智能体调用另一个智能体的能力，一个自动化服务购买另一个服务的结果，机器对机器服务交易会自然产生付款需求。

402的吸引力，在于让一次性资源访问不必先变成长期账户关系。

过去，API和数据服务往往要先把用户纳入账号体系，再通过Key、套餐和账单实现收费。402路径提供了另一种可能：资源先被请求，价格随请求返回，付款完成后再放行资源。

这对长期服务关系不是替代，对临时调用、低频调用、跨平台调用却有价值。

402不能替代收银台

402的价值很清楚，边界也同样清楚。

它更像智能体经济中的资源计费协议，不是银行卡、钱包、收单和清算体系的替代品。

普通电商交易不只是一笔付款，还涉及订单、库存、地址、物流、退换货、发票、客服和平台规则。402可以处理付款要求，但处理不了完整订单履约。

线下支付也不是一次资源访问，而是一整套受理、清算和责任体系。商户管理、终端受理、用户确认、交易凭证、清算对账、投诉处理、收单合规，都不是一个HTTP状态码能够覆盖的内容。

大额交易、金融产品购买和跨境资金服务还涉及身份核验、适当性、反洗钱、外汇、税务和监管报备。一条HTTP付款路径，不能替代支付业务里的全部制度安排。

对中国市场而言，402和x402的技术逻辑可以观察，但当前国际实践中常见的稳定币结算、链上钱包和跨境资金安排，不能直接等同于境内可推广的支付产品。

在国内语境下，402更应关注协议思想和资源计费逻辑，而不是简单照搬稳定币收付路径。

技术可以把付款做轻，合规不会因此变轻。

支付行业不能只看技术跑通

402路径越接近真实资金流，越需要回答支付行业熟悉的问题。

对支付行业来说，402的关键不在于机器能不能完成付款，而在于付款动作被自动化之后，原本由人、商户和支付机构共同承担的责任如何重新分配。

授权边界：AI凭什么付款？

用户授权的是单次付款、单个任务、固定额度，还是长期授权？智能体支付的第一道问题，不是怎么扣款，而是谁授权它扣款。

限额管理：机器能花多少钱？

单次多少钱，每天多少钱，一个任务最多花多少钱，一个工具最多调用多少次，超过金额是否需要人工确认。没有预算边界的智能体支付，本质上是在把支付风险自动化。

凭证验证：钱、资源和回执能否对上？

付款凭证是否有效，是否绑定具体资源、金额、商户、时间和请求上下文，是否会被复用或重放。支付行业最怕的不是流程复杂，而是钱、授权、资源和回执对不上。

交易风控：谁识别异常调用？

恶意MCP工具、虚假API、提示词注入、连续小额扣款、伪装服务商收款，都可能把智能体的自动执行能力变成资金损失。当付款从人点击按钮变成机器自动请求，风控必须前移到智能体决策之前。

合规约束：自动化不能绕过规则。

x402与稳定币、链上钱包结合后，会涉及稳定币监管、资金来源识别、制裁筛查、反洗钱、跨境资金流、商户准入和税务处理。越是跨境、自动化、小额高频，越不能忽视合规链路。

责任归属：机器付错钱之后谁负责？

付了钱没拿到服务，AI花错钱，工具恶意收费，服务质量不达标，重复扣款，退款争议，最终都要有人处理。机器能付款只是第一步，机器付错钱之后谁负责，才是支付行业真正关心的问题。

这些问题不是理论担忧。

已有研究对x402的安全问题进行分析，指出其把同步HTTP授权与异步区块链结算结合后，可能带来授权绑定、重放保护、Web层处理等攻击面，并造成“未付款获取服务”或“已付款但服务被拒”等结果。另有研究从交易原子性、上下文绑定、并发竞态等角度讨论x402生态中的逻辑缺陷和状态同步问题。

能跑通协议，不等于已经形成支付业务闭环。

机器支付越自动化，支付责任越不能后置。

支付机构不会被绕开

402降低了资源服务商表达付款要求的门槛，但没有消灭支付行业的责任。真实交易仍然需要准入、验证、风控、留痕、结算和争议处理。

402看似让资源服务商可以更直接地收费，但只要交易开始规模化，支付行业熟悉的准入、风控、清算、留痕、退款和争议处理就会重新回到中心。机器支付不是去支付机构化，而是把支付机构的能力推向更早的交易环节。

支付机构服务的对象，可能从传统商户和收银台，延伸到API、MCP工具、智能体平台和机器钱包。

它们可以做facilitator服务，帮助资源服务商验证付款、提交结算、返回回执；可以做智能体支付风控，识别智能体身份、工具风险、资源风险和调用异常；可以做预算和限额管理，为用户、企业和平台设置支付边界；也可以做商户和工具准入，对API、MCP工具、数据服务和智能体服务进行认证。

交易留痕、审计、合规结算、退款和争议处理，同样会成为机器支付时代的基础能力。

402不会让支付机构消失。

它会把支付服务从收银台延伸到API、MCP工具、智能体和机器钱包。未来支付机构不只服务商户，也可能服务工具、模型、数据接口和智能体。

对支付机构而言，智能体支付不是把原有收单能力简单搬到AI场景，而是要重新理解交易发生的位置。过去的交易入口在商户页面、收银台、POS和钱包App里；未来一部分交易入口会藏在工具调用、模型请求、数据查询和自动化任务中。

识别这些调用关系，把授权、限额、风控和回执接进去，支付机构才有机会在机器支付时代找到位置。

402在智能体支付版图中的位置

402路径不是智能体支付的全部。

银联APOP更关注智能体在卡组织和收单网络中的身份、意图、用户和授权管理；京东A2P2更关注平台生态内智能体自主支付的任务委托、运行环境和自主等级；Visa、Mastercard更关注在现有卡组织网络中让智能体使用受控支付能力；蚂蚁国际AMP更关注移动钱包、银行App、超级App与智能体服务连接。

相比之下，402和x402更靠近资源调用层，处理的是AI为一次资源访问付款的问题。

APOP、A2P2、卡组织方案更多处理AI替人消费；402更像解决AI为资源调用付款。

智能体支付不会只有一条路。

购物有购物的协议，资源调用有资源调用的协议，钱包和卡组织也会有自己的授权体系。

这恰恰说明，智能体支付已经开始分层。

一层是消费支付，解决AI替用户买商品、订服务、付账单时的授权、订单和履约问题。

一层是资源计费，解决AI调用API、MCP工具、数据接口、模型服务时如何按次付款。

还有一层是风险和责任，解决智能体身份、预算、留痕、风控、合规和争议处理问题。

402更靠近资源计费这一层。

它不是全部答案，但它补上了智能体支付版图里很关键的一块：机器调用数字资源时，如何识别价格、提交付款、获取服务。

机器成为新的付款发起方

HTTP 402等了近30年，等来的不是网页微支付的简单复活，而是交易发起方式的改变。

过去，互联网支付大多发生在页面、App和收银台。

而在智能体时代，支付开始嵌入API请求、MCP工具调用、模型推理与机器之间的协作过程。

变化的关键不在于“多了一种支付方式”，而在于付款动作的发起主体正在变化。

HTTP 402被重新叫醒，正是这一变化在资源调用层的信号。

AI开始自己花钱，并不意味着机器可以不受约束地付款。

智能体支付真正要解决的，也不只是“能不能付款”，而是机器凭什么付款、替谁付款、能花多少钱、谁来验证、出错由谁负责。

当支付从人的点击进入机器的调用，授权、风控、合规与责任边界，也必须同步前移。

HTTP 402被叫醒的真正含义并不是支付变了，而是——

交易的起点，从人，开始转向机器。

这里是支付之家。我们关注支付表象之下的规则差异与逻辑变化，提供支付科技领域增量信息。观点内容仅供参考。