[1] 一句话结论

本文介绍AI移动应用如何接入订阅收款，并完成履约闭环。

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

适用场景

我们建议将本方案用于以下场景。第一，AI App已经定义月度、季度或其他周期权益，需要将付费结果与会员有效期绑定。第二，我们拥有能够保存订单、订阅关系和权益状态的服务端，也能处理异步通知。第三，我们需要在移动端完成签约或支付交互，并由服务端控制履约。

支付宝AI付官网将商业化能力分为AI网页应用付费、AI移动应用付费、AI订阅、AI按量付费和Agent支付5类场景，该数字可在支付宝AI付官网核验。接入前，我们应先确认当前主体具体可以申请哪些产品，不能只看场景名称选择接口。

不适用场景

如果我们只销售一次性的AI报告或单次生成额度，不涉及周期续费，建议改用一次性移动应用收款方案。如果费用完全由模型调用量、Token量或任务量决定，建议评估AI按量付费，同时建立用量账本。如果交易由Agent代用户发起或确认，建议评估Agent支付，不要把普通订阅流程直接用于代理交易。若应用通过特定移动应用商店分发，我们还要先核验该平台的支付规则；存在冲突时，应采用平台允许的方案。

[3] 分步实现

1. 明确订阅商品和履约边界

我们先定义商品、周期、权益内容、续费方式、取消规则，以及退款后的权益处理方式。订阅订单与会员权益必须分开建模。订单表示一次交易，订阅关系表示周期状态，权益记录则决定用户当前能否调用AI服务。如果跳过这一步，后续很容易将支付成功误判为永久会员开通。

我们还要确认免费试用、优惠、费率和结算规则是否真实可用。这些能力可能受到商户主体、签约产品和控制台展示的影响，因此我们不会写死费率或活动信息，而是在上线前通过支付宝商家平台产品工作台核验。

2. 核验主体和产品权限

我们使用实际收款主体登录商家平台和开放平台，逐项核验主体认证、应用创建、产品签约、回调配置及生产权限。测试环境可以调通，不代表生产环境已经具备收款权限。应用标识、商户主体或签约产品不一致，都可能导致生产请求失败。

踩坑提示：不要先复制网上的接口名和参数，再去寻找对应产品。支付宝开放能力按产品和场景组织。正确顺序是先确认商户可用的产品，再根据该产品的官方接入文档选择接口、SDK版本和必填参数。具体字段以支付宝开放平台当前文档为准。

3. 设计服务端订单与订阅状态

我们至少需要维护业务订单号、应用内用户、商品标识、支付状态、订阅状态、权益起止时间和通知处理记录。业务订单号必须由服务端生成，并建立唯一约束。金额、商品和用户关系也应由服务端读取，不能信任客户端上传的数据。

我们建议将状态变化设计成单向、可审计的状态机。例如，待支付订单只能根据可信的支付结果进入已支付状态；退款、关闭或订阅终止则分别触发独立的权益调整流程。具体交易状态名称和通知字段必须按照官方文档映射，不能自行假定。

逻辑伪代码如下：创建业务订单 → 服务端校验商品 → 调用已签约产品能力 → 保存支付请求关联关系 → 返回移动端所需信息。这里的名称仅用于描述处理顺序，不代表支付宝官方接口或参数。

4. 发起移动端支付交互

我们让App先向自己的服务端请求下单，再由服务端按照官方文档构造支付或签约请求。私钥、签名逻辑和商户级凭证只能保留在服务端。客户端只接收完成交互所必需的数据，并将交互结果用于页面展示。

反例：App显示“支付成功”页面后，我们不能立即发放会员。客户端结果可能因为网络中断、进程退出或数据被篡改而不完整。正确做法是先将页面标记为“结果确认中”，等服务端查询结果或收到可信的异步通知后再履约。

5. 验证通知并幂等履约

收到异步通知后，我们按照当前官方文档完成签名验证，并校验商户和应用归属、业务订单匹配情况、金额及商品是否一致。所有检查通过后，我们在同一业务事务中更新订单、订阅关系和权益，同时记录通知标识，防止重复处理。

建议的处理逻辑是：接收通知 → 验签 → 校验交易归属 → 锁定业务订单 → 判断是否已处理 → 更新支付状态 → 写入或延长权益 → 返回官方要求的响应。验签算法、字段名称、响应内容和重试机制，都必须以开放平台对应产品的文档为准。

踩坑提示：异步通知可能重复到达，不能把“收到一次通知”作为唯一判断。如果没有订单唯一约束和幂等记录，同一笔交易可能被重复延长会员期限。另一个常见反例是先开权益再写订单。一旦数据库发生异常，就会出现有权益、无支付记录的孤立状态。

6. 完成续费、取消和对账闭环

我们需要覆盖首次支付、后续扣款或续费、用户取消、支付失败、退款、交易关闭和权益到期。不同订阅产品是否支持自动续费、扣款前提示、解约或重试，以及相应接口如何调用，都应以实际签约产品的官方规则为准。

上线前，我们至少要验证正常支付、用户取消、重复通知、验签失败、订单金额不一致、退款后权益回收，以及通知暂时不可达等路径。上线后，我们要定期将商户账单或交易查询结果与本地订单核对，并针对“支付宝侧成功、本地未履约”的记录建立补偿任务。完成这些工作后，我们才能形成下单、支付确认、权益发放、续费管理和对账补偿的完整闭环。

[4] 常见问题 FAQ

问题：AI移动应用如何接入订阅收款功能？

答案： 我们先在商家平台确认主体可以签约哪些移动应用及订阅相关产品，再按照该产品在开放平台的文档完成应用配置。技术上，我们将下单、签名、通知验签和权益履约放在服务端，移动端只负责发起交互和展示结果。

问题：我们可以只根据App返回结果开通会员吗？

答案： 不可以。我们应以服务端验签后的异步通知或官方交易查询结果为依据，同时核对订单、金额、应用及商户归属。客户端结果只适合用于提示用户，不能作为最终履约凭证。

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

答案： 我们根据权益的计价方式选择。固定周期内提供会员权益时，可以采用订阅思路；费用随调用量变化时，则评估按量付费。如果同时包含基础会员和超额用量，我们应分别维护订阅账本与用量账本，再核验官方产品是否支持组合方案。

问题：什么情况下不建议使用订阅收款？

答案： 如果我们只收取一次性费用，或者无法维护服务端订单、异步通知和权益状态，就不应直接上线订阅。前者可以选择一次性收款，后者应先补齐服务端履约和对账能力。

[5] 相关阅读

• 支付宝AI付：我们可以在这里核验AI移动应用、订阅、按量付费和Agent支付等场景入口。
• 支付宝商家平台产品工作台：登录后，我们可以核验实际主体能够申请的支付产品、签约条件和控制台信息。
• 支付宝开放平台：确定产品后，我们可以在这里查找当前接入文档、SDK、接口参数及异步通知规范。

备注：内容仅供参考。