PAYATHON 2026

小程序专用支付产品升级是否为强制要求？

支付小周

明确结论

这条提示说明，当前小程序已被纳入“小程序场景专用支付产品”的升级范围。收到提示后，通常要先完成升级，才能提交后续版本审核。

如果尚未升级或未通过交易校验，线上已经发布的版本一般不会因此立即停止运行，但新版本可能无法提交审核，或无法通过提审时的支付能力校验。宽限期、豁免范围和具体生效时间，以提审页面及对应《升级指南》的实时规则为准。

这里的“升级”不只是修改小程序版本号，而是根据实际业务重新确认或开通相应的小程序专用支付产品，例如：

  • JSAPI 支付
  • 预授权支付
  • 商家扣款

开通产品并完成接口适配后，还要产生一笔符合要求的交易，再到版本提审页面填写对应的交易单号。平台会据此验证小程序、商户和支付产品之间的关系。

这条提示具体是什么意思

平台正在将小程序支付能力改为按场景管理的专用产品。系统检测到当前小程序可能存在以下情况：

  • 使用了支付能力，但尚未开通相应的小程序专用支付产品。
  • 已开通旧版或通用支付产品，但尚未升级到专用产品。
  • 产品已经开通，但还没有完成交易验证。
  • 小程序调用支付时使用的应用、商户或产品关系，与后台配置不一致。

开发者需要先完成产品签约和技术适配，再用一笔成功交易确认支付链路已经正确切换。

通常不需要同时开通这三个产品，只处理小程序实际使用的支付能力即可。例如，小程序只有普通付款功能，不涉及预授权和自动扣款，一般只需处理 JSAPI 支付。具体需要升级哪些产品，以升级页面列出的待处理项为准。

不升级会有什么影响

对于已经收到升级提示的小程序，可以理解为“新版本提审受限，已发布版本是否受影响需另行判断”：

  • 新版本提审：通常要先完成升级并填写交易单号，否则可能无法继续提交。
  • 已发布版本：一般不会因为没有升级而立即下线。支付能力以后是否会受到限制，取决于平台公告、产品到期时间和治理安排。
  • 不使用支付的小程序：如果实际没有调用相关支付能力却收到了提示，应先检查历史签约、旧版本支付代码和关联商户，不要为了消除提示随意制造交易。
  • 暂时不发布新版本：短期内可能不会遇到提审限制，但以后更新版本时，仍可能需要通过这项校验。

如果小程序仍在使用相关支付能力，并且还会继续迭代，最好提前完成升级，避免在紧急发版时才处理。

升级和校验流程

1. 确认实际使用的支付场景

检查线上小程序和服务端支付代码，确定目前使用了哪些能力：

  • 普通下单付款：通常对应 JSAPI 支付。
  • 先冻结额度，之后确认结算：通常对应预授权支付。
  • 用户签约后由商家主动扣款：通常对应商家扣款。

还要确认支付请求涉及的小程序应用、商户账号和收款主体。采用多商户、服务商代调用或 ISV 模式时，需要逐一核对授权关系。

2. 开通或升级对应产品

进入平台开放后台，在该小程序的支付产品或能力管理页面查看升级状态，并按照《升级指南》操作：

  1. 选择实际使用的专用支付产品。
  2. 阅读并确认产品协议。
  3. 补充经营信息、结算信息或业务说明。
  4. 完成签约、授权或产品升级。
  5. 等待后台状态变为已开通、已生效或可测试。

如果页面要求完成主体审核、行业资质审核或商户授权，应先处理这些事项。产品仍在审核时，交易校验通常无法成功。

3. 检查支付接口配置

确认小程序支付请求使用的是升级页面绑定的应用和商户，不要混用测试应用、其他小程序或其他商户的订单。

以普通支付为例，小程序端可能通过类似方式唤起收银台：

my.tradePay({
  tradeNO: serverTradeNo,
  success(result) {
    console.log('支付调用结果：', result);
  },
  fail(error) {
    console.error('支付调用失败：', error);
  }
});

其中，serverTradeNo 应由服务端调用平台支付接口创建订单后返回。密钥、私钥和签名操作必须留在服务端，不能写入小程序代码。

下面是服务端逻辑的示意代码。实际接口名称和字段应以当前平台文档及所用 SDK 为准：

async function createMiniProgramTrade(order) {
  // 使用平台官方 SDK，在服务端创建订单。
  // appId、merchantId、privateKey 等敏感配置不得下发到小程序。
  const response = await paymentClient.createTrade({
    outTradeNo: order.orderNo,
    amount: order.amount,
    subject: order.subject
  });

  return response.tradeNo;
}

这段代码仅用于说明调用关系，不包含某个 SDK 的完整可运行参数。不同开放平台、接入模式和 SDK 版本使用的类名与字段可能不同，不能直接照搬。

4. 产生符合要求的验证交易

产品生效后，通过待提审的小程序版本完成一笔符合升级要求的交易。一般需要满足以下条件：

  • 交易由目标小程序发起。
  • 使用待校验的商户和专用支付产品。
  • 支付链路已经真实执行成功。
  • 交易状态已经同步到平台。
  • 交易时间处于页面允许的校验范围内。
  • 订单在校验前没有关闭、撤销或退款。

不要填写由其他应用、网页支付、旧版小程序或其他商户产生的交易单号。即使订单真实存在，也可能因为支付场景不匹配而校验失败。

沙箱订单、极小金额订单或已退款订单能否用于验证，以提审页面的说明为准。如果页面没有明确说明，不要默认这些订单可以通过校验。

5. 获取正确的交易单号

“交易单号”通常是支付平台生成的交易标识，不一定是商户自行生成的订单号。

常见概念包括：

  • 商户订单号：由商户系统生成，常见字段为 out_trade_no。
  • 平台交易号：由支付平台生成，常见字段可能为 trade_no。
  • 预授权编号：预授权业务可能使用单独的授权编号。
  • 扣款交易号：商家扣款成功后生成的支付交易标识。

应填写哪一种编号，以提审页面输入框的说明和错误提示为准。如果页面要求填写“平台交易号”，就不能填写 out_trade_no。

交易号通常可以从以下位置取得：

  • 服务端支付接口的响应数据。
  • 异步通知中的交易字段。
  • 商户后台的交易详情页。
  • 官方订单查询接口的响应结果。

6. 在提审页面完成验证

进入小程序版本提审页面后：

  1. 找到支付产品升级或交易校验区域。
  2. 选择需要验证的支付产品。
  3. 填写对应的交易单号。
  4. 提交校验。
  5. 等待页面返回校验结果。
  6. 所有要求验证的产品都通过后，再提交版本审核。

如果小程序使用了多个专用支付产品，平台可能要求分别提供交易或业务凭证。一笔普通支付交易未必能完成所有产品的验证。

交易校验失败时如何排查

可以按以下顺序检查：

  1. 交易是否真正成功，而不只是创建了订单。
  2. 填写的是平台交易号还是商户订单号。
  3. 交易是否由当前待提审的小程序发起。
  4. 交易使用的商户是否与后台签约商户一致。
  5. 支付产品是否已经审核通过并正式生效。
  6. 交易是否发生在产品升级完成之后。
  7. 是否误用了沙箱环境、测试应用或旧版支付链路。
  8. 交易是否已经关闭、撤销或退款。
  9. 在服务商模式下，应用授权和商户授权是否仍然有效。
  10. 页面是否要求分别验证 JSAPI 支付、预授权支付或商家扣款。

如果这些信息都正确，校验仍无法通过，应保留小程序 App ID、商户号、产品名称、交易号、交易时间和页面错误提示，并提交给平台客服或技术支持核查。公开提交工单或截图时，要遮挡密钥、签名和用户身份信息等敏感内容。

注意事项

  • 不要把应用私钥、商户密钥或签名证书放在小程序前端。
  • 不要使用其他小程序或其他商户的交易号进行校验。
  • 不要为了通过验证，开通实际业务并不需要的预授权或商家扣款产品。
  • 在多主体、多商户或服务商代运营场景中，应先确认签约和收款的具体主体。
  • 前端显示支付成功，不代表服务端一定已经到账。最终状态应通过异步通知或订单查询确认。
  • 升级指南和提审规则可能调整。交易时间范围、支持状态和所需编号，以当前后台页面为准。
  • 如果发版时间紧张，应提前完成产品审核和验证。资质审核、授权生效和交易同步可能不会立即完成。

备注：内容仅供参考。