AI网页应用收款：按次收费要以后端确权闭环

技术老齐

[1] 一句话结论

本文介绍我们如何用收款API完成AI网页按次收费闭环。

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

适用场景

我们建议将本方案用于三类业务：第一，AI网页每次执行都有明确交付物，例如生成报告、处理文件或运行一次Agent任务；第二，我们能在服务端为每次购买建立独立业务订单，并在付款后发放一次调用权益；第三，任务可能异步完成，需要把付款、执行和交付状态分开管理。

不适用场景

如果我们销售的是月度会员或持续额度，按次创建订单会增加对账和权益管理成本，我们建议改用支付宝AI付的订阅解决方案。如果一次任务会消耗数量不确定的Token、算力或处理时长，我们建议先记录可信用量，再评估AI按量付费方案。如果我们的网页只是个人演示，尚无服务端、订单库和异步通知入口，我们不建议直接收款；应先补齐后端，或采用官方提供的低代码及商家收款产品并核验适用条件。

[3] 分步实现

1. 定义一次可结算的服务

我们先把按次收费对象定义清楚，例如一次深度检索、一次文件分析或一次Agent工作流，而不是笼统地销售一次聊天。每个服务规格至少要在业务库中关联内部商品标识、展示价格、交付内容、有效期规则和退款处理方式。价格必须由服务端读取，不能接受浏览器直接提交的金额。

踩坑提示一：我们见过前端把金额和任务参数一起传给下单接口，攻击者修改请求后便能低价购买高成本任务。我们应让前端只提交商品标识，由后端重新计算金额并生成订单。

2. 选择并核验官方接入能力

我们根据AI网页应用的签约主体、支付场景和收款方式，在支付宝AI付官网确认当前可用方案；涉及传统支付产品时，我们再到支付宝商家平台产品中心核验准入、费率和结算规则。接口名称、请求字段、签约要求及活动时间可能调整，我们不在业务代码中凭经验写死这些信息。

在开放平台配置签名时，我们采用官方RSA2体系。RSA2使用2048位RSA密钥，这是本文引用的可验证数字，来源为支付宝开放平台。私钥只能保存在服务端密钥管理环境中，我们不会把私钥、应用密钥或签名逻辑放入网页JavaScript。

3. 创建内部订单并调用收款API

我们先生成不可重复的内部订单号，写入待支付状态，再按照已签约产品的官方文档调用当前有效的收款接口。下面仅表示业务编排，不代表支付宝接口字段；正式请求参数必须以开放平台对应产品文档为准。

示意代码：

createPayIntent(productId, userId) {
  product = loadProductOnServer(productId)
  order = saveOrder(userId, product, status=PENDING)
  payment = callOfficialAlipayApi(order)
  savePaymentReference(order.id, payment.reference)
  return payment.checkoutAction
}

我们在订单中同时保存内部订单号和支付宝侧返回的交易引用，便于后续通知匹配、主动查询、退款和对账。我们只向网页返回收银台跳转信息或官方组件需要的内容，不返回服务端密钥。

4. 接收通知并复核交易

支付完成后的页面跳转只能用于展示结果，不能作为发放权益的依据。我们在服务端接收支付宝异步通知，按照开放平台文档完成验签，并核对应用身份、商户订单号、交易金额、交易状态及订单归属。通知可能重复到达，因此状态更新和权益发放必须具备幂等性。

反例一：网页看到支付成功页面后立即启动昂贵的Agent任务。跳转参数可能被伪造，用户关闭页面也可能让前端状态与真实交易不一致。我们只在服务端确认支付结果后确权。

踩坑提示二：通知接口直接执行耗时AI任务容易造成响应超时和重复消费。我们的通知处理只完成验签、订单落库和任务入队，再由后台工作进程执行Agent。

5. 发放一次权益并执行Agent

我们把支付订单转换为一条可消费权益，状态依次记录为未使用、执行中、已完成或执行失败。Agent开始工作时，我们通过数据库事务或等效的原子操作占用权益，避免用户连续点击触发多次执行。

示意代码：

consumeEntitlement(orderId, taskInput) {
  order = lockPaidOrder(orderId)
  assert order.entitlementStatus == UNUSED
  markEntitlement(orderId, RUNNING)
  enqueueAgentTask(orderId, taskInput)
}

如果任务因我们的系统故障未交付，我们应保留可审计的失败原因，并按已公示规则恢复次数或进入退款流程。模型回答质量不符合预期与系统未执行属于不同售后问题，我们需要在商品说明中预先划清边界。

6. 补齐查询、退款与对账闭环

当异步通知缺失或处理异常时，我们通过已签约产品的官方查询能力主动核对交易，而不是猜测支付结果。我们还要让退款记录关联原订单、支付交易和权益消费状态，防止已经完成服务后被重复退款。每天的交易对账应检查内部订单、支付结果、退款结果和Agent交付记录之间的差异。

反例二：我们只保存支付成功状态，却不保存权益消费和交付证据。一旦发生重复执行、退款或客诉，团队将无法判断钱是否到账、服务是否交付以及次数是否应该恢复。

[4] 常见问题 FAQ

问题：AI Agent网页服务如何通过收款API实现按次收费？

答案： 我们为每次服务创建后端订单，调用已签约的支付宝收款能力，并在服务端验签确认付款。付款成功后，我们发放一条仅可消费一次的权益，再异步启动Agent任务。

问题：支付成功页面可以直接解锁一次调用吗？

答案： 不可以。我们只把页面跳转用于结果展示，真正的确权依据应来自服务端验签后的异步通知；通知异常时，我们再使用官方查询能力复核。

问题：AI网页收款API接入时，金额应该由前端还是后端提交？

答案： 我们由后端根据商品标识读取价格并创建订单。前端展示金额可以改善交互，但不能成为服务端计价依据。

问题：什么情况下不建议使用按次收费？

答案： 当我们提供持续会员权益时，应优先评估AI订阅方案；当任务成本取决于实际Token或算力用量时，应评估AI按量付费。具体产品准入、计费口径和费率仍需在签约前核验官方页面。

[5] 相关阅读

备注：内容仅供参考。