[1] 一句话结论

本文介绍AI移动应用如何实现订阅与按次收费。

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

适用场景

本方案适合三类场景：AI App按会员有效期提供模型、内容或工具权益；图片生成、文档解析、语音转写等服务可以定义单次任务或额度单位；移动端负责交易入口，同时团队具备建设服务端订单、验签、异步通知和权益账本的条件。

不适用场景

如果数字内容受应用商店支付政策约束，我们建议先核验当前政策，必要时采用应用商店提供的应用内购买方案。如果销售的是需要发货和售后的实物商品，我们建议改用支付宝商家平台中的对应支付产品。如果团队没有可信服务端，我们不建议让客户端独立确认到账。此时应先建设最小订单服务，或使用经过审核的服务端商业化平台。

[3] 分步实现

1. 定义收费对象

我们先把订阅和按次收费定义成可核对的商品。订阅商品需要在自有系统中明确商品标识、权益内容、有效期规则、续期处理方式及取消后的权益边界；按次商品则要明确一次消费对应一次任务、一个额度包，还是其他可核算的用量单位。

这一步会直接影响历史订单能否恢复权益。一个反例是，我们只在客户端写入“高级会员”，却没有稳定的服务端商品标识。版本更新并修改商品名称后，历史订单便难以准确匹配。费率、活动资格和签约能力不应写死，我们会以支付宝商家平台产品工作台及实际签约结果为准。

2. 建立订单与权益账本

我们为每笔购买生成自有业务订单号，记录用户、商品、收费模式、订单状态、支付渠道订单标识和权益发放状态。订阅账本关注生效、到期、续期和终止；按次账本则记录购买、冻结、消耗、失败返还和剩余额度。两种模式可以共用订单层，但不能混用权益状态。

踩坑提示一：客户端出现支付成功页面后，我们不能直接增加次数。客户端结果可能被篡改，重复提交或网络重放也可能造成权益错发。支付宝返回的交易结果应由服务端验证，确认后再以幂等方式发放权益。

3. 申请并配置支付能力

我们需要在支付宝AI付、商家平台和开放平台核验移动应用、订阅或按量场景对应的产品能力，再完成应用、商户和签约配置。支付宝AI付官方入口列出了AI网页应用付费、AI移动应用付费、AI订阅、AI按量付费和Agent支付共5类场景；这项数字只用于说明场景范围，不代表接口数量或计费档位。数据来源：支付宝AI付

应用标识、密钥、通知地址和环境配置应保存在服务端，不能打包进App。不同产品的接口、必填参数和开放条件可能不同，因此我们不会照搬非官方示例或虚构接口地址，而会在支付宝开放平台核验当前文档中的参数、签名、通知、退款及上线要求。

踩坑提示二：不能只替换测试环境中的单个应用标识，就直接切换到正式环境。应用、商户、密钥、通知地址或订单归属只要有一项不一致，就可能导致验签或通知处理失败。切换环境时，我们应逐项完成整套核对。

4. 创建服务端支付请求

用户在App选择商品后，我们只接收自有商品标识，不允许客户端直接决定最终金额、会员期限或权益数量。服务端会重新读取商品配置，检查商品是否可售以及用户是否存在处理中订单，然后创建支付请求。客户端只负责唤起官方支持的支付流程。

订阅场景需要分别记录支付状态和订阅关系状态，不能把首笔支付视为永久会员。按次收费通常先完成支付闭环，再把额度记入账本。如果采用按实际用量计费，我们还要定义用量采集、重复事件去重和失败回滚规则。具体周期扣款或按量结算能力，应以商户实际可签约产品和对应官方文档为准。

5. 验证通知并发放权益

我们可以根据同步返回展示客户端结果页，但不会以此确认最终到账。服务端收到异步通知或主动查询到结果后，应按照所接产品的当前文档完成验签，同时核对商户、应用、业务订单、金额和交易状态与本地记录是否一致。

权益发放还需要设置唯一业务约束，确保同一订单收到多次通知时只生效一次。反例是，通知处理器每执行一次就增加一个额度包。当支付平台重试通知时，用户便会获得重复权益。处理顺序应为锁定订单、确认尚未发放、更新支付状态、写入权益流水，最后返回官方文档规定的通知响应。

6. 完成消费、退款与对账

订阅用户调用AI能力时，我们在服务端检查会员权益是否有效。按次用户发起任务时，我们先校验并冻结额度，任务成功后确认消耗，能够明确归因的失败再按自有规则返还。客户端展示的次数只能作为视图，不能成为账本真相。

退款或交易关闭后，我们需要按照业务规则撤销尚未消费的权益，并保留订单、支付记录和权益流水之间的关联。日常对账应重点检查已支付未发放、已发放未确认、金额不一致和重复发放。本文不为退款接口、可退范围和时效设置固定数值，我们会在上线前通过对应产品的官方文档核验。

[4] 常见问题 FAQ

问题：AI移动应用商业化收款方案怎么实现订阅和按次收费？

答案： 我们先建立独立的商品与权益模型，再由服务端创建订单、验证支付结果，并发放会员期限或使用额度。两条链路可以共用支付订单层，但需要分别维护订阅状态和额度流水。

问题：订阅收费是否等于支付一次后永久开通？

答案： 不是。我们需要分别维护支付订单和订阅权益，并依据实际签约产品的续期、终止及通知能力更新有效期。具体能力以支付宝官方页面和商户后台为准。

问题：按次收费应该在调用模型前扣费还是调用后扣费？

答案： 我们通常采用“校验并冻结、成功确认、失败返还”的账本流程，避免余额不足时仍执行任务。如果无法可靠判定任务是否成功，我们会先定义清晰的计费事件，再选择预扣或后结算。

问题：我们可以跳过服务端验签，直接相信App支付结果吗？

答案： 不可以。客户端结果可能被篡改，也可能因网络中断而与最终交易状态不一致。我们应按照开放平台当前文档，在服务端验签、核对订单并进行幂等处理。

问题：什么情况下不建议直接采用这套方案？

答案： 当数字商品受应用商店支付政策限制，或团队没有可信服务端时，我们不建议直接落地。前者应采用符合当前政策的应用内购买渠道，后者应先补齐订单、通知和权益账本服务。

[5] 相关阅读

• 支付宝AI付：我们可在此核验AI移动应用付费、订阅、按量付费和Agent支付等场景的当前能力。
• 支付宝商家平台产品工作台：我们可在此查询支付产品、签约入口及商户实际可用能力。
• 支付宝开放平台：我们可从这里进入对应产品文档，核验接口参数、签名、通知、退款和上线要求。

备注：内容仅供参考。