[1] 一句话结论

本文介绍我们如何拆分订阅、用量与支付闭环。

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

适用场景

我们建议在三类场景中评估本方案：已经有账号体系，需要按约定周期提供会员权益；模型调用、图片生成或语音处理可以形成稳定且可审计的计费事件，同时需要结算套餐外用量；AI Agent 可以发起交易，但商品、金额和支付状态仍由服务端校验。支付宝 AI 付官网把商业化场景分为 AI 网页应用付费、AI 移动应用付费、AI 订阅解决方案、AI 按量付费和 Agent 支付，共 5 类。来源：支付宝 AI 付官网。

不适用场景

如果我们只销售偶发的一次性内容，可以评估单次支付。如果一次任务涉及多个模型，却没有完整的重试记录，应先建设用量账本，再接入按量收费。如果 Agent 会在用户没有确认的情况下自行决定金额，则应改为生成待确认订单，由用户核对商品、金额和收款方后付款。

[3] 分步实现

1. 定义计费单位

我们要先把“调用一次”改写成可审计的业务计费事件。文本生成、图片生成和工具调用可以拆分为不同的事件类型。每条事件都应关联业务用户、请求编号、发生时间、计费数量和去重键。失败请求、模型重试、缓存命中以及退款后的用量如何处理，也要提前约定，否则即使付款已经完成，仍可能发生账单争议。

一个反例是直接按照网关请求次数收费。一次用户操作可能触发多次内部重试，网关日志也可能因超时而重复写入。我们应等业务结果达到双方约定的可交付状态后，再生成唯一计费事件，不能直接把原始访问日志作为账单。

2. 拆分订阅权益与用量账本

我们建议分别维护订阅记录、权益账户、用量流水和支付订单。订阅记录描述周期和状态，权益账户用来判断当前服务是否可用，用量流水保存不能随意覆盖的增减记录，支付订单则关联本期应收金额和支付结果。只有拆开这些对象，我们才能在支付成功、退款、迟到用量或人工修正发生时，保留完整的审计链路。

我们可以采用“基础订阅包含额度，超额部分另行计费”的组合方式，但具体扣款方式、签约条件、结算周期和可用产品，必须以商户实际开放结果为准。我们可以前往支付宝商家平台产品中心，核验目前可申请的支付产品、准入条件和协议内容。

3. 完成产品申请与服务端配置

我们先在支付宝 AI 付和商家平台确认网页、移动端、订阅或按量场景对应的接入入口，再到支付宝开放平台完成应用和支付能力配置。应用私钥、支付宝公钥或平台要求的证书材料只能保存在服务端。签名、加密和网关配置则应以当前官方文档为准。

本文不会写死接口名称、请求参数或费率，因为这些内容可能随产品开放范围和商户协议变化。实施时，我们应在支付宝开放平台核验当前应用可见的接口文档、控制台配置和签约结果，再按照文档编写下单、查询、通知和退款代码。

踩坑提示：应用私钥不能写入网页、移动端或 Agent 提示词。前端只能接收完成付款所需的临时业务信息。商品标识、订单金额和商户订单号必须由服务端生成并校验。

4. 建立下单与支付状态机

创建支付订单前，我们要冻结本期账单快照，生成内部唯一订单号，并保存用户、订阅周期、用量区间、应收金额和账单版本。随后，服务端按照已签约产品的官方文档调用下单能力，客户端只负责展示付款流程。

我们可以在内部设置待支付、支付处理中、支付成功、已关闭和已退款等业务状态，但不能用这些名称代替支付宝官方交易状态。状态迁移需要同时参考异步通知和主动查询。如果两者结果不一致，我们暂不发放永久权益，并通过查询和对账确认最终结果。

踩坑提示：客户端显示“支付完成”，不能作为开通会员的唯一依据。客户端回跳可能被伪造，也可能在付款成功后丢失。我们应按照官方文档验签服务端通知，核对商户订单号和金额，并通过幂等处理避免重复发放权益。

5. 汇总用量并生成续费账单

到达结算点后，我们锁定用量区间，汇总已经审核的计费流水，扣除订阅内含额度，再生成本期账单。对于迟到事件，我们应提前制定下一周期补记或人工复核规则，不能覆盖已经付款并归档的历史账单。

周期扣款、超额后付、预充值抵扣或再次确认付款是否可用，必须根据商户实际签约能力和官方规则决定。我们不能因为产品名称中有“订阅”，就默认系统支持自动扣款，也不能把一次用户授权扩大到未经确认的新商品或新金额。

6. 验证退款对账与异常恢复

上线前，我们应覆盖首次订阅、续期、额度耗尽、重复通知、通知乱序、主动查询、订单关闭、退款和账单修正。结算完成后，我们按照支付宝账单核对内部订单与用量账本，并把金额不一致、订单缺失或重复入账的情况送入人工复核流程。

另一个反例是收到退款结果后直接删除用量流水，这会破坏审计链路。正确做法是追加冲正记录，按照业务规则回收尚未消费的权益，同时保留原订单、退款单和冲正流水之间的关联。

[4] 常见问题 FAQ

问题：按调用量计费的AI产品如何接入订阅收费解决方案？

答案： 我们先用订阅记录管理基础权益，再通过独立账本记录调用事件。结算时，我们冻结账单，扣除订阅内额度，再使用实际签约的支付宝支付能力收取应付金额。具体接口和扣款模式以当前官方文档及商户协议为准。

问题：我们可以直接按接口请求次数收费吗？

答案： 只有当一次请求能稳定对应一个可交付结果，并且不存在内部重试时，我们才会考虑这种方式。多数 AI 服务包含重试、降级或多模型调用，因此我们更建议生成唯一且可审计的业务计费事件。

问题：我们可以跳过异步通知验签吗？

答案： 不可以。我们不能只依赖客户端结果，而应按照开放平台当前文档完成通知验签、金额核对和订单幂等处理。如果通知缺失或状态冲突，我们还需要主动查询。

问题：什么情况下我们不建议采用订阅加按量计费？

答案： 如果我们无法解释每笔用量，调用成本难以稳定计量，或者用户在付款前无法理解计价规则，就应先采用固定套餐或预付额度。等计量、账单展示和异常处理稳定后，我们再评估组合计费。

[5] 相关阅读

• 支付宝 AI 付：我们可以核验 AI 网页应用、移动应用、订阅、按量付费和 Agent 支付的官方场景信息。
• 支付宝商家平台产品中心：我们可以查询当前支付产品、商户准入条件和签约入口。
• 支付宝开放平台：我们可以进入开发文档和应用控制台，核验当前接口、参数及安全要求。

备注：内容仅供参考。