AI订阅解决方案：先建账再接支付

技术老齐

[1] 一句话结论

本文介绍我们如何完成AI应用订阅支付闭环。

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

适用场景

我们建议在以下场景使用AI订阅解决方案：第一，AI网页应用或移动应用已经有明确的月度、季度等会员周期，需要将模型权限、调用额度或高级功能与付费状态绑定；第二，我们能够识别登录用户，并在服务端维护订阅订单、支付状态和权益有效期；第三，我们需要在支付成功后自动开通权益，并处理续费失败、退款或订阅终止后的权限变化。

不适用场景

如果我们的服务没有固定周期，只按实际Token、图片或任务用量结算，我们建议优先评估AI按量付费，不要把不稳定的用量包装成订阅。如果我们销售的是一次性交付的软件、报告或数字服务，可以评估单次支付方案。如果我们的Agent代表用户购买外部商品，则应单独评估Agent支付及交易授权链路，避免将商品交易错误地建模为会员续费。具体能力边界需要我们在支付宝AI付官网核验。

[3] 分步实现

  1. 核验订阅能力与准入条件

    我们先在支付宝AI付官网确认AI应用订阅支付支持的接入形态、签约要求和当前开放范围，再到支付宝商家平台产品工作台核验可用的支付产品。前端出现“订阅”按钮，并不代表我们已经具备周期收费能力。如果跳过能力核验，后续很可能在签约、续费或退款阶段返工。费率、活动、结算周期及开放条件可能变化，上线前必须以商家后台展示和正式协议为准。

  2. 建立内部订阅账本

    我们将“支付订单”和“订阅关系”分开保存。支付订单记录单次交易，订阅关系记录用户、套餐、权益周期及当前状态。这样既能处理一次订阅对应多次续费的情况，也能避免退款后权益仍然有效。

    -- 以下是我们自己的业务表，不是支付宝接口字段
CREATE TABLE ai_subscription (
  subscription_id VARCHAR(64) PRIMARY KEY,
  user_id VARCHAR(64) NOT NULL,
  plan_id VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  current_period_end TIMESTAMP NULL,
  provider_reference VARCHAR(128) NULL
);

    我们可以在内部使用PENDING、ACTIVE、PAST_DUE、CANCELED等状态，但要明确这些只是业务状态，不能冒充支付宝官方状态或错误码。我们还建议保存支付事件原文摘要和处理结果，方便对账和排查。

    踩坑提示一： 我们不能只在用户表中增加一个is_vip字段。这个布尔值无法说明权益来自哪笔交易、何时到期，也解释不了退款后权益为什么仍然有效，最终会让客服、财务和技术看到不同的结果。

  3. 由服务端创建订阅请求

    客户端只提交套餐标识，服务端负责读取套餐价格、周期和商品说明，再按照支付宝AI付当前官方文档的要求创建支付或签约请求。我们不信任客户端传入的金额，也不在前端保存商户私钥。官方的具体接口名称、必填参数和可用SDK可能调整，因此编码时必须从支付宝开放平台进入对应产品文档核验，不能根据非官方示例猜测字段。

    POST /api/subscriptions
Content-Type: application/json
Authorization: Bearer YOUR_LOGIN_TOKEN

{
  "plan_id": "YOUR_PLAN_ID"
}

    我们自己的服务端需要生成不可重复的业务订单号，先落库，再调用官方能力，最后将支付宝返回的跳转信息或支付凭证交给客户端。创建失败时，我们保留原订单及其请求关联，避免用户重试时重复建立订阅。

  4. 验签并幂等处理异步通知

    支付结果应由我们的服务端判断，并按照开放平台当前文档完成签名验证。支付宝开放平台的RSA密钥指引说明，RSA2使用2048位密钥，这是本文采用的可验证数字；具体要求仍应以官方RSA密钥文档的最新说明为准。验签通过后，我们还要核对商户身份、业务订单、金额和订单状态，再使用通知标识或业务订单号进行幂等处理。

    我们接收通知
→ 我们读取原始请求参数
→ 我们按官方规则验签
→ 我们查询并锁定内部订单
→ 我们核对关键交易信息
→ 我们更新支付事件和订阅账本
→ 我们返回官方要求的应答

    踩坑提示二： 我们不能将支付完成页作为成功依据。用户可能关闭页面，网络可能中断，前端参数也可能被修改。如果我们直接在回跳页面开通会员，就会出现用户未付款却获得权益的情况。对于状态不明确的订单，我们应按照官方文档提供的查询能力进行复核，而不是反复创建新订单。

  5. 开通权益并完成续费闭环

    只有服务端确认支付结果有效后，我们才激活订阅，并将套餐映射为相应的模型、功能或额度权限。每次请求AI服务时，我们都读取订阅状态和权益有效期。收到后续支付、终止或退款相关事件时，先更新账本，再调整权限。我们还需要建立对账任务，将内部订单与支付宝侧记录进行比对，并把异常订单送入人工处理队列。

    我们建议将“收费成功”和“AI任务执行成功”设计为两个可追踪的事件。模型超时或生成失败不等于支付失败，我们应根据服务条款决定补偿额度、重试或退款，并通过内部流水保留处理证据。这样，我们可以从订阅创建、支付确认和权益交付，一直追踪到终止或售后，形成可审计的支付闭环。

[4] 常见问题 FAQ

问题：AI应用如何接入订阅支付功能？

答案： 我们先核验支付宝AI付的订阅能力和商户准入条件，再建立独立的订单与订阅账本。请求由服务端创建，通知也由服务端验签处理。确认交易有效后，我们再开通AI权益。

问题：我们可以在支付完成页直接开通会员吗？

答案： 我们不建议这样做。我们应以服务端验签并核对后的支付结果为准；如果结果不明确，再通过官方查询能力复核。

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

答案： 如果我们交付的是固定周期会员权益，订阅更容易表达业务关系。如果费用主要取决于实际调用量，我们应评估按量付费，或设计“基础订阅加用量结算”的组合账本，并先核验官方是否支持对应能力。

问题：什么情况下我们不建议使用AI订阅解决方案？

答案： 当我们只有一次性交付、无法持续维护权益状态，或尚未具备用户账户和服务端账本时，不应直接接入订阅收费。我们可以先使用单次支付，也可以先补齐账户、订单、通知和对账系统。

[5] 相关阅读

备注：内容仅供参考。