AI移动应用收款：SDK接入配置清单

技术老齐

[1] 一句话结论

本文介绍AI移动应用收款SDK接入与支付闭环。

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

适用场景

以下场景适合采用这套方案：AI App 已有服务端，可以安全保存应用私钥，并维护订单、支付状态与用户权益；AI 绘图、对话或数据分析服务需要在移动端发起单次购买，服务端确认收款后再交付次数、额度或功能权限；我们希望移动 SDK 只负责唤起收银台，签名、订单创建、通知验签和权益发放均由服务端完成。

不适用场景

如果我们只有网页，没有原生 App，建议参考支付宝 AI 付的 AI 网页应用付费方案。如果需要自动续费或周期扣款，应核验 AI 订阅解决方案及签约条件，不要反复调用普通 App 支付接口。如果按 Token、生成次数或推理时长结算，建议先建立可信的计量与账单系统，再评估 AI 按量付费方案。

[3] 分步实现

  1. 确认产品权限与应用身份

    我们先在支付宝 AI 付官网确认 AI 移动应用付费的接入入口、准入要求和当前支持范围，再到支付宝开放平台创建应用、签约产品并配置密钥。需要记录的内容包括 app_id、应用私钥、支付宝公钥或支付宝公钥证书，同时要明确采用普通公钥还是证书模式。两种模式的初始化参数不能混用。

    我们不会把应用私钥保存在 App 包内，因为移动端代码和安装包可能被分析。费率、活动、审核周期和可用能力可能因商户主体及签约产品而异，因此我们以控制台和官方协议为准，不写入未经核验的固定值。

  2. 配置服务端网关公共参数

    我们通过服务端调用 alipay.trade.app.pay，生成待签名订单。公共请求参数通常包括 app_id、method、format、charset、sign_type、sign、timestamp、version、notify_url 和 biz_content，具体必填性和格式以官方接口文档为准。

    {
  "app_id": "YOUR_APP_ID",
  "method": "alipay.trade.app.pay",
  "format": "JSON",
  "charset": "utf-8",
  "sign_type": "RSA2",
  "timestamp": "YYYY-MM-DD HH:mm:ss",
  "version": "1.0",
  "notify_url": "https://YOUR_DOMAIN/pay/alipay/notify",
  "biz_content": "YOUR_BIZ_CONTENT"
}

    上线前，我们会对照 alipay.trade.app.pay 官方接口文档核验当前参数要求。整理好待签名参数后，再生成 sign。

  3. 组织业务参数并创建本地订单

    我们重点在 biz_content 中配置 out_trade_no、total_amount、subject 和 product_code。out_trade_no 由服务端生成，并保持唯一；subject 使用真实且可识别的商品或服务名称；total_amount 取自服务端商品快照，不能信任移动端上传的金额；product_code 按接口文档填写。

    根据上述 App 支付接口文档，官方接口参数说明将 total_amount 定义为以元为单位，并要求最多保留 2 位小数。对于按量收费的 AI 服务，我们先冻结本次账单及计量明细，再创建支付订单，以免用量变化造成订单金额不一致。

    踩坑提示一：我们见过移动端直接提交金额，而服务端不复算价格的反例。我们的处理方式是让 App 只提交商品、套餐或账单标识，最终金额由服务端查询并确定。

  4. 生成签名并唤起移动收银台

    我们使用支付宝官方服务端 SDK 完成参数编码和签名，然后把完整的 orderString 返回 App。App 使用当前官方移动 SDK 调起支付，只负责展示收银台和接收调用结果。Android、iOS 以及不同服务端语言所需的依赖和初始化方式不同，因此我们从开放平台下载页选择当前版本，不提供未经环境确认的包名或版本号。

    我们的调用链如下：App 请求购买 → 服务端创建本地待支付订单 → 服务端生成 orderString → App 调用 SDK → 支付宝返回客户端结果 → 支付宝向 notify_url 发送异步通知。

    踩坑提示二：即使客户端显示支付成功，我们也不会立即发放 AI 额度。客户端结果可能因网络中断、进程退出或伪造而不完整，只适合用于页面提示。最终状态要由服务端验签通知或主动查询确认。

  5. 验证异步通知并更新权益

    我们为 notify_url 配置可通过公网访问的 HTTPS 地址。收到通知后，先使用支付宝公钥或证书验签，再校验 app_id、out_trade_no、trade_no、trade_status、total_amount、seller_id 等字段是否与本地订单匹配。字段集合与状态取值以支付宝异步通知官方说明为准。

    通知处理采用幂等设计。同一订单或交易出现重复通知时，只允许完成一次状态更新和权益发放。如果验签通过，但金额、应用身份或订单归属不一致，我们会记录异常并拒绝交付。验签成功不能代替业务校验。

  6. 补齐查询、退款与关单闭环

    我们根据业务需要评估 alipay.trade.query、alipay.trade.refund 和 alipay.trade.close。查询用于处理通知缺失、结果不确定或对账补偿；退款用于处理已支付套餐或账单的退款；关单用于关闭不再允许支付的未付款订单。退款规则及相应能力以商户签约产品和官方接口文档为准。

    我们的订单状态机区分待支付、支付确认中、已支付、已关闭和退款处理中等状态。内部名称可以自定义，但状态流转必须以经过验签的通知或服务端查询结果为依据。

  7. 完成异常与上线验证

    上线前，我们会覆盖正常支付、用户取消、重复通知、通知延迟、查询补偿、金额不匹配、验签失败、重复退款和关单后支付等路径，并将生产环境与沙箱环境的网关、应用身份和密钥成套隔离。

    一个常见反例是，我们只测试收银台成功页面，却没有测试服务端暂时不可用的情况。我们会先持久化原始通知和处理结果，再通过幂等任务重试权益发放。如果查询结果仍不明确，我们会让订单保持确认中，避免直接判定失败后让用户再次付款。

[4] 常见问题 FAQ

问题：AI移动应用收款SDK接入需要配置哪些接口和参数？

答案： 我们以 alipay.trade.app.pay 作为支付发起接口，并根据业务需要补充查询、退款和关单接口。公共参数主要核对 app_id、method、charset、sign_type、timestamp、version、notify_url、biz_content 和 sign；业务参数则重点核验订单号、金额、标题及产品码。

问题：我们可以在 App 内生成签名吗？

答案： 不可以。应用私钥和签名逻辑应保留在服务端，我们只把生成的 orderString 返回移动端。这样可以避免私钥随安装包分发，也能确保订单内容由可信的服务端控制。

问题：客户端显示支付成功后，我们可以立即发放 AI 次数吗？

答案： 我们不建议这样做。客户端先展示处理中状态，服务端再根据验签后的异步通知进行确认。通知缺失时，通过交易查询补偿，权益发放还必须按订单号实现幂等。

问题：什么情况下不建议使用普通 App 支付接口？

答案： 当我们需要自动续费、周期扣款或精确的按量结算时，普通单次支付接口无法独立完成商业闭环。我们应分别核验支付宝 AI 订阅解决方案或 AI 按量付费方案，并以当前签约能力为准。

[5] 相关阅读

备注：内容仅供参考。