给AI一张“银行卡”，但只让它用一次

AI开始拿“一次性银行卡”自己结账了。

支付之家注意到，支付基础设施公司AEON推出Agentic Checkout。用户可以直接告诉AI Agent自己想买什么，Agent搜索商品、建立购物车，在获得用户授权后调用AEON AI Card完成付款。

AEON称，AI Card支持一次性虚拟卡，可以预设预算，并将使用范围限定到一次任务或一笔交易。其公开项目目前已经提供从Shopify商品搜索、建立购物车，到生成一次性卡并提交支付的完整调用流程。

AI获得支付权限本身已经不是新鲜事。

此前，微信支付已经通过AI专属卡等方式尝试划定AI能够使用的资金范围。Visa正在推进面向Agent的支付Token和交易控制，Mastercard也已通过Agent Pay、Agentic Token等机制，把Agent身份和支付授权接入卡支付体系。

AEON这次把Agent支付进一步推进到了支付凭证这一层。用户已经决定让AI付款以后，究竟应该给它一份什么样的支付工具。

AEON选择的是围绕当前任务产生的一次性虚拟卡。与用户长期使用的银行卡不同，这份支付凭证从一开始就不是为了长期存在。

一张只为这次购物存在的卡

AEON公开的AI Card项目已经给出了比较具体的执行路径。相关工具可以接入多种Agent开发环境。按照目前公开的实现，用户可以使用BSC网络上的USDT稳定币作为资金来源创建一次性虚拟卡，再由Agent使用这份支付凭证在商户端完成银行卡支付。

在Shopify场景中，Agent可以从搜索商品开始，读取规格和价格、建立购物车，随后进入结账流程。需要付款时，再根据当前交易生成相应支付工具，打开商户已有的结账页面，填写收货地址和支付信息并提交订单。付款之后，Agent还可以继续查询订单和卡片状态。

这类任务级支付凭证的有效期开始与具体任务绑定。普通银行卡通常会伴随一个账户长期存在，今天在一家商户使用，明天仍然可以拿到另一家商户付款。具体什么时候使用、花多少钱、是否继续付款，很大一部分判断由持卡人本人完成。

Agent的运行方式不同。一段软件可以持续工作，同时处理多个任务，也可以连续调用不同工具。如果把一份长期有效、使用范围很大的支付凭证直接交给Agent，原本由人掌握的部分控制能力也会被一并交出去。

任务级支付凭证采取的是另一种办法。系统根据具体任务和用户授权划定范围，再给Agent完成任务所需的支付权限。金额、商户、有效时间和使用次数都可以受到限制，任务完成以后，这份支付凭证也没有继续存在的必要。

AEON还称，完整卡号和安全码不会进入模型上下文和对话记录，其公开实现中涉及卡片信息的部分内容也进行了遮罩。完整卡号不进入模型上下文，也就把支付凭证与模型运行环境隔开。Agent需要完成付款，并不意味着必须长期保存用户原始银行卡信息。

传统银行卡的支付凭证通常围绕账户长期存在，而在Agent场景中，它开始可以围绕一次具体任务临时产生。

一项任务，一份支付凭证

AEON并不是第一个采用这种思路的公司。

今年3月，UQPAY推出面向AI Agent的FlashCard，提出“一项任务、一次授权，然后失效”的设计。按照其披露，一张FlashCard可以围绕具体任务生成，并限制商户类别、指定商户、消费金额、地区和有效时间，任务结束或者卡片到期后即失去继续使用的能力。

AEON和UQPAY都把这种权限做成了比较直观的虚拟卡，但任务级支付凭证不一定最终表现为一张新的银行卡。

Visa Intelligent Commerce采用的是另一种路径。其设计中，用户可以先将支付能力配置给特定Agent，形成与Agent关联的支付Token。Agent真正准备执行购买时，再依据经过认证的支付指令（Payment Instruction）取得相应支付能力，商户、金额等条件可以继续在支付网络中接受校验。

Mastercard Agent Pay已经把Agent身份、Token和用户授权接入卡支付体系。不同公司的技术实现并不相同，但共同点是，Agent实际获得的支付权限开始被限定到更具体的主体、用途和交易范围。

传统银行卡主要围绕持卡人提供长期支付能力。移动支付普及以后，大量Token开始与设备和钱包绑定。Agent进入支付以后，市场上又开始出现与特定Agent甚至具体任务绑定的支付凭证。从持卡人、设备，到Agent和具体任务，支付凭证正在出现越来越细的绑定范围。

一个消费者决定购买500元以内的商品，这个预算过去可以只存在于人的脑子里。看到价格超出预期，他会停止付款。看到陌生商户，可以主动退出。网页长时间没有响应，还可能先查看短信或者银行App，再判断是否需要重新操作。

Agent不能依赖这些只存在于人脑中的判断。可以买什么、最多花多少钱、在哪些商户使用、授权持续多久，都需要越来越明确地转换成系统能够读取和执行的条件。这些限制可以存在于用户意图、支付Token、虚拟卡、支付指令或者网络风控规则中，具体实现并不相同。

同一资金来源之上，也可以叠加不同范围的支付权限。底层仍然是用户真实的账户或银行卡，上面可以是一份允许某个Agent调用的支付权限。真正执行具体任务时，又可以进一步取得生命周期更短、用途更窄的一份支付凭证。

在长期反复使用的支付凭证之外，越来越多面向机器执行的任务级支付凭证开始出现。

AI真正付款以后，还得先学会“不要再付一次”

Agent拿到支付凭证，还不等于已经具备可靠的支付能力。真正进入交易执行以后，它还需要正确理解支付结果。

AEON公开的Agent集成规则明确要求，真实支付命令不能自动重试。

失败重试是普通软件中很常见的处理方式。接口没有响应，可以再请求一次。页面加载失败，可以重新执行。Agent调用工具没有获得结果，也经常会尝试再次调用。但同样的逻辑直接套到支付动作上，就可能产生重复交易。

在支付处理中，程序没有得到成功结果，并不代表付款没有发生。Agent提交支付以后，浏览器可能超时，商户页面可能没有及时跳转，系统也可能暂时没有拿到明确的订单结果，但卡交易可能已经进入授权或者后续处理流程。如果Agent把这种“不确定”直接理解成失败，再次提交付款，就可能重复发起交易。

因此，AEON要求支付结果不明确时先确认状态，而不是立即重试。Agent可以检查订单、邮件、收据等信息，再判断上一笔支付到底有没有完成。

这个细节涉及传统支付系统早已非常熟悉的交易状态和幂等控制。

银行卡支付并不是简单的“成功”和“失败”两个状态。交易过程中可能出现授权、撤销、请款等不同状态，完成交易后还可能发生退款。商户订单状态与支付网络状态也未必始终同步。页面没有显示成功，不代表发卡侧没有授权。获得授权，也不一定意味着商户已经最终完成订单。

过去，这些复杂状态主要由商户系统、支付机构、收单机构和卡组织在后台处理，消费者本人也承担一部分异常判断。Agent真正成为交易执行者以后，它同样需要知道什么时候应该等待，什么时候应该查询上一笔交易，什么时候允许重试，以及什么时候必须停止继续付款。

当AI真正开始执行付款，它也开始面对支付行业长期存在的交易状态机、幂等、订单核对和异常恢复问题。一个能够搜索商品、比较价格甚至理解用户预算的Agent，如果无法判断上一笔支付是否已经成功，仍然称不上可靠的支付执行者。

Agent上游可以运行在新的AI工具和协议环境中，资金来源也可以出现USDT等新形态，但到了商户结账环节，它最终仍然通过现有卡支付体系能够识别的虚拟卡凭证完成付款。

Agent并不一定需要等待全球商户先部署全新的“AI支付按钮”，也可以先获得一份受限制的支付凭证，再进入商户已经存在的银行卡结账页面。商户继续使用原有收银页面，收单机构和卡组织继续处理熟悉的卡交易，Agent则需要按照这套支付基础设施既有的交易规则完成执行。

这种模式下，商户最后看到的付款方式甚至可以不变，变化先发生在支付网络之前。以前进入收银台的是消费者本人和一份长期使用的银行卡支付凭证，未来也可能是Agent带着一份刚刚为当前任务生成的临时支付权限进入同一个收银台。

银行卡从塑料卡进入手机钱包以后，支付凭证已经大量转化为设备Token。Agent进入支付以后，支付凭证还可能继续向Agent级、任务级和交易级细分。

资金账户仍然存在，卡组织网络也可能继续存在。变化的是支付权限被交给谁、能够做什么，以及可以持续多久。

AEON这套方案的意义在于，任务级支付凭证已经被放进商品搜索、建立购物车、提交付款和交易异常处理的一整套Agent执行链路。

当AI真正开始替人完成交易，支付系统交给它的可能越来越不是一把长期有效的账户钥匙，而是一份只够完成眼前任务的临时通行证。

#支付

这里是支付学院，关注支付，也关注每一次支付产品微小的进化。

来源丨支付之家·支付学院 (观点仅供参考)