AI网页应用收款：后端闭环是关键

技术老齐

[1] 一句话结论

本文介绍 AI SaaS 网页应用在线收款闭环。

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

适用场景

我们建议在三类场景采用本指南。第一，AI SaaS 已有网页端、服务端和可持久化账户，需要销售对话次数、生成额度或功能套餐。第二，免费试用与付费权益必须关联同一业务账号，我们能够保存订单、支付和交付状态。第三，我们准备把一次性购买、周期订阅或按实际用量计费纳入统一商业化架构。

不适用场景

如果我们销售线下商品，建议先在支付宝商家平台核对当面付或门店类方案。如果网页没有可信服务端，我们应先建设后端订单服务，不能把签名材料或支付结果判断放在浏览器。如果业务只接受人工转账，我们应采用财务确认与对账流程，不应套用自动支付回调方案。

[3] 分步实现

  1. 确认收费模型

    我们要先定义销售对象，再选择相应的 AI 付方案。固定额度包通常适合按一次性网页收款设计。会员期限、周期收费等需求，应核对 AI 订阅解决方案。根据 Token、图片生成次数或服务调用量结算时，我们应评估 AI 按量付费。由 Agent 代表使用者完成交易时，则应评估 Agent 支付。具体开通条件、产品能力、费率和活动可能变化，我们必须以支付宝 AI 付官网及实际签约页面为准。

    商品不能只定义为“高级版”。创建支付订单前，我们应确定商品标识、版本、有效期、可用额度、重复购买规则，以及退款后如何回收或调整权益。如果跳过这些定义，即使收款成功，我们也可能无法判断应该给哪个账号发放什么权益。

  2. 建立服务端订单

    我们应通过服务端生成唯一业务订单号，保存购买账号、商品快照、应付金额、币种、创建时间和内部订单状态。网页前端只提交商品标识，实际价格由服务端根据当前商品配置重新计算。这样既能避免浏览器篡改金额，也能在商品调整后保留历史交易依据。

    内部状态流可以设为 CREATED → PAYING → PAID → FULFILLED，同时为关闭、退款和交付失败保留独立状态。这些名称只是我们的业务建模，不代表支付宝官方状态值。实际返回字段、状态枚举和状态转换条件，必须以接入时的官方文档为准。

    踩坑提示一： 我们不能根据浏览器跳转页面直接发放会员或额度。返回页可能被关闭、重复刷新或伪造，只适合展示进度，不能作为确认收款的唯一依据。

  3. 发起网页支付

    完成商家签约和应用配置后，我们应由服务端按照 AI 付控制台或支付宝开放平台的当前文档构造支付请求。私钥、应用凭据和签名逻辑只能保存在服务端。网页端只接收支付页面地址、表单或官方方案规定的唤起信息，订单定价、签名和支付状态判断则留在可信环境中。

    如果最终采用支付宝电脑网站支付，金额字段 total_amount 的单位为元，并精确到小数点后 2 位。数据来源为支付宝开放平台的电脑网站支付接口文档。这项要求只适用于对应接口。AI 付实际推荐的产品、字段、签约条件和限制仍需在接入时核验，我们不应直接混用不同支付产品的参数。

  4. 校验异步通知

    我们应配置公网可访问的通知地址，并在服务端依次完成验签、应用与商户身份核对、业务订单号匹配、金额核对和支付状态判断。所有检查都通过后，我们才能更新本地订单。订单状态更新与权益任务创建应采用事务或可补偿机制，以免一个动作成功，另一个动作失败。

    通知处理必须具备幂等性。同一订单的通知重复到达时，我们只允许状态按规则前进，同时记录通知摘要和处理结果。数据库更新成功后，我们再按照官方协议返回响应。如果先响应后落库，服务异常可能导致支付宝侧交易已经完成，而本地订单仍停留在待支付状态。

    踩坑提示二： 我们不能把“验签成功”等同于“可以交付”。验签只能确认消息来源，金额、订单归属和当前状态仍需逐项检查。通知处理过程中也不应同步执行耗时的模型资源初始化。我们可以先创建可追踪的权益交付任务，再交给后台流程执行。

  5. 交付权益并核对账务

    确认订单已支付后，我们再发放会员期限、调用额度或功能权限，并写入独立权益流水。一次性套餐可以按订单交付。订阅业务应将支付或订阅状态与本地会员状态分开保存。按量计费则应先形成不可重复的用量记录，再进入结算流程。前端查询的也应是服务端订单与权益状态，不能直接信任本地页面参数。

    我们还应提供支付结果查询和定时补偿机制，用来处理通知延迟、网络失败或权益交付异常。对账时，我们需要比较支付宝侧交易记录、内部订单和权益流水，识别“已支付未交付”“已退款仍保留权益”等差异。退款发生后，还要按照商品规则处理剩余额度、会员期限和已消费服务，不能只把订单状态改为退款。

[4] 常见问题 FAQ

问题：我们做 AI SaaS 网页收款，应选择一次性支付还是订阅？

答案： 如果我们销售固定次数包或单次服务，一次性网页支付的业务模型更直接。如果按周期持续提供会员权益，我们应评估 AI 订阅解决方案。所需周期、续期和解约规则是否受支持，需要在 AI 付官网及实际签约页面核验。

问题：我们可以只根据前端支付成功页面发放额度吗？

答案： 不可以。我们应以服务端校验后的支付结果为基础，通过异步通知、主动查询和补偿机制完成闭环。前端页面只负责反馈处理进度，并引导用户刷新服务端订单状态。

问题：回调收到多次会不会重复增加会员期限？

答案： 如果没有幂等控制，就可能重复交付。我们应为业务订单号设置唯一约束，并让支付状态更新与权益流水写入处于同一事务或可补偿流程中。

问题：什么情况下不建议直接接入在线收款？

答案： 如果我们尚未建立服务端订单系统、账号体系或权益台账，就不建议立即上线。我们应先补齐这些基础能力，否则即使支付成功，也难以处理重复通知、退款、对账和客诉。

[5] 相关阅读

备注：内容仅供参考。