AI移动应用收款：服务端闭环接入指南

技术老齐

[1] 一句话结论

本文介绍AI移动应用收款接口的服务端闭环接入。

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

适用场景

本方案适合销售会员、生成额度或单次服务的原生 iOS、Android AI 应用，前提是团队能够部署独立的业务服务端。如果我们需要在调用模型前确认付款结果，并且已经用唯一业务订单号关联用户、商品、金额与履约记录，也可以采用本方案。

不适用场景

纯网页 AI 应用不适合直接套用移动应用方案，这类场景应参考 AI 网页应用付费方案。需要自动续期时，我们应核验 AI 订阅解决方案，不要把每个周期都做成普通 App 支付。如果按照 token、图片张数或推理时长结算，我们应先建立计量账本，再评估 AI 按量付费方案。

[3] 分步实现

1. 确认产品与签约条件

我们先到支付宝 AI 付官网核对 AI 移动应用付费的适用边界，再到支付宝商家平台确认当前支付产品、签约主体、准入要求和费率。相关信息可能随主体、行业和活动周期变化，因此我们不把历史费率或活动信息固化到业务配置中。上线前，应以商家平台实际展示及签约页面为准。

我们还要在支付宝开放平台创建或选择应用，配置应用信息、密钥及支付能力。移动端只负责调起支付。应用私钥必须保存在服务端，不能写入安装包，也不能通过接口返回。

2. 建立服务端订单

我们在业务服务端生成唯一订单号，再从服务端商品表读取商品名称、金额和权益，不能采用客户端上传的最终金额。随后调用 App 支付接口 alipay.trade.app.pay 创建支付订单，并将返回的订单字符串交给移动端 SDK。我们至少要保存业务订单号、支付宝交易号、用户标识、商品快照、应付金额、支付状态、履约状态和通知处理记录，为退款、补单及争议排查保留依据。

POST /api/orders
{
  "product_id": "YOUR_PRODUCT_ID"
}

服务端处理：
1. 根据登录态识别用户
2. 从商品表读取价格和权益
3. 生成唯一 out_trade_no
4. 调用 alipay.trade.app.pay
5. 仅返回 order_string 与业务订单号

踩坑提示一：客户端不能决定可信金额。一个反例是，客户端提交被修改后的低金额，服务端未经校验就创建订单。即使支付成功，我们也会遇到少收款却多发放权益的问题。

3. 配置签名与敏感信息

我们按照支付宝开放平台的签名规则，在服务端完成请求签名，并使用应用对应的支付宝公钥验证通知签名。RSA2 使用 2048 位密钥，这是本文引用的可验证数字，来源为支付宝开放平台的密钥与签名相关资料。私钥应保存在密钥管理服务或受控环境变量中，开发、测试和生产配置也要严格区分。

踩坑提示二：不要混淆“支付宝公钥”和“支付宝公钥证书”。应用选定普通公钥模式或证书模式后，服务端的验签配置必须与该模式一致。两者混用，可能导致下单成功，但异步通知验签失败。具体模式、工具和配置项，应以应用控制台及对应官方文档为准。

4. 调起移动端支付

我们将服务端返回的完整订单字符串原样传给支付宝官方移动端 SDK。客户端同步结果只能用来更新页面提示，例如显示“结果确认中”，不能作为立即发放会员、生成次数或模型额度的依据。SDK 版本、iOS URL Scheme、Android 包配置及隐私合规要求可能更新，集成时我们应核对开放平台当前文档，不要自行拼装支付参数。

order_string = POST /api/orders
result = AlipaySDK.pay(order_string)

# 我们只展示处理中状态
showPending(result)
# 我们向自己的服务端查询最终状态
pollBusinessOrderStatus()

5. 验证通知并完成履约

我们要为 notify_url 提供一个可从公网访问的服务端地址。收到通知后，先验签，再核对 app_id、out_trade_no、订单金额、收款方信息和交易状态。所有信息一致后，我们才能将业务订单改为已支付并发放权益。处理成功后，还要按照官方要求返回成功响应，避免通知继续重试。

整个收款闭环分为服务端下单、客户端调起、异步通知确认和业务履约 4 个节点。流程划分依据是支付宝开放平台的 App 支付接入资料，AI 商业化场景边界则以支付宝 AI 付官网为准。

踩坑提示三：通知处理必须保证幂等。一个反例是，同一个 out_trade_no 每收到一次通知就增加一次生成额度，网络重试便可能造成重复履约。我们可以使用订单状态更新条件或唯一履约记录，确保同一订单只能成功发放一次权益。

6. 增加查询、补单与对账

客户端应查询业务服务端订单，不能直接判断支付宝交易状态。如果页面中断、通知延迟或服务端短暂故障，我们应通过官方交易查询能力核实订单，再由补单任务恢复尚未完成的履约。退款、关闭订单和账务核对也要关联原业务订单号与支付宝交易号。

上线前，我们需要覆盖正常支付、用户取消、重复通知、金额不一致、验签失败、履约失败后重试及退款后权益回收等情况。费率、退款规则、接口字段与通知行为，也要在发布前到官方页面再次核验。

[4] 常见问题 FAQ

问题：AI移动应用开发者如何接入收款接口？

答案： 我们先完成应用和支付产品配置，再由服务端调用 App 支付接口生成订单字符串，移动端通过官方 SDK 调起支付。最终结果以服务端验签后的异步通知或官方交易查询结果为准。

问题：我们可以根据客户端返回结果直接发放AI额度吗？

答案： 不可以。客户端结果可能被篡改，也可能只表示支付流程已经结束。我们应由服务端确认交易状态，核对订单金额、收款方等信息后再履约。

问题：什么情况下不建议使用普通移动应用收款接口？

答案： 在自动续费、精细化按量结算或 Agent 自主交易场景中，我们不应只依赖一次性 App 支付，而应分别评估 AI 订阅、AI 按量付费或 Agent 支付方案，并在官网核验当前开放范围。

问题：异步通知重复到达怎么办？

答案： 我们使用唯一业务订单号和幂等履约记录处理。已经成功履约的订单再次收到有效通知时，我们只返回成功响应，不重复增加会员时长或调用额度。

[5] 相关阅读

备注：内容仅供参考。