独立解读
Stripe Link 的 Agent 钱包：不交出原始卡信息，如何让 Agent 帮你付款？
结论先行：Stripe 的 Link Agent 钱包沿用用户已经有的卡或银行账户，向 Agent 提供一次性卡或受限支付凭证。它的核心是让现有支付体系接纳 Agent；官方公开演示包含用户批准，不能据此声称它普遍支持无人审批购物。
资料核查 2026-10-28；本文没有实际开通 Link 或付款。
背景：支付平台为什么需要 Agent 钱包？
Stripe 长期向商家提供支付、收单、发卡和其他金融基础设施；Link 是其消费者支付体验。Stripe 于 2026 年 4 月介绍 Link 的 Agent 钱包时，指出它建立在 Issuing for agents 之上，让 Agent 获得一次性卡或 Shared Payment Token（SPT），而不接触用户原始支付凭证。
这条路线与稳定币钱包不同：用户可能已经有可用的卡或银行账户，关键任务是让 Agent 安全使用它们，并让原有商户支付链路能识别和处理交易。Link、发卡服务、商户收款和 Agent 应用各是不同的产品角色。
从聊天到付款：一次 2 美元的 API 请求
Stripe 的 Sessions 演示展示 Agent 发现一个支持 Machine Payments Protocol（MPP）的付费 API，看到 2 美元价格后转到 Link，由用户查看并批准，然后继续执行请求。这是公开演示，不等于本站独立验证，也不代表所有 Agent 购买均采用同样流程。
图是将公开演示和产品描述概念化；具体消息、批准时点和凭证类型依实现而异。
一次性卡与 SPT 有何意义？
| 要解决的问题 | 产品思路 | 别误解为 |
|---|---|---|
| Agent 需要发起支付 | 使用一次性卡或 SPT | Agent 必须知道原始卡号 |
| 用户希望知道自己买什么 | 演示中用户批准交易 | 所有服务都支持同一种审批体验 |
| 商户需要接收付款 | 接到相应的支付和商户流程 | 所有网页、地区与银行账户都已支持 |
| 付款后发生争议 | 走适用支付与商户规则 | 钱包能保证商品质量或必然退款 |
支付凭证、用户授权与发卡方批准是三件不同的事。用户同意购买后，发卡行、商户及支付服务仍可能拒绝交易；部分交易也可能需要额外身份验证。
商业模式和价格
Stripe 已有商户收单、Issuing 等业务。它把 Agent 的支付活动接回既有网络，可能带来更多支付和配套服务机会，但这不是 Agent 钱包收入披露。Stripe 通用定价列的是具体支付产品的价格，不能直接认定为 Agent Link 的统一收费；实际需要核对消费者端、商户端、发卡或凭证服务各自的合同及地区。
| 成本或责任 | 必须问清 |
|---|---|
| 用户支付 | 卡、银行、兑换是否有费用，谁承担 |
| 商户收款 | 使用 Link、SPT 或虚拟卡时，收费主体及费率 |
| 争议退款 | 商户、发卡方和平台分别负责什么 |
| 准入 | 账户、地区、Agent 平台及商户的支持条件 |
与链上 Agent 钱包的差异
如果目标是向现有支持银行卡的商家采购，Link 的既有凭证网络有明显吸引力；如果目标是让机器高频支付支持 x402 的链上 API，Coinbase 或 Circle 的路径可能更直接。实际选择还取决于商家接入、用户审批体验和完整费用。
待验证：当前国家和账户能否使用；什么时候需要逐笔批准；SPT 与一次性卡分别适用哪些商户；限额如何执行；支付成功但服务未交付时如何处理。不能把一次演示扩展成普遍可用性。
钱从哪里来，Agent 又会看到什么？
Stripe 的发布说明把 Link 的既有卡或银行账户作为资金来源；在用户批准后，系统向 Agent 提供一次性卡或 SPT，让它完成购买。原始支付凭证不需要交给 Agent。Stripe 还称用户可以在 Link 查看 Agent 支出和管理连接的 Agent。
这与给 Agent 一个持续暴露完整卡号的做法有本质不同：即使凭证泄露，它的作用范围仍需按具体 token 或卡的限制判断。受限不等于零风险：如果 Agent 请求用户批准的是错误商户或错误价格，用户仍可能批准一笔不该发生的交易；如果用户无法看懂授权窗口和最终金额，风险只是从凭证泄露转向错误确认。
Stripe 的 Agentic Commerce 指南说明 SPT 可以限制到特定卖家、金额和时间窗口，Link Agent Wallet 的购买需要用户审阅与批准。具体集成应确认：一次性凭证在失败、订单修改、金额变化或时间窗口到期后如何处理，而不是假设任何 SPT 都能无限次使用。
Link 与 Issuing：消费者产品和开发者基础设施
Stripe 在同一发布说明中将 Link 钱包建立在 Issuing for agents 之上。Link 是用户使用的支付体验；Issuing 则给企业开发者提供发卡、资金流、权限、交易监控等底层能力。应用团队可以围绕它设计自己的产品，但这不等于每一个 Issuing 客户都使用 Link，也不等于任意地区都能立刻发卡。
| 谁做决定 | Link 钱包场景中的问题 | 定制 Issuing 场景中的问题 |
|---|---|---|
| 用户 | 是否批准这笔购买 | 如何查看自己的卡与支出 |
| Agent 应用 | 如何表达商户、商品和金额 | 是否构建用户界面、预算与通知 |
| Stripe 与支付合作方 | 如何生成和处理受限凭证 | 卡、资金和风控能力是否适用 |
| 商户 | 是否接受支付并交付 | 授权、扣款、退款及售后 |
Stripe 2026 年 10 月服务条款将 Link Agent Wallet 服务描述为 Preview，并列出企业接入和 Link 作为支付方式的相关条件。条款页面地区可能影响适用性；具体国家、账户与最终费率应查看对应版本和合同。Preview 是服务阶段信息，不表示任何特定客户已获批。
一个购买的总成本怎么估算？
假设 Agent 购买一项标价 100 美元的软件。用户最终付款可能包含商户税费或货币转换；商户端还可能按 Stripe 支付合同承担处理费用。即使公开的通用价格可查，也不能未经核实把它乘以 100 美元后称为本次 Agent 交易的确定手续费，因为商户所在地、卡类型、发卡安排和合同都可能改变计算。
应向相关方索取完整费用拆分：商品价与税、汇率及兑换、用户侧附加费用、商户侧支付费、发卡服务费以及退款时费用处理。对于高频一美元 API 调用，固定费用和批准次数都可能影响经济性；价格低并不意味着这种卡路径一定适合所有微支付。
失败、退款和用户体验
如果用户拒绝批准，Agent 应把任务留在可解释的待处理状态，而不是改用未经授权的方式。若用户批准后发卡行拒绝，应用应说明是支付失败，而不是声称用户没有授权。如果支付成功但 API 未返回结果，先查交易和订单状态，再根据商户规则决定重试或退款。
Stripe 和 Meta 的 Muse 合作案例提供了消费者购物场景，但合作案例的渠道与地域不能推广到所有 Agent 和商家。是否适合你的产品，核心是用户是否接受每次审批、目标商户是否受支持、以及订单和客服能否连贯，而不只是用户是否已有银行卡。