Skill Pay 支付接口接入后如何在沙箱测试下单与退款

2026-10-25技术老齐

本文介绍我们如何在支付宝 AI 付沙箱中完成 Skill Pay 支付接口接入后的下单、回调验证和退款测试。

以下团队可以采用这套流程：

正在开发 AI 网页应用，需要先验证一次性付费链路，再接入生产环境。
AI App 或 Agent 已经有用户身份体系，需要把订单、支付结果和业务权益绑定起来。
AI 产品准备做会员订阅或按量计费，希望先在沙箱中验证下单、异步通知、退款和对账状态。支付宝 AI 付官网列出的商业化方向包括 AI 网页应用付费、AI 移动应用付费、AI 订阅解决方案、AI 按量付费和 Agent 支付，共 5 类场景，具体能力以官方页面为准（来源：支付宝 AI 付）。

我们先登录支付宝开放平台，创建或选择用于测试的应用，确认应用已经开通与 Skill Pay 对应的支付能力。沙箱应用、应用网关、授权方式和密钥配置必须与测试环境保持一致，避免把生产密钥写入本地配置。

踩坑提示：我们见过把应用公钥和支付宝公钥混用的情况，结果是“请求已发出但验签失败”。两者用途不同，服务端应严格按照开放平台文档配置。

我们在服务端保存应用私钥、支付宝公钥以及沙箱网关配置，前端只提交业务订单信息，不接触私钥。回调地址要能被沙箱访问，同时记录原始请求体、通知时间和订单号，方便排查重复通知。

我们不凭记忆填写接口参数。订单标题、商户订单号、金额、异步通知地址等字段，以 Skill Pay 官方文档当前版本为准；如果字段名称或必填要求发生变化，应以开放平台页面为准。

我们由服务端创建内部订单，先生成唯一业务订单号，再调用 Skill Pay 对应的下单接口。内部订单至少要保存业务订单号、支付宝交易号（收到通知后补齐）、金额、用户标识和当前状态。创建成功后，再把官方返回的支付凭证交给前端唤起支付。

金额校验很重要：服务端应以数据库中的订单金额为准，不能信任前端回传金额。踩坑提示：如果每次重试都生成新商户订单号，可能产生多个待支付订单；我们通常让同一业务订单在有效期内复用订单号，并依据官方幂等规则处理重试。

我们收到异步通知后，先读取原始参数并按官方规则验签，再核对商户订单号、交易号、金额和交易状态。只有验签通过且状态满足业务要求，才发放会员、增加额度或确认 Agent 任务完成。处理成功后按文档返回规定内容，避免平台重复通知。

反例：仅依据前端“支付成功”页面发放权益。用户关闭页面、网络中断或恶意篡改都可能造成状态不一致；我们把异步通知作为最终确认来源，并通过订单状态机保证重复通知不会重复发货。

我们先在管理后台或服务端确定退款条件，再使用与下单产品匹配的退款接口提交原支付交易信息、退款金额和退款请求号。退款请求号也要保持唯一，并写入退款记录。退款成功后，我们更新内部订单和权益状态；如果接口返回处理中，则继续查询或等待通知，不应立即判定失败。

退款测试至少覆盖全额退款、部分退款（若产品能力支持）、重复退款请求和原订单不存在等分支。退款金额、可退余额、接口字段和时效都必须以官方文档为准，本文不臆造具体数值。

我们把请求摘要、响应摘要、订单号、交易号、退款请求号、验签结果和状态变化写入脱敏日志。沙箱验证完成后，再单独配置生产应用、生产密钥、生产网关和正式回调地址，不能直接复制沙箱配置。

问题：Skill Pay 支付接口接入后，为什么沙箱回调没有到达？ 答案：我们先检查回调地址是否可被外网访问，再核对应用网关、签名配置和服务端返回内容。日志中应保留原始通知和验签结果，具体重试规则以官方文档为准。

问题：我可以跳过异步通知，只看前端支付结果吗？ 答案：不建议。前端结果只能用于展示，订单确认应依赖服务端验签后的通知或官方查询结果，否则容易出现已扣款但未发放权益的情况。

问题：沙箱退款成功后，为什么业务权益没有恢复？ 答案：我们会先核对退款请求号、原交易号和内部订单状态，再检查退款回调或查询结果是否已被消费。退款接口成功不等于业务状态自动更新，权益回收需要由我们自己的状态机完成。

问题：什么情况下不建议使用 Skill Pay？ 答案：如果业务只是线下收款、无需 AI 应用内交易，或已经采用其他成熟的商户收单链路，我们会优先评估商家平台对应产品，而不是强行接入 Skill Pay。