Stripe Shared Payment Tokens：把有限付款权限交给商家

购物助手找到了替换用的笔记本充电器。用户同意商家和最终价格之后，商家还需要一份能实际处理付款的凭证。把整个支付账户交出去权限太大，只说“用户同意了”又不够。Stripe 的 Shared Payment Token，简称 SPT，解决的是中间这一层。

核对边界： 2026 年 11 月 1 日查阅官方文档。本文讨论凭证范围和示意订单流程，没有签发令牌或真实扣卡。

看清授权关系，不只看令牌字符串

Agent 接入文档要求取得商家的 Stripe Profile，再通过令牌授予使用用户支付方式的权限。接收方很重要：SPT 不是一串任何商家都应当能用的通用卡号。

在充电器例子中，应先把购买决定绑定到所选商家、商品、金额和币种，再申请凭证。如果 Agent 换了商家或改了订单，要重新检查原授权是否仍然适用。商品标题相近，并不能成为把用户同意悄悄转移给另一家店的理由。

采用 Stripe 处理支付的概念路径，非实际结账。凭证签发、支付处理和订单成立是不同事件。

使用限制要成为支付约定的一部分

商家文档说明了金额、币种、到期时间等限制，目前也描述了明确配置周期的 recurring SPT。因此，不能一概写成“所有 SPT 都只能用一次”。单次购买与持续扣费权限，需要向用户作不同解释。

购买一个充电器不需要长期授权。若购买周期性服务，就要展示扣费周期和条件，不能藏在一句“确认”后面。两种情况都应保留用户批准的订单版本。额度上限只是一项限制，不能单独解释这笔费用为何合理。

商家拿到的是 granted-token 视图

API 文档区分签发侧令牌与接收方只读的 granted-token 资源；后者可查看属性，并用于 PaymentIntent。设计权限时，应分清谁能创建、查询和使用授权。

实际支付凭证应留在支付系统中，不必进入模型对话。助手知道“已批准、已过期、被拒绝”等状态，就足以开展很多交互。我们建议对模型提供接受订单号的窄接口，由服务端完成付款并返回脱敏结果，而不是把凭证字节暴露给模型。

用户看到的事件	应用需要核实什么
已同意购买	商家和最终订单仍与批准版本一致
凭证已准备	范围、有效期和使用方式符合该订单
已尝试付款	支付处理方的最新状态可确认
购买完成	商家订单存在，且达到要求的付款状态

超时不应变成第二笔购买

支付响应慢时，要保留原订单和支付编号，先核对状态，再决定是否需要新凭证或新结账。用户想买一个充电器，不是让 Agent 一直买到收到满意的响应为止。

取消也跨越多个层次。阻止凭证继续使用，不等于取消已有商家订单，更不等于退回已经扣除的款项。客服流程应准确说明完成了哪一步，不能因为助手停止尝试，就显示“已退款”。

不要把 SPT、Link 和商家产品混为一谈

SPT 是受限凭证机制；Link Agent Wallet是独立的买方支付入口；Stripe 商家方案又覆盖更广的商家接入。它们可以一起使用，但不是同一个对象换三个名称收录。

适用国家、支付方式、账户资格和 API 版本仍需逐项确认。核对时，文档示例使用了预览版本能力；生产接入前应重新查阅 SPT 文档。本文提供架构检查方法，不保证某个账户拥有全部公开能力。