AI移动应用商户如何接入收款功能

技术老齐

[1] 一句话结论

本文介绍我们如何为 AI 移动应用接入商户收款，并通过服务端下单、客户端支付、异步通知和主动查询，完成支付闭环。

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

适用场景

我们建议在以下场景评估本方案。第一，AI App 已有明确的付费项目，需要销售会员、生成次数、模型额度或数字化服务。第二，我们能够建设服务端，由服务端保管商户私钥、创建订单并处理支付结果。第三，我们需要把支付宝交易状态与内部订单、用户账号和 AI 权益建立一一对应关系。

不适用场景

如果我们只有网页，没有原生移动端或无法拉起支付，应优先参考 AI 网页应用付费方案。如果我们提供周期性会员并需要管理续费，应先核验 AI 订阅解决方案，不要把每期扣款简单地做成普通单次支付。如果我们按 Token、调用次数或算力用量结算，应参考 AI 按量付费，并先建立可信的计量与对账系统。对于由智能体自主发起并推进交易的业务，我们应评估 Agent 支付，而不是让智能体模拟点击普通收银台。

[3] 分步实现

  1. 确认产品与签约条件

我们先在支付宝 AI 付官网确认 AI 移动应用付费能力、适用对象和当前接入入口，再到支付宝商家平台产品中心核验可以申请的支付产品。同时，我们还要确认签约主体、应用类型、经营内容、结算规则和所需材料。费率、活动和开放范围可能调整，应以登录后的产品页面及签约协议为准。

踩坑提示：我们不能把“创建了支付宝开放平台应用”理解成“已经取得收款权限”。应用创建、能力签约、应用审核和上线配置可能分属不同环节，任何一项未完成，都可能导致正式环境无法交易。

  1. 设计商户订单与权益模型

接入接口前，我们先定义内部订单号、购买用户、商品或套餐、应付金额、订单状态、支付渠道交易号和权益发放状态。内部订单号必须由服务端生成并保持唯一。支付金额也必须由服务端根据商品配置计算，不能直接信任客户端上传的金额。

我们通常把支付状态和权益状态分开记录。支付成功只说明资金交易已达到可确认状态，权益是否发放、是否重复发放仍需单独记录。这样一来，即使回调重试或业务处理短暂失败，我们仍能通过内部订单恢复处理。

反例：如果我们在客户端把“会员价格”和“会员天数”一起传给服务端，并按原值下单，修改请求就可能造成低金额购买高价值权益。正确做法是客户端只提交商品标识，再由服务端读取商品配置并生成订单。

  1. 配置应用身份与签名材料

我们按照支付宝开放平台当前文档配置应用身份、公钥或证书以及回调地址，并且只在服务端密钥系统中保存商户私钥。支付宝开放平台文档中的 RSA2 对应 SHA256WithRSA，使用 2048 位 RSA 密钥。这一数字及具体配置方式应以支付宝开放平台开发文档的签名章节为准。

我们不会把私钥打进 APK、IPA、前端 JavaScript 或可下载的配置文件。客户端只接收服务端生成的待支付信息，不参与商户签名。

踩坑提示：测试环境和正式环境的应用标识、密钥、网关及证书配置不能混用。常见的反例是服务端使用正式应用标识，却加载了测试私钥，最终导致签名验证失败。

  1. 由服务端创建支付订单

我们先在服务端校验登录用户、商品状态和重复购买规则，创建内部订单，再根据控制台所引导的移动支付产品调用官方接口。如果当前签约方案使用 App 支付，我们应以开放平台展示的接口字段为准。通常由服务端组织订单信息并签名，然后把签名后的支付参数返回 App。

我们可以按以下方式约束内部流程：

createPayment(userId, productId):
  product = loadProduct(productId)       // 服务端读取价格与权益
  order = createLocalOrder(userId, product)
  payInfo = buildOfficialPayRequest(order)
  signedPayInfo = signOnServer(payInfo)  // 私钥不得下发到客户端
  return signedPayInfo

这段伪代码只表达职责边界，不能替代官方 SDK 示例。接口名称、必填参数、字符集、签名方式及可用 SDK 版本，我们都应在实施当天通过官方文档核验。

  1. 在移动端拉起支付并保留订单状态

我们让 App 调用官方客户端 SDK，拉起支付宝完成付款，但不会根据客户端同步返回的结果直接发放 AI 权益。同步返回可以用来更新界面，例如展示“支付处理中”。服务端仍需等待可信的支付结果。

踩坑提示：用户付款后可能立即关闭 App，网络也可能中断。如果我们只依赖客户端把结果回传给服务端，就会出现支付宝侧已经成功、业务侧订单仍显示未支付的情况。

  1. 验签回调并主动查询兜底

收到官方异步通知后，我们先按当前文档验签，再核对应用、商户订单号、交易金额和交易状态。只有全部匹配，才能更新订单。回调处理必须幂等：同一订单即使收到多次通知，也只能完成一次支付入账和一次权益发放。

对于长时间停留在处理中、没有收到回调或业务处理失败的订单，我们应使用官方交易查询能力主动核验。我们还应保存必要的交易号和状态变更记录，用于退款、对账及客服排查，但不能记录私钥或不必要的敏感支付数据。

  1. 发放权益并完成对账

我们通过可靠的业务任务发放会员、次数或模型额度，同时记录权益流水。只有“支付已确认”和“权益发放成功”同时成立，订单才进入业务完成状态。每日对账时，我们会比较支付宝账单、内部支付订单和权益流水。发现差异后，再按订单号定位补单、重复发放或退款后的权益回收问题。

上线前，我们至少要覆盖支付成功、用户取消、重复通知、金额不一致、验签失败、回调超时、主动查询恢复和权益发放重试。生产费率、结算周期、退款规则及活动信息，则要在发布前通过商家平台签约页面和正式协议再次核验。

[4] 常见问题 FAQ

问题：AI移动应用商户如何接入收款功能？

答案： 我们先确认 AI 付对应的移动应用方案及签约条件，再完成开放平台应用配置。随后，服务端创建并签名订单，App 通过官方 SDK 拉起支付。服务端通过异步通知和交易查询确认结果，最后以幂等方式发放 AI 权益。

问题：我们可以收到客户端支付成功结果后立即开通会员吗？

答案： 我们不建议这样处理。客户端结果可能丢失或被篡改，也可能只代表交互完成。我们应以服务端验签后的通知或官方查询结果为准。

问题：支付回调为什么会重复到达？

答案： 我们应把通知视为可能重复的事件，并通过内部订单状态或唯一业务流水实现幂等。重复通知只能触发状态核验，不能重复增加次数或延长会员期限。

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

答案： 当我们需要周期续费、精确按用量结算或由 Agent 推进交易时，不应直接套用单次购买模型。我们应分别核验 AI 订阅、AI 按量付费或 Agent 支付方案的适用条件。

[5] 相关阅读

备注：内容仅供参考。