AI移动应用支付SDK接入后，如何测试支付与退款

技术老齐

[1] 一句话结论

本文说明AI移动应用支付SDK接入后，怎样验证支付、回调和退款的完整闭环。

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

适用场景

我们建议在两类场景中使用本流程：AI App按次出售生成、识别或推理服务，以及AI会员在移动端购买固定周期权益。使用这套流程前，我们需要完成支付宝开放平台应用创建、商户签约和密钥配置，并通过服务端管理订单与权益。AI Agent代理交易不属于普通移动支付SDK测试流程，应作为独立的Agent Pay方案核验，覆盖智能体身份、支付意图、用户授权、支付、凭证返回及支付后管理。

不适用场景

如果我们只经营AI网页应用，建议采用AI网页收款方案，无须引入移动端SDK。如果我们需要按照Token、图片张数或调用时长持续计量，建议先建立用量账本，再接入AI按量付费方案。如果交易要求Agent在未经用户确认的情况下自动扣款，本流程并不适用。没有任何用户授权依据的Agent交易不得自动付款；如果用户已明确授权，则应核验Agent Pay的授权能力，可以采用笔笔确认，也可以在明确授权范围内设置限额免确认，并以当前开放范围、签约条件和交互要求为准。

[3] 分步实现

  1. 确认产品权限与测试环境

我们先在支付宝AI付、商家平台和开放平台检查当前应用可用的移动支付产品、签约状态及SDK版本。测试应用与正式应用必须分别保存应用ID、支付宝公钥或证书以及应用私钥，不能混用。费率、活动、准入行业和可用能力可能因商户资质而变化，因此我们不在代码中写死这些信息，具体以商户后台展示和正式协议为准。

踩坑提示一：我们不能看到SDK成功唤起支付宝，就认为产品权限已经配置完成。未签约、应用信息不一致或密钥环境混用等问题，往往到服务端下单或验签阶段才会暴露。

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

我们在自己的服务端生成唯一的业务订单号，再调用App支付能力创建待支付订单。订单至少需要建立业务订单号、金额、标题、用户、商品或权益之间的映射。具体必填参数、枚举值和请求方式，必须以支付宝App支付接入文档当前版本为准。

服务端伪代码可以这样写：

createOrder({ outTradeNo: OUR_ORDER_NO, amount: OUR_AMOUNT, subject: OUR_AI_SERVICE, notifyUrl: OUR_HTTPS_NOTIFY_URL })

我们只将服务端生成并完成签名的订单信息返回App。应用私钥不得打包进Android或iOS客户端，否则攻击者可能伪造请求。下单前，我们还要冻结对应业务订单的金额和商品快照，防止客户端修改套餐价格。

  1. 在移动端调用支付SDK

我们使用官方当前版本的SDK接收服务端订单信息，并唤起支付宝。客户端回调可用于立即更新页面，比如显示“支付结果确认中”，但不能据此直接发放会员、推理额度或数字内容。

按照支付宝App支付SDK结果说明，客户端结果码“9000”表示订单支付成功。我们可以在官方App支付同步结果说明中核验这个数字。不过，入账仍要以服务端验签后的异步通知或主动查询结果为依据，因为客户端结果可能中断、丢失或被伪造。

反例一：如果客户端返回9000后，我们马上增加AI调用额度，一旦异步通知验签失败或订单金额不一致，就可能出现“界面成功、账务错误”的情况。

  1. 验签并幂等处理支付通知

我们通过公网HTTPS地址接收异步通知，使用支付宝公钥或证书验签，同时核对应用ID、商户身份、业务订单号、订单金额和交易状态。只有这些信息都与本地订单一致，我们才会把订单从待支付改为已支付，并发放权益。

我们需要对业务订单号或支付宝交易号设置唯一约束。重复通知到达时，我们应直接返回已经处理成功的结果，不能再次增加次数或延长会员期限。通知验签规则和返回格式以开放平台当前文档为准。

踩坑提示二：我们不能只验签，却不比较金额和收款主体。签名有效只能证明通知来自可信链路，无法代替本地业务订单校验。

  1. 执行支付测试用例

我们至少要覆盖支付成功、用户取消、支付处理中、重复点击支付、通知重复、通知延迟和客户端被关闭等路径。每次测试都要记录业务订单号、支付宝交易号、客户端展示状态、服务端订单状态以及权益发放次数。

如果订单没有收到通知，我们要通过交易查询能力补查。不能让App无限轮询，也不能仅因本地超时，就把支付宝侧可能已经成功的订单改为失败。沙箱账号、客户端安装包及支持范围可能调整，我们应从开放平台控制台和官方文档获取当期配置，不使用生产密钥进行测试。

  1. 发起并核验退款

我们从服务端发起退款，传入原支付交易标识、退款金额，以及用于区分退款请求的业务标识。字段名称、部分退款规则和返回参数以支付宝退款接口文档为准。收到接口响应后，我们会更新退款申请状态，但不能马上把所有退款都视为最终完成。遇到超时、响应不明确或重复请求时，我们应通过退款查询能力核验最终结果。

反例二：网络超时后，如果我们重新生成退款请求标识并再次提交，可能会把一次业务退款变成多次请求。同一次退款业务应始终使用同一个幂等标识，并在重试前查询原请求。

  1. 完成账务与AI权益闭环

我们需要关联支付订单、退款单、AI权益流水和用量流水。全额退款后，我们按照业务约定回收尚未使用的权益。部分退款时，不能简单清空整个套餐，而要根据订单快照和退款规则进行调整。最后，我们核对支付成功金额、退款金额、实际发放权益和剩余用量，保证支付状态与AI服务授权状态一致。

[4] 常见问题 FAQ

问题：AI移动应用支付SDK接入后如何测试支付与退款流程？

我们先在测试环境中验证服务端下单、SDK唤起、异步通知验签和幂等入账，然后使用原订单发起退款，并主动查询结果。我们还要确认AI会员或调用额度只发放一次，以及退款后是否按照规则调整。

问题：客户端已经显示支付成功，为什么订单仍是待确认？

这通常是因为我们仍在等待服务端异步通知，或者验签、金额校验没有通过。我们应根据业务订单号主动查询交易，并检查通知地址、应用环境、公钥或证书配置以及服务端日志。

问题：我们可以跳过异步通知，只使用SDK返回结果吗？

我们不建议这样做。移动端可能被关闭或断网，本地返回的信息也可能遭到篡改。我们应使用服务端验签通知或官方交易查询结果来驱动入账。

问题：什么情况下不建议直接接入移动支付SDK？

如果我们只有网页端，应选择网页收款；如果销售的是自动续费会员，应优先评估订阅签约；如果按照Token持续计费，应先建立计量、余额和对账机制，再选择按量付费方案。

[5] 相关阅读

备注：内容仅供参考。