Visa Intelligent Commerce：让商家知道，来付款的是一个被授权的 Agent

类型：卡网络、Agent 身份与凭证基础设施｜面向：发卡机构、商户、平台和企业支付伙伴｜资料核验：2026-10-28｜未实测。

一家企业已经批准了一张供应商发票，但付款仍需要员工登录供应商网站，输入卡信息并提交。Visa 与 BILL、Billtrust 的试点把最后一步交给 Agent：它使用受控的凭证完成已批准的付款。这个案例说明 Visa 的切入点：让既有的卡支付网络和商家门户能识别并处理 Agent。

背景：Visa 在链路里的位置

Visa 是支付网络与技术服务提供商。它连接金融机构、商户收单体系和平台，具体卡账户和资金通常由发卡方及其他参与方提供。Intelligent Commerce 是一组面向 Agent 商业的能力，包括身份与信任、支付凭证和控制等；Trusted Agent Protocol（TAP）聚焦 Agent 与商家之间可验证的通信。它不是一个给每个 Agent 存放余额的钱包。Intelligent Commerce · TAP 发布

企业发票试点：谁做什么？

2026 年 10 月 20 日，Visa、BILL 与 Billtrust 宣布面向参与买卖双方的 live pilot。以下流程来自其公告，并非本站验证。

sequenceDiagram participant B as 企业买方 participant A as BILL Payment Agent participant P as Billtrust 供应商门户 participant V as Visa 信任与支付能力 B->>A: 批准发票及付款指令 A->>V: 使用登记身份与受控支付凭证 A->>P: 发起已批准发票付款 P->>V: 识别和验证 Agent V-->>P: 返回相关信任信号 P-->>A: 依据接受政策处理付款

该试点中，BILL Agent 的指令绑定买方已经批准的付款，Billtrust 借 TAP 识别 Agent；使用 tokenized payment credentials，不要求共享供应商门户登录凭证。Visa 明确说明 Agent 不作付款决策，而是执行合格的已批准付款。试点公告及 FAQ

识别 Agent 与批准付款是两回事

组件	解决的问题	边界
TAP	向商户传递可验证的 Agent 身份和意图等信号	身份可信本身不证明用户批准了任何购买
代币化凭证	减少暴露原始卡信息，按方案限制使用	发卡方、网络和商户仍需各自处理授权、风控与争议
Agent 控制	在合作方案中绑定购买或付款指令	限额、适用对象、撤销和责任取决于具体实施
卡网络	处理适用的网络交易与相关服务	不是 Agent 资金余额本身

Visa 产品页明确提醒部分能力处于部署过程，最终功能可能改变。试点成立也不代表全球所有供应商门户、商户或发卡行已经支持。产品页

商业模式与判断

Visa 的既有商业基础包括网络处理及相关增值服务。Agent 交易可能让其现有凭证、认证和支付网络服务进入新的购买界面，这是分析推断，不是 Visa 对该项目收入或每笔费率的披露。Visa 开发者平台的 API 有不同收费安排；Intelligent Commerce 与 TAP 的具体企业报价未核实，不能将通用 API 费率直接套用。开发者定价说明

与 Mastercard Agent Pay 相比，两者都试图使身份和既有卡支付适配 Agent；Visa 这个案例尤其具体地展示了企业已审批发票跨门户执行。与链上 Agent 钱包相比，这里依赖既有商业卡网络和参与机构，而非必须持有稳定币。

适合跟踪的读者包括企业应付账款团队和供应商收款平台。接入前需问：哪些发卡行与门户参加？审批指令如何约束凭证？失败、重复支付与退款由谁处理？能否回传财务系统完成对账？

传统卡交易为什么需要新的信任层？

传统的线上支付往往依赖人的浏览器会话、登录或验证码。Agent 可以代人读取和提交网页，但商户无法只凭自动化请求判断它是否受欢迎、代表谁、正在搜索还是付款。TAP 的思路是为请求提供可验证的 Agent 信号；Visa 的发布材料提及 Agent 意图、消费者识别信息以及可选支付信息，并称建立在 HTTP Message Signatures 等网络标准之上。实际收到哪些字段、由谁验证，以及是否允许访问，由商户和参与方共同决定。TAP 发布材料

这一区分会影响每个参与者：企业买方希望预算及发票准确；BILL 需要知道执行的指令已被批准；Billtrust 要确认进入供应商门户的是可识别 Agent；发卡机构和网络仍要处理对应卡交易。即使门户识别了 Agent，发卡方仍可能拒绝卡交易；即使网络授权成功，发票匹配与会计对账也可能失败。

把试点放回应付账款流程

阶段	谁负责	可能需要保存的记录
供应商开票	供应商及其平台	发票号、金额、到期日、收款方
购买方审批	买方企业及应付平台	已批准金额、审批人、指令与权限
Portal 访问	BILL Agent 与 Billtrust	Agent 身份、访问结果及发票关联
卡交易	发卡方、网络与收单方等	授权与处理结果、交易标识
对账和例外	买卖双方系统	已支付状态、重复付款核查和后续处理

这是根据试点职责整理的操作清单，不声称试点已经公开每项字段、退款或重试规则。公告称该试点已在参与的 BILL 买方及 Billtrust 供应商之间处理端到端交易；更广泛的地理、商户和规模数据没有在此处证明。试点公告

出错时谁来查？

支付前，可出现发票金额变化、指令过期或门户拒绝 Agent；提交后，可能出现网络超时、付款状态不明或供应商系统没能关联发票。买方不能在没有查询原交易状态的情况下简单重试，否则可能重复支付。需要在合同和集成测试中确认：可查询的交易标识是什么，谁能撤销、退款或发起争议，供应商门户和买方账本何时同步。上述是尽调问题，不是对试点已实现这些功能的断言。