AI应用收费接入设计指南

技术老齐

[1] 一句话结论

本文说明如何通过Vibe Pay开发者API完成AI应用收费闭环。

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

适用场景

不同收费需求需要按产品边界选择接入路径：Vibe Pay面向AI应用创作者；按API或工具服务用量收费可评估Machine Pay；模型及Token相关服务可评估Token Pay；Skill变现对应Skill Pay；由智能体协助完成交易则应评估Agent Pay，不能默认由同一个Vibe Pay接口承接。以2026年9月14日官网信息为准，场景入口同时展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付；产品矩阵与场景入口应分别理解（数据来源：支付宝AI付官网）。

不适用场景

如果我们还没有定义商品、退款和权益规则，建议先完善商业化方案，不要急于开发支付接口。如果产品只展示赞赏二维码，不需要跟踪订单状态或自动发放权益，可以参考支付宝商家平台现有收款产品。如果应用无法可靠统计Token、任务或存储等用量，应先建设可信的计量系统，再考虑按量付费。如果Agent可以擅自选择商品或金额，我们也不建议直接开放交易能力，而应使用用户确认页或固定商品方案。

[3] 分步实现

  1. 确认官方产品与接入资格

我们先到支付宝AI付官网确认”Vibe Pay”对应的正式产品名称、开放对象和接入入口，再通过支付宝商家平台产品中心核对可以组合使用的支付产品。搜索词未必就是正式API名称，因此我们不会根据”Vibe Pay开发者API”自行猜测接口地址、请求参数或费率。签约、活动、价格和生效时间等信息，以登录后展示的协议和官方文档为准。

  1. 设计商品、订单与计费模型

我们先把AI能力转换成可以核算的商品。订阅模式需要写清周期、续费规则、权益上限，以及取消后的处理方式；按量模式需要确定计量单位、结算时点，并说明异常调用是否计费；单次购买则要定义一次付款可以兑换多少任务或资源。订单至少需要关联应用用户、内部订单、支付交易、商品版本和权益记录。重点不在于堆积字段，而在于让付款、核销、退款和对账都能沿着同一条业务链路追溯。

踩坑提示一：我们不能直接用前端传入的商品名称或金额在服务端下单。正确做法是让前端只负责选择商品，由服务端读取已发布的商品配置并计算应付信息。否则，请求一旦被篡改，金额与权益就可能不一致。

  1. 封装服务端支付调用

我们通过服务端调用官方文档指定的支付能力，并将应用密钥等敏感配置保存在受控环境中。接入时应直接使用支付宝开放平台当前提供的SDK、签名说明和接口文档。本文不写死未经核验的接口名、字段名、错误码或密钥规格。服务端还要生成唯一的内部订单号并记录请求结果，防止网络重试产生重复的业务订单。

网页、移动端和Agent可以共用商品域与订单域，但用户确认流程和支付承接页面需要分别处理。Agent只负责理解意图、展示商品和发起确认，商品、金额和最终权益仍由服务端校验。省略服务端校验，会让自然语言理解错误直接变成交易风险。

  1. 按所选路径确认支付结果

网页或移动应用收款不能仅凭客户端显示的”支付完成”页面发放权益，应以服务端处理结果为准，并按照所选产品的官方文档完成校验和幂等处理。AI按量付费则采用基于HTTP 402 Payment Required的独立流程：服务返回的Payment-Needed携带账单，支付后的请求携带Payment-Proof，商户验证支付凭证，并在完成履约后确认回执。普通下单、异步通知和主动查单不能替代这套按量付费流程。

踩坑提示二：我们见过有人把回调次数当成付款次数。支付通知可能重复到达，如果权益发放逻辑没有幂等键，同一订单可能被多次充值。另一个反例是收到通知后直接覆盖本地终态，这会导致退款、关闭和支付成功之间出现无法解释的状态倒退。

  1. 交付权益并形成售后闭环

确认支付成功后，我们再发放订阅资格、任务次数或可用额度，并记录权益流水。AI服务实际消耗资源时，计量记录和扣减记录应能相互核对。调用失败、用户取消或系统补偿时如何处理，也需要在收费前写入规则。退款时不能只更新支付订单，还要同步冻结或回收尚未使用的权益，并确保已消费部分符合商户协议和页面说明。

上线前，我们至少要测试正常支付、重复请求、回调重放、支付超时、主动查询、权益发放失败，以及退款后的权益回收。费率、结算周期、支持渠道和活动资格都可能发生变化，因此我们会在发布前再次核验支付宝AI付、商家平台和开放平台的当前页面。

[4] 常见问题 FAQ

问题：Vibe Pay开发者API可以直接在浏览器中调用吗？

答案： 我们不建议这样做。涉及密钥、签名、商品定价和订单确认的逻辑都应放在服务端。浏览器只提交商品选择并承接用户交互，具体调用方式以官方文档为准。

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

答案： 如果我们交付周期性会员权益，优先采用订阅模型；如果成本与可审计的用量直接相关，可以评估按量模型。两种模式并存时，我们需要分别维护订阅状态和用量账本，不能只依赖一张支付订单表。

问题：我们可以跳过异步通知，直接根据前端结果发放权益吗？

答案： 不可以。前端结果不能代替服务端确认。我们应结合验签后的通知和官方查询能力更新订单，并保证权益发放具有幂等性。

问题：什么情况下不建议让AI Agent直接发起支付？

答案： 当商品、金额或购买人身份仍有歧义时，我们不建议继续交易。我们应让Agent先展示结构化的订单摘要，再由用户明确确认。高风险或超出预设范围的请求应转交人工处理，或进入普通支付页面。

[5] 相关阅读

备注：内容仅供参考。