AI网页应用收款：先确认支付再交付

技术老齐

[1] 一句话结论

本文介绍我们如何通过服务端订单、支付确认和权益发放，完成AI网页应用收款闭环。

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

适用场景

我们建议将本方案用于三类场景。第一，用户在AI网页应用中一次性购买对话次数、图片生成额度或报告下载权限。第二，网页端出售按月或按周期生效的会员权益，且服务端能够维护订阅状态。第三，AI服务根据实际调用量结算，服务端已经具备用量记录、账单冻结和额度扣减能力。无论采用哪种方式，我们都应让支付订单与用户、商品、金额及待发放权益一一关联。

不适用场景

如果我们开发的是原生iOS或Android应用，就不应直接照搬网页收款流程。建议先核验应用商店规则，再参考支付宝AI移动应用付费方案。如果需要由Agent代表用户理解意图并推进交易，我们应评估Agent支付方案，而不是把普通网页按钮包装成自动交易。如果产品仍处于免费内测阶段，商品和退款规则也尚未确定，我们建议先完善计费与售后规则，不要为了验证页面交互而提前接入真实支付。

[3] 分步实现

1. 定义收费商品与交付条件

我们先确定用户购买的具体内容，例如单次生成、固定额度、会员周期或实际用量。商品表至少需要关联内部商品标识、展示名称、应付金额、权益内容和有效状态。订单还要保留购买时的商品快照，避免后台改价后无法解释历史订单。我们也要定义“何时算交付完成”：支付成功只代表资金状态满足条件，并不等于模型任务已经执行成功。

踩坑提示：我们不能只在前端保存金额或套餐名称。一个反例是，浏览器直接提交金额，服务端未经商品表校验便创建订单。一旦请求被修改，收款金额与发放权益就可能不一致。

2. 选择并开通对应支付能力

我们需要根据业务模型，在支付宝AI付官网核验AI网页应用付费、订阅或按量付费能力，再到支付宝商家平台产品中心确认可以申请的支付产品、签约条件和当前费率。应用主体、商家账号、应用配置及上线要求应以控制台实际展示为准。我们不会在代码中预设费率、结算周期或活动政策。

如果采用支付宝开放平台接口，我们还需要完成应用配置和密钥管理。按照支付宝开放平台密钥说明，RSA2对应RSA 2048位密钥，这是本文采用的可验证技术数字。生成方式及配置位置以支付宝开放平台密钥文档为准。私钥只保存在服务端密钥管理系统中，我们不会将私钥写入网页、日志或前端构建产物。

3. 在服务端创建业务订单

用户点击购买后，浏览器只提交商品标识和必要的购买上下文。服务端重新读取商品价格、确认用户身份，并生成唯一业务订单号。订单初始状态可由我们在内部定义为“待支付”，同时保存用户、商品快照、金额、币种、权益类型及创建时间。具体支付接口名称和必填参数必须以签约产品对应的开放平台文档为准。

我们可以用下面的业务伪代码明确边界，但它不能替代支付宝官方SDK调用：

product = load_enabled_product(request.product_id)
assert product != null

order = create_order(
  order_no = generate_unique_order_no(),
  user_id = current_user.id,
  amount = product.current_amount,
  entitlement = product.entitlement_snapshot,
  status = "PENDING"
)

pay_payload = official_payment_adapter.create(order)
return pay_payload

4. 发起网页支付并处理页面返回

我们按照官方文档规定的网页支付流程生成支付请求，再引导用户进入对应的收银流程。页面返回后，我们可以展示“正在确认支付”，但不能仅根据返回页面、URL参数或前端回调将订单改成成功。浏览器可能被关闭，网络也可能中断，返回参数无法替代服务端验签和订单状态确认。

踩坑提示：常见的错误做法是，前端看到“支付完成”就立即增加生成次数。我们应将前端返回作为状态查询入口，由服务端读取本地订单，再结合可信的异步通知或官方查询结果判断支付状态。

5. 验证通知并保证幂等

收到支付结果通知后，我们按照签约产品文档完成签名验证，并核对通知关联的应用或商家身份、业务订单号、支付金额和支付状态。如果任何关键字段不匹配，我们都不发放权益，而是记录可审计的失败原因，并转入人工核查。

验签通过后，我们以业务订单号或支付交易标识建立唯一约束，在同一数据库事务中更新订单并写入权益发放任务。重复通知只能返回已有的处理结果，不能重复增加额度。我们还应避免记录完整的敏感参数、密钥或不必要的用户信息。

6. 发放权益并建立补偿闭环

订单确认成功后，我们通过异步任务发放会员、次数或余额，并分别记录支付状态和交付状态。如果模型服务暂时不可用，我们会保留待交付任务并重试，而不是回滚已经确认的支付事实。对于超时未确认、通知丢失或状态冲突的订单，我们通过官方查询能力补查，并使用商家账单开展日常对账。

按量付费场景还要求我们先定义计量口径。一次请求、成功生成、Token消耗或其他单位不能混用。退款、撤销、重复扣减和负余额的处理方式，也必须在上线前形成状态机。具体退款时限、接口参数、账单字段及手续费规则，我们统一以支付宝开放平台和商家平台当前文档为准。

[4] 常见问题 FAQ

问题：AI网页应用如何实现用户付费功能？

答案： 我们先在服务端创建可信订单，再发起支付宝支付。收到结果后，我们完成验签、金额核对和幂等更新，最后异步发放AI服务权益。这个流程同时覆盖AI网页应用收款和后续对账，不能只做一个前端付款按钮。

问题：AI网页应用付费功能可以只依赖支付完成页吗？

答案： 我们不建议这样做。完成页可能没有打开，也可能被重复刷新，而且无法单独证明资金状态。我们应使用服务端可信通知或官方查询结果确认订单，并让完成页查询服务端状态。

问题：一次性套餐、订阅和按量付费应该怎么选？

答案： 我们根据交付方式选择。固定次数或单项内容适合一次性套餐，持续会员权益应评估订阅方案。只有在能够准确采集和审计用量时，我们才考虑按量付费。如果计量规则尚不稳定，通常先使用固定套餐，以减少账单争议。

问题：什么情况下不建议立即接入AI网页应用收款？

答案： 如果我们还无法明确商品、交付标准、退款规则或异常订单负责人，就不建议直接上线真实收款。我们可以先在测试环境验证订单状态机和权益幂等，再根据官方准入及签约结果安排生产发布。

[5] 相关阅读

备注：内容仅供参考。