网页支付返回URL无法访问，如何排查？

结论

这类问题通常与 notify_url 无关。支付页面打不开，更可能是支付请求已经失效、签名有误，或者支付宝环境与应用配置不一致。

从给出的 URL 来看，应先检查以下几项：

1. URL 中的 timestamp 是 2024-06-11 21:40:43。支付链接不能长期保存或反复使用，应在用户发起支付时重新生成。
2. 请求使用沙箱网关 https://openapi.alipaydev.com/gateway.do，必须配套使用沙箱应用的 app_id、应用私钥和支付宝沙箱公钥。
3. URL 在复制、拼接或传递到前端时，可能经过了二次 URL 编码，也可能出现参数丢失或 sign 被修改的情况。
4. 建议直接使用支付宝 SDK 生成支付表单并返回给浏览器，不要自行拼接支付 URL。
5. notify_url 使用的是 HTTP 内网穿透地址。这个地址通常不会影响支付收银台打开，但失效后会导致异步通知无法送达。

先重新生成支付请求

给出的 URL 包含固定的时间戳和签名。时间戳或业务参数发生变化后，都要重新计算签名，不能只修改 URL 中的参数。

不要重复使用保存在数据库、日志或浏览器历史记录中的支付链接。正常流程如下：

1. 用户点击“支付”。
2. 服务端生成新的 out_trade_no。
3. 服务端设置当前时间并重新签名。
4. 服务端把 SDK 生成的表单返回给浏览器。
5. 浏览器提交表单，进入支付宝收银台。

还要确认服务器时间是否准确。服务器时间偏差过大，也可能导致请求校验失败。

检查沙箱和正式环境是否混用

当前请求使用的是沙箱网关：

https://openapi.alipaydev.com/gateway.do

对应配置也必须来自沙箱环境：

沙箱 app_id
应用私钥
支付宝沙箱公钥

正式环境应使用：

https://openapi.alipay.com/gateway.do

并配套使用正式应用的 app_id、应用私钥和支付宝公钥。

常见的配置错误有：

• 使用沙箱 app_id 调用正式网关。
• 正式应用配置了沙箱公钥。
• 把“应用公钥”当成“支付宝公钥”配置到客户端。
• 应用私钥与上传到支付宝开放平台的应用公钥不匹配。
• 重新生成或更换密钥后，服务端仍然使用旧私钥。
• 使用证书模式，却按照普通公钥模式初始化客户端，或者反过来。

如果支付宝页面可以打开，但显示“签名错误”“应用不存在”或“无权限”等信息，应先检查这些配置。

不要手工拼接或改写支付 URL

sign 是根据待签名参数计算的。签名生成后，参数内容只要发生变化，验签就可能失败。例如：

• biz_content 被重新序列化。
• 金额从 "123.3" 改成 "123.30"。
• 参数被重复进行 URL 编码。
• +、%2B 和空格之间发生错误转换。
• & 在 HTML 中被改写或截断。
• 复制 URL 时漏掉了末尾内容。
• 前端框架对整个 URL 又执行了一次 encodeURIComponent()。
• 网关参数已经由 SDK 编码，业务代码又编码了一遍。

日志可以记录签名前的参数，但签名完成后不要重新拼装请求。完整支付 URL 也不应长期保存在公开日志中。

推荐使用 SDK 返回支付表单

以支付宝 Java SDK 为例，服务端可以生成表单，再直接写入 HTTP 响应：

AlipayClient alipayClient = new DefaultAlipayClient(
    "https://openapi.alipaydev.com/gateway.do",
    appId,
    merchantPrivateKey,
    "json",
    "UTF-8",
    alipayPublicKey,
    "RSA2"
);

AlipayTradePagePayRequest request = new AlipayTradePagePayRequest();
request.setNotifyUrl("https://example.com/alipay/notify");
request.setReturnUrl("https://example.com/alipay/return");

request.setBizContent("""
{
  "out_trade_no": "ORDER_202406110001",
  "total_amount": "123.30",
  "subject": "商品标题",
  "product_code": "FAST_INSTANT_TRADE_PAY"
}
""");

String form = alipayClient.pageExecute(request).getBody();

response.setContentType("text/html;charset=UTF-8");
response.getWriter().write(form);
response.getWriter().flush();

前端访问这个服务端接口后，浏览器会加载并提交 SDK 生成的表单。不要把 form 当成普通 JSON 返回，否则前端看到的只会是一段 HTML 字符串。

如果必须由前端接收表单内容，可以将其写入新页面后提交，但需要做好 XSS 防护，并确认前端没有转义或修改表单字段。

检查请求参数

当前请求的核心业务参数没有明显缺项：

{
  "subject": "商品标题",
  "out_trade_no": "qwe123",
  "total_amount": "123.3",
  "product_code": "FAST_INSTANT_TRADE_PAY"
}

仍需逐项核对：

• out_trade_no 在商户系统中必须唯一，不能与其他订单重复。
• total_amount 必须是合法的金额字符串，建议统一保留两位小数，例如 "123.30"。
• product_code 应为 FAST_INSTANT_TRADE_PAY。
• charset、签名所用字符集和 SDK 配置必须一致。
• sign_type 为 RSA2 时，实际使用的签名算法也必须是 RSA2。
• biz_content 参与签名的内容必须与最终发送的内容完全一致。
• 应用需要具备对应网页支付产品的调用条件。

不要通过手动修改现有 URL 来测试金额、订单号或回调地址。任何参数发生变化，都必须重新生成签名。

区分“支付页面打不开”和“回调收不到”

这两个问题要分开排查。

支付页面打不开

主要检查：

• 支付链接是否刚刚生成。
• 当前网络能否访问沙箱网关。
• 应用、密钥和网关是否属于同一环境。
• 支付宝返回页面上的错误码和错误信息。
• URL 是否被截断或二次编码。
• 服务器时间是否准确。
• 是否通过 SDK 生成并提交表单。

可以在浏览器开发者工具的 Network 面板中查看请求状态：

• 没有发出请求：通常与前端跳转、HTML 转义或安全策略有关。
• DNS 错误或连接超时：通常与本地网络、代理、防火墙或网关访问有关。
• 返回支付宝错误页面：根据页面中的错误码检查应用、权限、参数和签名。
• HTTP 400：重点检查 URL 格式、编码以及请求是否被截断。

支付完成后收不到通知

遇到这种情况，再检查 notify_url。当前地址是：

http://xiaowei007.natapp1.cc/payment_manager/pay_url

内网穿透域名可能过期、离线或发生变化，HTTP 地址也可能受网络和部署策略影响。建议换成稳定且可从公网访问的 HTTPS 地址，例如：

https://example.com/alipay/notify

通知接口还要满足以下条件：

• 支付宝服务器可以从公网访问。
• 不依赖用户登录状态或 Cookie。
• 不执行浏览器页面跳转。
• 正确验签。
• 校验 app_id、out_trade_no、total_amount 和 seller_id 等字段。
• 业务处理成功后返回纯文本 success。
• 做好幂等处理，能够接收支付宝的重复通知。

return_url 用于用户完成支付后的浏览器跳转，notify_url 用于服务端异步通知。最终支付状态应以异步通知或主动查询结果为准，不能只依据浏览器跳转参数。

建议的排查顺序

1. 停止使用给出的旧 URL，通过 SDK 重新生成支付请求。
2. 确认网关、app_id、应用私钥和支付宝公钥都来自同一个环境。
3. 把 pageExecute() 返回的 HTML 表单直接写入浏览器响应。
4. 不要再次编码 SDK 的输出，也不要手工修改请求参数。
5. 记录支付宝返回的错误码、错误信息和请求 ID，但不要公开保存完整签名或敏感配置。
6. 如果网络层无法连接，检查 DNS、代理、防火墙，以及当前网络能否访问沙箱网关。
7. 支付页面恢复后，再单独检查 notify_url 的公网可达性和验签逻辑。
8. 如果问题仍未解决，使用同一套参数核对签名前的原文、实际发送的参数，以及支付宝开放平台中的密钥配置。

应优先检查旧时间戳、环境混用和手工拼接 URL 这三项。使用同一环境的配置，并通过官方 SDK 实时生成支付表单，通常可以定位或解决问题。

备注：内容仅供参考。