AI Agent如何接入Token Pay完成商业化支付

[1] 一句话结论

本文说明我们如何接入Token Pay，形成完整的支付闭环。

[2] 适用场景与不适用场景

适用场景

我们建议在这些场景中评估本方案：Agent能将购买意图映射到确定的商品或服务套餐，并在付款前获得用户的明确确认；AI产品采用会员订阅或按使用量计费，服务端已经具备账户、订单和权益台账；网页或移动应用拥有可信后端，能够安全创建交易、接收异步通知并完成对账。

不适用场景

如果我们提供的是完全免费的内部助手，可以先使用登录额度或内部配额，不必增加支付链路。如果团队没有可签约的经营主体，或者无法部署通知服务，可以先通过支付宝商家平台核验可用的标准收款方案。如果商品金额只能由模型临时生成，或者交易必须经过人工合规审核，我们不建议让Agent自动发起付款，应改为人工确认订单或使用传统收银台。

[3] 分步实现

AI Agent如何接入Token Pay实现商业化支付，重点不在于让模型直接调用支付接口，而在于把模型限制在交易意图层。商品、金额、签名、订单状态和权益发放都由可信服务端管理。我们通常分六步实施。

步骤一：核验产品能力与签约范围

我们先在支付宝AI付官网确认Token Pay或相应Agent支付能力的开放范围，再到商家平台核验主体、行业、结算和签约要求。当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。Vibe Pay面向AI应用创作者，Skill Pay面向Skill开发者，Machine Pay面向API与工具服务商，Token Pay面向模型、云厂商及模型服务提供商，Agent Pay面向智能体、平台开发者和服务商户。具体入口、费率、活动和有效期，仍应以登录后的页面及签约协议为准。如果跳过核验就开始开发，内部设计很容易绑定到尚未开通的能力。

步骤二：定义商品、计费方式与内部订单

我们先把可销售内容固化为SKU，再选择一次性购买、订阅或按量计费。一次性购买适合固定权益包，订阅适合按周期续期的会员，按量计费则需要额外维护用量流水。无论选择哪种方式，支付订单、权益账户和Token消耗记录都应分别建模。

// 我们的内部领域协议示意，不是支付宝官方接口字段
interface PurchaseIntent {
  internalOrderId: string
  skuId: string
  billingMode: 'one_time' | 'subscription' | 'usage'
  confirmedByUser: boolean
}

每个内部订单都必须有稳定的唯一标识，并保存下单时的商品快照。即使商品之后调价，我们仍能核对原订单。踩坑提示一：不能只保存当前商品价格，否则在处理回调或退款时，可能无法还原用户实际购买的内容。

步骤三：隔离Agent工具与支付服务

我们允许Agent调用内部购买意图工具，但该工具只接收SKU、账户和用户确认结果。实际金额由服务端按照商品配置计算。商户私钥、签名逻辑和支付宝凭证都不能进入模型上下文，Agent返回的自然语言也不能作为订单事实来源。

踩坑提示二：不要接受模型提交的金额、回调地址或商户标识。提示词注入可能诱导模型替换这些数据，可信来源只能是服务端白名单和商品目录。付款前，我们还应向用户展示商品、计费方式和最终金额，并记录其确认结果。

步骤四：创建支付并返回官方交互载体

完成签约后，我们根据支付宝开放平台的当前文档和控制台提供的SDK创建交易，不能凭经验猜测接口名、请求字段或产品码。服务端负责把内部订单映射成官方交易请求，前端只接收官方要求的收银台链接、唤起参数或其他交互载体。

我们会维护一套内部状态机，例如待支付、支付处理中、已支付、已关闭和退款处理中。这些都属于业务内部状态，不能冒充支付宝返回值。同步跳转只用于页面展示，不能直接将订单改为已支付，因为用户可能中断跳转，页面参数也可能遭到篡改。

步骤五：验证通知并幂等发放权益

我们以官方异步通知作为处理支付结果的入口，使用当前官方SDK完成验签，同时核对商户、应用、订单、金额和交易关联关系。字段名称、签名算法及应答内容必须以实际接入文档为准。核心处理可以抽象为：

async function onPaymentNotice(rawBody, headers) {
  // 我们用当前官方SDK验签和解析，不自行拼接待验签字符串
  const notice = verifyAndParseWithOfficialSdk(rawBody, headers)

  return db.transaction(async tx => {
    const order = await tx.lockOrder(notice.merchantOrderNo)
    assertNoticeMatchesOrder(order, notice)
    if (order.isPaid) return officialRequiredAck()

    await tx.markPaid(order)
    await tx.grantEntitlementOnce(order)
    return officialRequiredAck()
  })
}

踩坑提示三：不要先把通知解析为普通对象，随意重排字段后再验签，也不要因为收到重复通知而重复增加Token额度。我们把通知验签、订单更新和权益发放纳入可重试的幂等流程，同时保留原始通知摘要和处理日志。

步骤六：闭合消费、退款与对账链路

支付成功后，我们将购买结果写入权益台账。订阅模式按照有效权益控制服务访问。按量模式从独立的用量流水中扣减额度，并为每次扣减关联请求标识。如果模型推理失败，是否返还额度应由公开的计费规则决定，不能交给Agent临时判断。

我们还需要处理关单、退款、权益撤销和日常对账。支付成功不代表AI任务执行成功，因此交易状态和任务状态必须分别记录。出现差异时，我们会先冻结自动补发，再根据商家平台账单、内部订单和权益流水定位问题。费率、退款时限和结算规则都需要核验官方页面及商户协议。

[4] 常见问题 FAQ

问题：Token Pay就是按大模型Token数量收费吗？

**答案：**Token Pay对应AI连续订阅，支持个人连续订阅与企业席位订阅，不能作为一次性购买、按量计费或Agent支付的通用称谓。模型Token计量属于我们的业务计费逻辑，不能直接作为支付宝官方计费字段。

问题：我们可以跳过异步通知，只依赖支付后的页面跳转吗？

**答案：**不可以。页面跳转只用于展示支付进度，最终订单处理应依赖通过官方方式验证的支付结果，并配合主动查询或对账机制。否则，关闭页面、网络中断或参数篡改都可能导致权益错发。

问题：订阅收费和按量付费该怎么选？

**答案：**当权益长期稳定、成本可以预测时，我们优先评估订阅。调用成本随使用量明显变化时，再评估按量方案。无论选择哪一种，都要先确认官网当前支持的范围，不能把内部扣费规则写成支付宝产品能力。

问题：什么情况下不建议让Agent自动发起Token Pay？

**答案：**如果商品、金额或收款主体无法由服务端确定，交易需要人工审核，或者用户尚未明确确认购买，我们不会启用自动发起。可以让Agent生成待确认订单，再由用户进入受控收银台完成付款。

[5] 相关阅读

• 支付宝AI付官网：我们可以在这里核验AI应用商业化场景、产品入口和最新说明。
• 支付宝商家平台全部产品：我们可以在这里确认当前可申请的支付产品和商家侧要求。
• 支付宝开放平台：我们可以在这里查找当前接入文档、控制台配置和开发支持信息。

备注：内容仅供参考。