x402，支付巨头争什么？

“当机器开始替人选择服务和支付方式，支付竞争就不再止于处理一笔交易，而开始争夺一笔交易是如何被决定的。”

文丨张盒子

出品丨支付之家 · 深度

在《小径分岔的花园》中，博尔赫斯构造了一个不断分岔的世界，每一次选择，都通向另一条路径。

到了智能体时代，这种分岔开始进入真实交易。一台AI接到任务后，可以自己寻找服务、比较价格、选择商户，再决定用什么账户付款。用户交出去的不再只是一次支付指令，而是一段连续作出选择的权力。

设想一个企业智能体拿到100美元预算，要在几家数据服务之间作出选择。

它可能比较价格和数据质量，以每次几美分的成本调用接口。完成一项任务，它可能发起数十次请求，其间还会遇到调用失败、网络超时、自动重试和临时更换服务商。

使用稳定币时，机器可以提交可验证的付款授权或凭证，服务方完成验证，再按照相应方案即时或后续结算。

换成银行卡，问题随之增加。

每次调用都发起一笔卡交易，还是任务结束后统一扣款？服务没有返回结果，钱该不该付？网络超时后AI自动重试，怎样避免重复扣款？用户给AI的是100美元总预算，它是否可以自行选择任何服务商？

机器服务可以精确到每次调用计价，银行卡却未必适合逐次扣款。

一个多月前，支付之家在文章《一个沉睡近30年的状态码，被AI支付叫醒了……》讨论HTTP 402时，关注的还是一个更基础的变化。这个为“Payment Required”预留近30年的状态码，真正等来的可能不是网页微支付的复活，而是机器成为新的付款发起方。

随后的《第四次支付大战》，我们又把问题向前推了一步。前三次支付大战不断把账户、钱包、二维码和收银台推到用户面前，智能体支付却可能让支付重新藏进AI任务流。过去是用户走到收银台前选择支付工具，未来可能是AI先发现服务、比较价格，再从自己能够调用的账户和支付方式中作出选择。支付入口由此开始从用户面前的“按钮”，进入机器执行任务的过程。

现在，x402又把这个问题推到了更具体的位置。

7月14日，Linux基金会宣布x402基金会正式投入运营。Coinbase完成x402协议贡献，Visa、Mastercard、American Express、Stripe、AWS、Google等机构进入由40家首批成员组成的正式治理体系。基金会将银行卡、稳定币等多种支付方式纳入发展方向，并设置银行卡受理工作组。

支付巨头加入x402，争的不只是一个开源基金会的席位。哪些支付工具能够进入机器的候选范围，账户凭证由谁提供，资金由谁执行，交易出错后由谁处理争议，都可能改变支付产业的位置分配。

x402最先解决的是机器怎样表达支付要求、提交付款凭证并获得服务。银行卡要进入这一体系，还要过两道关：先解决机器服务怎样计量、银行卡怎样结算，再解决机器凭什么有权付款，以及交易出错后拿什么证据判断问题。

支付巨头进入x402，先争机器付款入口

x402基金会今年4月已经启动。

4月2日，Linux基金会宣布启动x402基金会，Coinbase准备将协议贡献给基金会，22家机构表达参与意向。三个月后，协议贡献完成，基金会正式运行，首批40家成员进入Premier、General和Associate三个层级。

x402由此开始从企业主导走向跨机构治理。

按照基金会公开结构，Premier成员可以进入治理委员会，参与预算和组织事务；技术项目则由技术指导委员会负责。截至资料截止日，公开的技术指导委员会成员仍来自Coinbase、Cloudflare和Stripe，银行卡受理等工作组已经成立。

从22家机构表达参与意向，到40家首批成员进入正式治理体系，参与范围明显扩大，但公开技术治理结构仍延续x402早期几家核心参与机构形成的格局。

支付巨头已经坐到规则桌边，银行卡还要通过技术提案、参考实现和产品部署进入机器支付。

当智能体请求一项收费服务时，服务方要告诉它接受哪些支付方式、价格是多少、付款凭证交给谁验证。智能体则要判断自己持有什么钱包、银行卡或账户权限，再选择合适的支付工具。

协议支持什么，直接影响哪些支付方式能被机器识别。

在人类主导的网络支付中，用户通常先进入商户页面，再从收银台列出的选项中选择银行卡、钱包或其他支付方式。智能体交易的顺序可能发生变化，AI先发现能够完成任务的服务，读取价格和支付要求，再自动选择支付工具。

机器的候选列表，由此成为新的支付入口。

Visa、Mastercard、American Express和Stripe加入x402，意味着传统支付机构开始参与这一接口的建设。从这些机构所处的业务位置看，它们有机会推动银行卡Token、账户凭证、商户受理和争议机制进入智能体支付接口，降低未来机器交易被单一路线锁定的风险。

云平台和商户平台掌握另一层入口。AI应用、模型、数据接口和数字服务大量运行在云端，一项协议能否进入市场，不只取决于规范是否开放，还取决于AWS、Google、Cloudflare等平台是否将它接入开发工具，商户平台是否向卖家提供相关能力，智能体框架是否把它列为默认组件。

基金会预算和工作组如何安排，规范与参考实现由谁推动，云平台、商户系统和AI应用最终采用哪套方案，共同决定x402的实际走向。

银行卡能否进入机器候选列表，最终仍取决于具体技术方案和产品落地。

支付巨头已经进入治理体系，x402当前较成熟的能力却仍然主要围绕稳定币展开。

稳定币先跑通，付款证明更容易机器化

x402通过HTTP 402响应传递价格和支付要求。客户端提交付款凭证，服务方自行验证，或者交由付款处理模块完成验证和结算，再返回数据、模型结果或其他数字资源。

稳定币与这套流程较为匹配，因为付款结果可以由程序直接验证。

钱包签名可以证明资产控制权，链上交易记录能够被程序读取和验证，付款可以全天候执行。对于API、数据、模型、算力等即时交付的数字服务，付款凭证和资源放行可以在同一程序流程中完成。

整个过程不必跳转传统收银台，也无需人工确认。机器收到报价、提交凭证并取得服务，可以在一次网络请求中连续完成。

x402当前公开文档和参考实现仍以EVM、Solana、Stellar等多条链上网络及Token支付为主，这套结构与稳定币的可验证资产转移具有较高匹配度。

稳定币更容易提供机器可验证的付款结果，却不会自动证明付款符合用户任务。智能体仍需取得钱包权限，用户仍要设定预算、服务范围和有效期限，AI也可能选错服务、发送到错误地址，或者在任务终止后继续付款。

链上交易完成后，服务方可以较快放行资源，但错误付款和越权付款通常也更难通过类似银行卡拒付的统一机制撤回。银行卡已经形成较成熟的账户授权、风险控制、退款和争议体系，可以补充稳定币路线较弱的部分。

银行卡接入后，x402可以在稳定币之外增加账户、信用、退款和争议处理能力。不同工具更可能根据服务类型、金额和风险要求分工：稳定币继续处理适合即时验证的机器支付，银行卡则提供账户、信用和争议能力。

API、数据、模型、算力和数字工具价格相对明确、交付即时，更适合x402率先落地。机器较容易同时验证付款和服务结果。

实物消费还包含库存、物流、退货、售后和多阶段履约。用户付了钱，不代表商品已经发出；商户完成发货，也不代表用户不会退货。付款只是交易的一部分，单一支付协议难以覆盖完整过程。

x402即使取得广泛采用，也未必成为AI购买所有商品的统一支付协议。它更可能首先在数字服务和机器之间的小额交易中建立稳定位置。

稳定币率先占据了付款验证位置。传统支付要进入同一接口，就要把银行卡已有的账户和争议能力，转成适合机器计量和自动执行的结算方式。

银行卡怎样进入机器支付

银行卡进入机器支付，首先要解决计价很细、结算未必同样细的问题。

一项AI服务可以按照模型Token、计算时间、带宽或调用次数计价，最终资金结算却未必适合采用同样的颗粒度。结算越接近逐笔交易，卡网络和商户越容易看到每次消费；越倾向预付或汇总，上层平台掌握的计量和内部记账就越多。

x402目前已经用三类支付方案回应这种差异。

固定金额方案exact适用于金额预先确定的交易，一次请求对应一笔确定付款；最高金额授权方案upto允许买方先授权一个最高金额，服务完成后再按照实际用量结算；批量结算方案batch-settlement则面向大量重复的小额请求，通过可重复使用的资金通道和累计凭证记录多次服务，之后再批量完成资金结算。

后两种方案表明，x402已经不再只按照“一次服务、一次即时付款”的方式设计。价格确认、服务使用和资金结算可以发生在不同时间。

当前公开的upto和batch-settlement仍是链上实现，银行卡版本尚未形成公开方案。它们已经把一个关键问题摆到台前，机器服务可以精确计量，资金要根据成本、风险和账单要求选择结算方式。

银行卡体系本身也具备相应的基础能力。

用户事先同意后，商户可以保存卡片凭证，并在约定条件下发起后续扣款。预授权可以先锁定预计金额，再根据实际履约调整金额并完成请款。网络Token则为这些后续交易提供更安全的卡凭证，自动充值、周期扣款等模式也可以建立在存储凭证和用户协议之上。

这些能力与x402三类方案并不一一对应，却可以形成三种接入路线。

第一条路线，是每次机器调用都直接触发卡交易。

服务方提出付款要求，智能体发起卡授权，支付确认后交付资源。交易与服务可以一一对应，账单也较清楚，更适合金额较高、调用频率较低、每次服务可以单独验收的场景。

第二条路线，是先锁定预算，再按照实际使用结算。

例如，用户允许智能体为一次数据分析任务最多支付10美元，AI根据模型Token、计算时间和数据调用量完成任务，最终费用为7.32美元。

upto允许买方签署最高金额，服务方在上限内按照实际用量结算。银行卡预授权则允许商户先锁定预计金额，再根据履约结果调整和完成最终请款。二者结构相似，但采用的技术和规则不同。

银行卡预授权有有效期限、金额调整和商户规则，upto当前采用链上方案。金额没有突破预算，也只能证明支出未超上限，不能证明AI选择的服务符合用户任务。支付系统可以约束最高金额，智能体平台还要把预算、实际用量和最终扣款对应起来。

第三条路线，是预付额度、可重复支付通道或汇总扣款。

用户可以先用银行卡购买一组服务额度，智能体在额度内多次调用；平台也可以记录任务期间的全部小额服务，在任务完成后统一扣款；银行卡还可以为上层钱包或智能体账户提供资金，由平台内部记录每次调用。

batch-settlement已经明确面向高频小额API请求。买方先向可重复使用的通道提供资金，每次调用生成累计凭证，服务方即时验证并提供服务，之后再批量申领和完成资金结算。

平台需要管理额度、余额和商户分账，也要让用户账单能够追溯到每次调用。用户撤销授权后，已经发生的服务如何结算，同样需要明确。具体产品还可能涉及钱包、储值或客户资金管理问题，不同司法辖区的规则并不相同。

三条路线之所以会分化，核心原因是微支付的经济性。

线上银行卡交易往往同时包含按比例费用和固定单笔费用。以Stripe美国官网公开标准价为例，线上银行卡交易价格包含2.9%的比例费用和0.30美元固定费用。

这只是美国市场的公开标准价格，不能代表大型客户和其他地区的实际协议价。它反映出的共同问题是，只要收单价格含有固定单笔费用，几美分服务就难以逐次生成银行卡交易。

每次卡授权还会增加网络延迟，高频小额授权也会带来风控处理、授权失败和账单管理压力。

因此，高价值、低频服务可以逐次发起卡交易；价格在任务完成后才能确定的服务，可以采用最高预算和实际结算；高频小额调用更适合预付、通道或汇总扣款；企业信用场景还可能先使用服务，再按日或按月统一结算。

机器服务可以按调用计价，但不一定按调用支付。

逐笔结算保留较完整的卡交易详情；上限授权要求平台把预算、用量和最终扣款对应起来；预付与汇总模式则把更多计量和账单解释留在平台内部，银行卡网络更多承担资金来源、授信和争议处理。

支付巨头进入x402，争的不只是扣款机会，也包括交易数据、调用计量和账单解释停留在哪一层。

银行卡进入机器支付，第一道关并不是能不能扣款，而是按什么方式扣、谁负责计量，以及用户最终看到怎样的账单。

比结算更难的，是机器凭什么有权花这笔钱。

机器凭什么有权花钱

人类发起支付时，付款行为和交易意图通常同时出现。

用户看见订单，选择银行卡或钱包，再确认付款。支付系统记录账户、商户、金额、时间和资金状态，通常可以还原交易的基本情况。

智能体付款把这两个动作拆开了。

用户可能先交付一个任务和总预算，AI随后自主选择服务商、调用工具并执行付款。支付发生时，用户未必正在查看订单，也未必知道AI选择了哪一家服务。

一笔AI付款要形成完整授权依据，至少要连接四层记录。

第一层是任务：用户究竟要求AI完成什么，能否更换服务商，是否允许执行后续动作。

第二层是权限：AI可以使用哪个账户，最多花多少钱，授权持续多久。用户可以允许AI使用某张银行卡，但只限于10美元、某一类商户和当天有效。账户授权不能自动扩大为无限任务权限。

第三层是支付：实际收款方、金额、支付工具，以及授权、清算、退款和争议状态。

第四层是履约：商户提供了什么，接口是否返回结果，任务是否完成，是否出现失败、重试或部分履约。

四层记录要通过共同标识建立对应。

一次AI交易可能涉及任务编号、智能体身份、授权编号、支付交易号、商户编号、服务调用号和履约结果。

这些信息一旦彼此割裂，银行只知道钱付给了谁，却不知道原始任务。智能体平台掌握用户任务，却无法确认最终资金状态。商户知道服务被调用，也未必了解用户允许AI花多少钱。

建立证据链并不意味着集中保存全部数据。智能体平台保存任务和执行记录，银行或钱包保存账户权限，支付系统保存交易及资金状态，商户保存报价和履约结果。x402的支付标识、签名报价和签名收据等扩展，可以为这些分散记录建立关联。

银行卡进入智能体支付后，还要在智能体平台、银行、商户和支付机构之间传递可核验的授权信息。

这些信息至少要说明，谁授予权限，哪个智能体获得权限，对应什么任务，可以使用什么账户，金额和次数上限是多少，授权何时失效，以及用户是否已经撤销。

Visa、Mastercard和银联正在推进的智能体支付设计，已经开始将可信智能体身份、消费者同意、订单意图、支付Token和账户授权带入交易过程。Visa相关产品仍处于开发和部署过程中；Mastercard公开方案包括注册智能体、网络Token、订单意图和消费者同意。银联APOP围绕智能体身份、交易意图、用户身份和支付授权建立框架，并已完成有限生产验证。

x402目前公开的机制主要覆盖付款要求、支付标识、报价和收据，完整的任务授权仍要由智能体平台、账户体系和支付网络共同承接。

人类支付记录主要解释钱去了哪里。智能体支付还要形成一条由不同系统共同保存、必要时相互核验的证据链，解释机器为什么花钱、依据什么权限花钱。

正常交易中，这组记录形成授权依据。交易出错后，同一组记录还将决定问题发生在任务、权限、付款还是履约环节。

AI付款出错，现有争议规则只解决了一半

支付成功、任务合规和服务完成，是三个不同判断。

智能体付款出错，既可能是交易状态出了问题，也可能是AI对任务的理解和执行发生偏差。

重复扣款、账户凭证被非法使用、服务未交付和金额错误，都属于交易状态问题，核心是还原交易实际发生了什么。

现有支付技术和银行卡争议规则，已经能够处理其中相当一部分。

网络重试是最典型的例子。

智能体向服务方发送请求，商户已经成功处理并返回结果，但网络超时导致客户端没有收到响应。AI判断请求失败，于是自动重试。如果系统把每次重试都视为新交易，就可能再次扣款和提供服务。

x402的支付标识以及成熟支付API中的幂等机制，都用于处理这一问题。同一次购买意图在网络重试时应持续使用同一标识，服务端据此识别同一次购买，避免重复付款。具体缓存和去重仍由服务端实现。

一旦系统已经生成两笔交易，问题就不再只是技术去重，而会进入重复扣款和退款处理。商户或支付处理方需要证明两笔交易对应不同服务。如果只能证明一次调用和一次履约，重复交易就需要撤销或退款。

幂等机制用于预防重复执行，争议规则用于处理已经发生的重复扣款。

付款成功但服务没有交付，同样属于交易状态问题。

报价记录、付款凭证和服务端交付日志，分别说明商户提出了什么条件、资金是否完成以及系统是否返回服务。签名报价和签名收据可以形成审计或争议处理所需的交互记录，但服务端留下交付记录，也不能单独证明服务质量符合用户预期。

银行或钱包还可以依据身份验证、存储凭证协议、Token和交易记录，判断银行卡或账户凭证是否被合法调用。

任务语义错误处理的是另一类问题。AI为什么进行这笔交易，以及这一选择是否符合用户交付的任务。

账户授权与任务授权不是同一件事。

智能体平台要证明用户交付了什么任务，AI可以选择哪些商户、允许花费多少以及授权持续多久。一次银行卡授权成功，可以证明支付工具被系统接受，却不能单独证明AI按照用户任务行动。

例如，用户要求AI购买一份特定行业报告，智能体却订阅了全年数据库。银行卡可能由用户本人授权绑定，交易金额也没有超过账户限额，但AI已经超出原始任务。

现有卡网络争议规则可以处理未经授权交易、重复扣款、金额错误和服务未交付，却通常无法直接判断模型是否正确理解了一项复杂任务。这类问题的判断要结合用户原始指令、平台设定的限制、AI的执行记录，以及关键节点是否取得用户确认。

即使没有越权，也可能出现另一种问题。AI在预算内选择了更贵的服务。交易处于预算内、服务也已交付，支付系统无法据此判断选择是否合理。问题取决于用户是否要求最低价格、是否更重视质量，以及平台承诺了怎样的选择标准。

传统支付主要判断交易状态，智能体支付还必须判断任务语义。

Visa和Mastercard正在推进的方案，已开始加入可信智能体身份、消费者同意、订单意图、网络Token和AI参与标识。这些信息有助于商户、发卡机构和网络识别交易由谁发起、使用什么凭证、是否获得基本授权，却仍无法自动评价AI是否忠实、合理地执行复杂任务。

传统支付争议通常先判断“这笔交易是不是本人授权”，智能体支付还要继续判断“AI是否按照本人授权的任务行动”。

现有支付体系能够处理资金和交易状态，却无法单独完成任务语义判断。智能体平台、账户体系、支付网络和商户分别掌握不同证据，完整的AI支付争议要把这些记录准确连接起来。

开放协议、钱包闭环与x402的边界

x402先从开放互联网接口解决机器如何表达价格、付款要求和付款凭证。

不同AI、不同服务商和不同支付工具之间，缺少统一方式传递这些信息。x402尝试建立通用接口，再把稳定币、银行卡和银行转账等支付方式接进来。

这种路线的优势是跨平台。一个智能体可以在开放网络中发现多个服务商，不必被限制在单一钱包或超级App内；开发者也可以通过统一接口接入不同支付方式。

难点是身份、授权和消费者保护分散在多个主体之间。智能体平台记录任务，钱包或银行提供账户权限，商户负责履约，支付机构和卡组织处理资金与争议。任何一段记录断开，都可能影响责任判断。

Visa和Mastercard正在推进的智能体支付设计，也不是与x402完全平行的一套封闭系统。它们从现有卡网络、Token、商户受理和风险体系出发，增加可信智能体身份、用户同意、订单意图和AI交易标识。这些能力既可以服务卡网络内部交易，也可能成为银行卡进入开放智能体接口的组成部分。

中国支付的起点有所不同。

支付宝、微信支付、银联和商业银行已经形成较成熟的账户、钱包、商户受理、身份验证和风险控制体系。银联APOP已经完成有限生产验证，并继续推进智能体银行卡、收单和自主支付方向的试点与技术预研；支付宝、微信支付向AI场景开放支付能力的探索，也更多是在既有账户和商户体系上增加智能体权限。

中国支付的优势在于，用户身份、账户、商户和风控能力已经沉淀在相对成熟的银行、钱包和支付体系中，向AI开放账户权限时，更容易先把额度、确认、撤销和账单管理做进现有产品。

但这种优势也有另一面。

账户权限容易形成闭环，不代表跨平台连接同样容易。一个智能体如果要跨钱包、跨银行、跨商户平台发现服务并调用支付能力，还要面对不同账户体系之间的授权规则、数据接口和责任记录如何互通。

中国支付因此更可能先从“AI怎样安全使用我的账户”入手，开放互联网路线则首先解决“AI怎样跨平台找到服务并完成付款”。两种路径最终都需要补上自己相对薄弱的一侧。

智能体支付可以分成三个相互连接的层次。

接口解决机器怎样发现服务、读取价格并提交付款凭证，x402主要在这一层提供连接。账户凭证、资金执行、商户受理、退款和争议，则由卡网络、稳定币网络和支付处理机构承接。银行、钱包和智能体平台更接近用户，负责身份、任务授权、预算、确认、撤销和账单展示。

开放接口负责连接，支付网络负责资金与争议，账户平台负责权限和用户控制，三者共同组成智能体支付。

分层协作不代表各方利益完全一致。

钱包不愿失去用户和账户入口，云平台希望控制开发环境，卡组织要让Token、账户凭证和争议处理继续留在卡网络中，商户平台也未必愿意让AI绕过原有结账页面。支付机构还要承担高频小额交易带来的欺诈、退款和运营成本。

从这些机构所处的位置看，参与x402既是在推动共同标准，也是在确保自身能力不会被未来机器交易接口绕过。

x402更可能先在API、数据、模型和算力等数字服务中形成规模。进入实物消费后，银行卡及既有支付体系仍要承担资金执行、消费者保护和长期争议处理。

但x402带来的变化，最终不会只停留在一种协议能够覆盖多少支付场景。

在《第四次支付大战》中，我们曾判断，智能体可能让支付重新藏进AI任务流。现在，这个判断还可以再往前一步——支付可以隐身，人的控制不能隐身。

用户不可能为AI的每一次API调用、每一笔小额服务和每一个任务步骤逐笔确认。越是自动执行，交易之前的规则就越重要。人的控制会从付款那一刻向前移动：先定义任务、预算、账户范围、商户边界和撤销条件，再允许AI在授权范围内执行。

这也是随着x402进入正式治理阶段，第四次支付大战正在显露出的更深一层变化。

前三次支付大战争的是谁更靠近用户的付款动作；智能体时代，竞争开始向机器作出交易决定的那一刻移动。谁能进入智能体的选择范围，谁能提供账户权限，谁来执行资金，谁又能在交易发生之后解释这笔钱为什么被花掉，都会成为新的支付位置。

支付可以从前台消失，但交易决策权不会消失。

支付巨头集体加入x402，争的因此已经不只是付款最终经过哪条网络，而是谁更接近智能体背后的交易决策权。

下一代支付基础设施真正的分水岭，不是谁能让AI更自由地花钱，而是谁能让机器的每一次支付都有授权、可解释，让权限能够收回，让错误能够追责。

自动化不是把人从支付中拿掉，而是把人的控制从逐笔确认，上移到任务、权限、预算和责任边界。

这里是支付之家。我们关注支付表象之下的规则差异与逻辑变化，也记录智能体支付正在带来的入口迁移、授权重构和信任重排。本文为行业观察与阶段性判断，观点内容仅供参考。