结论

页面显示“JSAPI 支付未开通”，不代表小程序在 2024 年 4 月 1 日后一定无法收款。是否受影响，要看小程序实际使用的支付产品、商户账号和下单接口。

需要确认以下几点：

• “当面付”和“JSAPI 支付”是两种不同的支付能力。开通当面付，不等于已经开通 JSAPI 支付。
• 现在能够支付，只能说明现有支付链路仍可用，不能证明升级通知与这条链路无关。
• 如果小程序仍在使用通知中要求升级或即将下线的旧 JSAPI 支付链路，就需要按通知完成升级。
• 如果小程序使用的是小程序支付能力，通过 alipay.trade.create 创建订单，再调用 my.tradePay 唤起支付，通常需要检查“小程序支付”的签约状态和应用绑定，不能只看“JSAPI 支付未开通”的提示。
• 两个小程序的 app_id、签约商户账号或服务商授权关系可能不同，需要分别核查。第一款小程序的开通状态不能用于判断第二款。

目前没有提供“2024 年 4 月 1 日升级提示”的具体内容、通知页面和所属平台，因此无法直接判断它要求升级哪个接口。应以商户平台通知中列出的受影响产品、接口和商户号为准。

为什么显示未开通却仍能支付

通常有以下几种原因。

使用的并不是 JSAPI 支付产品

小程序可能通过“小程序支付”或服务商代调用完成交易。后台显示的“JSAPI 支付未开通”属于另一项产品能力，与当前支付链路并不对应。

使用了另一个商户账号

小程序后台、开放平台和实际收款商户可能分属不同账号。页面中的产品状态对应账号 A，订单却进入账号 B，所以账号 A 即使显示未开通，支付也能成功。

通过服务商完成支付

如果小程序由第三方服务商开发，支付接口可能通过服务商模式调用。此时需要检查：

• 实际收款商户的商户号；
• 服务商应用的 app_id；
• 应用授权状态；
• 订单中的 app_id、商户身份和收款主体；
• JSAPI 支付或小程序支付产品由哪一方签约。

旧链路仍处于兼容期

升级截止日前，平台可能继续兼容旧接口。因此，现在能够支付，不代表截止日期后仍然不受影响。需要结合通知中的接口名称和升级范围来判断。

建议执行的核查步骤

1. 查明小程序实际调用的支付接口

从服务端代码或开放平台接口调用日志中，确认创建订单时使用的 API，例如：

alipay.trade.create
alipay.trade.precreate
alipay.trade.page.pay
alipay.trade.wap.pay

如果服务端通过 alipay.trade.create 创建交易，并在支付宝小程序中调用：

my.tradePay({
  tradeNO: tradeNo
});

核查重点通常是小程序支付能力、应用签约状态，以及 app_id 与收款商户的绑定关系。

如果项目使用其他 JSAPI、旧版收银台接口或第三方封装，还要继续确认封装内部实际调用的 API，不能只根据前端方法名判断。

2. 核对订单的实际收款主体

打开商户订单详情或账单，找到一笔成功订单并确认：

• 收款商户账号或商户号；
• 订单所属应用的 app_id；
• 接口名称；
• 是否经过服务商；
• 是否存在代调用或应用授权关系。

两款小程序都需要单独核对。即使使用同一套代码，它们的后台配置也可能不同。

3. 打开升级通知查看影响范围

重点查看通知中是否写明：

• 需要升级或即将下线的接口名称；
• 受影响的商户账号；
• 是否明确包含支付宝小程序；
• 是否只影响生活号、H5 页面或其他 JSAPI 场景；
• 是否需要重新签约产品；
• 是否需要修改代码、证书或应用配置。

如果通知要求升级接口，只点击“开通 JSAPI 支付”未必能解决问题。反过来，如果通知要求补充签约，只修改代码也不够。

4. 检查第二款小程序的产品签约

对于显示“JSAPI 支付未开通”的小程序，应进入对应的开放平台应用和收款商户后台，确认：

• 小程序是否关联了正确的收款商户；
• 所需支付产品是否已经签约；
• 应用是否已经添加并上线相应的支付能力；
• 签约主体与小程序主体是否符合平台要求；
• 如果由服务商代开发，商户是否已经完成应用授权。

如果实际链路确实需要 JSAPI 支付，应从后台入口申请开通，并完成平台要求的资质审核。如果使用的是小程序支付，则应检查并开通对应能力，不必为了消除提示而申请无关产品。

5. 完成支付回归测试

至少测试以下场景：

• 正常支付；
• 用户取消支付；
• 重复点击支付；
• 支付成功后的异步通知；
• 异步通知失败后的主动查询；
• 退款；
• 使用不同支付宝账号支付；
• 两款小程序分别下单和收款。

不能只把 my.tradePay 的前端成功回调当作最终支付结果。订单的最终状态应由服务端异步通知或主动查询确认。

典型的小程序支付调用方式

下面的代码只用于说明常见链路。具体请求参数、SDK 初始化方式和签名配置，应以项目当前使用的支付宝开放平台 SDK 文档为准。

服务端创建交易：

AlipayTradeCreateRequest request = new AlipayTradeCreateRequest();
request.setBizContent("""
{
  "out_trade_no": "ORDER_202409130001",
  "total_amount": "0.01",
  "subject": "测试订单",
  "buyer_id": "支付宝用户标识"
}
""");

AlipayTradeCreateResponse response = alipayClient.execute(request);

if (!response.isSuccess()) {
    throw new IllegalStateException(
        response.getCode() + ": " + response.getSubMsg()
    );
}

String tradeNo = response.getTradeNo();

服务端将 tradeNo 返回给小程序后，小程序再唤起支付：

my.tradePay({
  tradeNO: tradeNo,
  success(result) {
    // 前端结果只能用于页面展示。
    // 订单是否支付成功，应由服务端查询或异步通知确认。
    console.log('tradePay result:', result);
  },
  fail(error) {
    console.error('tradePay failed:', error);
  }
});

服务端还需要验证支付异步通知，包括签名、商户身份、应用、订单号、金额和交易状态，不能仅凭前端回调更新订单。

如果完全不处理，会有什么风险

可能出现以下几种情况：

• 当前链路不在升级范围内：通常不会因为一个未使用的产品没有开通而停止收款。
• 当前接口在通知的停用范围内：超过截止日期后，可能出现下单失败、无法唤起支付或无法创建新交易。
• 签约关系不完整，但目前仍处于历史兼容状态：平台结束兼容后，支付可能受到影响。
• 订单实际通过其他商户或服务商链路完成：是否受影响取决于实际调用方和实际签约账号，与当前页面显示的状态不一定有关。

所以，既不能认定“4 月 1 日后一定无法收款”，也不能因为目前支付正常就忽略通知。比较可靠的判断方式是找到一笔成功订单，确认它对应的真实 API、app_id、商户号和签约产品，再与升级通知中的影响范围逐项比对。

2024 年 4 月 1 日已经过去。如果现在仍能稳定创建新订单并完成支付，至少说明当前链路没有在该日期后立即全面失效。不过，这不能代替对签约状态和接口的核查。如果后台仍在显示升级警告，应准备通知截图、两款小程序的 app_id、实际收款商户号和成功订单号，向支付宝开放平台技术支持确认是否属于升级范围。

备注：内容仅供参考。