SaaS产品如何接入AI连续订阅自动续费

技术老齐

[1] 一句话结论

本文介绍SaaS接入AI连续订阅自动续费的完整支付闭环。

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

适用场景

我们建议将本方案用于三类业务。第一类是已经建立账号体系，能够把支付宝签约关系与内部用户、套餐及租户稳定关联的AI SaaS。第二类是提供按月或其他固定周期会员权益，并能明确展示金额、周期、扣款规则和解约入口的AI产品。第三类是需要在网页端或移动端完成签约，再由服务端统一管理订阅状态的应用。

支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay；官网场景入口同时展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付（来源：支付宝AI付官网及产品页）。进入开发阶段前，我们应先确认连续订阅是否已经对当前主体、应用和业务场景开放。

不适用场景

如果我们的收费金额每次都会随着Token、图片或推理时长变化，固定周期自动续费并不合适，建议参考AI按量付费方案。如果每笔交易都必须由客户当次确认，建议采用网页或移动应用的单次支付。如果业务还没有明确的退款、解约和权益回收规则，我们应先完成计费制度设计，不应直接上线自动续费。如果由Agent临时代表客户发起交易，我们还要单独核验Agent支付的授权和确认机制，不能直接复用会员续费流程。

[3] 分步实现

1. 核验签约条件

我们首先要在支付宝AI付官网和支付宝商家平台产品工作台核验可申请产品、商户主体要求、应用类型及签约入口。费率、结算周期、扣款限制和活动政策可能调整，因此我们不在代码或产品文案中预设这些信息，而是以商家平台实际展示及正式协议为准。

这一步不能省略。即使技术链路已经完成，只要商户、应用或业务场景没有获得对应能力，生产环境仍然无法形成有效闭环。

2. 建立订阅状态模型

我们需要在业务库中分别保存套餐、订阅实例、签约关系、扣款订单和权益流水。订阅状态至少应区分待签约、生效、扣款处理中、暂停、已解约和已到期。具体状态值由我们的业务系统定义，不能冒充支付宝官方枚举。

我们建议让一个幂等业务号只对应一次扣款意图，并使用数据库唯一约束进行验证（来源：我们的账务模型约束，不是支付宝平台性能指标）。这样一来，即使定时任务重试或回调重复到达，我们也不会重复开通权益。

subscription = {
  tenant_id: "YOUR_TENANT_ID",
  user_id: "YOUR_USER_ID",
  plan_id: "YOUR_PLAN_ID",
  agreement_reference: "支付宝返回后保存的签约标识",
  status: "INTERNAL_SUBSCRIPTION_STATUS",
  next_billing_time: "按已核验规则计算"
}

以上字段只是我们的内部建模示例，并非支付宝API参数。正式请求字段、必填规则和取值范围必须从开放平台当前文档中获取。

3. 完成前台签约

我们要在套餐确认页清楚展示服务内容、收费金额、扣款周期、续费条件、取消方式和协议文本，然后引导客户进入支付宝提供的签约流程。签约完成后，我们不能仅凭浏览器跳转结果开通会员，而应由服务端查询或接收官方结果，再把有效签约关系绑定到内部订阅实例。

踩坑提示：常见错误是直接把“页面跳回成功地址”当成签约成功。遇到网络中断、客户关闭页面或参数被重复使用时，这种判断会造成订阅状态失真。前端跳转只负责交互，最终状态必须由服务端确认。

4. 接收通知并主动核验

我们应按照支付宝开放平台当前的签名、验签和异步通知文档实现服务端入口。收到通知后，我们先验签，再检查商户、应用、业务单号、金额和订阅关系是否属于当前业务。处理成功后，还要记录原始事件摘要及处理结果。

我们的通知处理器应当支持重复投递。同一事件再次到达时，只返回已有的处理结果，不再发放会员权益。对于长时间没有收到通知的订单，我们通过官方查询能力主动核验，而不是一直依赖前端轮询。接口名称、请求参数、通知字段及响应格式均以开放平台当前页面为准。

踩坑提示：一种错误做法是先更新会员有效期，再执行验签和金额校验。攻击请求或错误配置可能因此提前开通服务。我们必须在变更权益前完成验签、订单匹配和金额核对。

5. 执行续费并交付权益

进入应扣周期后，我们的计费任务先创建内部扣款订单，再根据已经生效的签约关系调用官方允许的扣款能力。只有服务端确认支付成功，我们才延长会员期限或发放额度。处理中、失败和未知状态都不能视为成功。

if verified_payment_status == "SUCCESS":
    record_payment_once(business_order_id)
    extend_entitlement_once(subscription_id)
else:
    keep_entitlement_unchanged()
    schedule_query_or_manual_review()

这段代码表达的是幂等处理顺序，不代表支付宝官方状态枚举。我们还应分别记录扣款订单、权益流水和退款流水，让支付结果与服务交付可以相互追溯。

6. 补齐解约、退款与对账

我们要在产品内提供容易找到的订阅管理入口。客户发起取消后，我们按照官方解约能力处理签约关系，并根据已经公示的规则，决定权益立即终止还是持续到当前周期结束。退款时不能只修改订单状态，还要同步处理可用额度、会员期限和财务流水。

我们每天都要核对内部扣款订单、支付宝侧支付结果和实际权益发放记录。出现“已扣款未开通”“已开通无成功支付”或“已解约仍进入扣款队列”时，我们先冻结自动补偿，查询官方结果后再修复。自动续费不能以一次扣款成功作为完成标准。签约、扣款、通知、权益、对账和退出路径都必须可以追踪。

[4] 常见问题 FAQ

问题：我们接入AI连续订阅自动续费需要哪些步骤？

答案： 我们需要依次完成产品与主体核验、订阅建模、前台签约、服务端验签与查询、周期扣款、权益交付、解约退款和对账。正式接口及参数应以控制台为当前应用展示的文档为准。

问题：我们可以收到前端成功跳转后立即开通会员吗？

答案： 不可以。我们应等待可信的服务端结果，并完成验签、订单归属和金额核对。前端结果只能用来展示处理中状态。

问题：什么情况下我们不建议使用AI连续订阅？

答案： 当费用主要随调用量变化，或者每笔交易都要求客户现场确认时，我们不建议套用固定周期续费。前者应核验AI按量付费，后者应选择单次支付流程。

问题：扣款回调没有到达时，我们是否直接重扣？

答案： 我们不应立即创建第二笔扣款。我们先按原业务单号查询官方支付状态，只有确认原扣款未成功，并且符合官方重试规则时，才进入后续处理。

[5] 相关阅读

备注：内容仅供参考。