H5支付中跨域请求被拦截如何解决？

Question

在H5支付集成过程中，常见问题为：当H5页面发起支付请求（如调用支付宝或微信JSAPI）时，因支付网关域名与当前页面不同源，触发浏览器同源策略限制，导致跨域请求被拦截，支付无法唤起。该问题多发生在前端直接请求支付接口或注入支付SDK时，尤其在混合开发或代理部署场景下更为突出。如何在保障安全的前提下，通过合理配置CORS、使用后端代理或遵循支付平台规范进行跳转授权，成为解决此问题的关键。

Answer 1

一、H5支付集成中的跨域问题本质与触发机制

在现代Web应用中，H5页面通过调用支付宝或微信的JSAPI发起支付请求时，常因支付网关域名（如 openapi.alipay.com 或 pay.weixin.qq.com）与当前页面所在域不同源，触发浏览器的同源策略（Same-Origin Policy）限制。该策略禁止前端脚本向非同源域名发起跨域请求，除非目标服务器明确允许。

典型错误表现为：

• No 'Access-Control-Allow-Origin' header is present
• Blocked by CORS policy
• SDK注入后无法唤起支付控件

尤其在混合开发（如WebView嵌套H5）、CDN代理部署或前后端分离架构中，此问题频发。根本原因在于：前端直接请求第三方支付接口，而这些接口通常不支持CORS预检（Preflight），也不返回必要的响应头。

场景	是否易触发跨域	典型表现
H5直连支付API	高	CORS拦截，请求失败
WebView内嵌页面	中高	白屏或无响应
前后端分离 + Nginx代理	中	重定向异常
使用后端统一下单接口	低	正常跳转授权

二、深入分析：为何CORS配置难以直接解决支付跨域问题

尽管CORS是处理跨域的标准方案，但在H5支付场景下存在根本性局限：

1. 第三方支付平台出于安全考虑，通常不会对任意来源开放CORS头（如 Access-Control-Allow-Origin: *）。
2. 部分支付接口为POST且携带自定义头部，触发预检请求（OPTIONS），而支付网关未实现对该方法的支持。
3. 微信JS-SDK依赖本地环境注入，若页面加载时域不匹配，则签名验证失败。

示例代码演示前端直接请求引发的错误：

fetch('https://openapi.alipay.com/gateway.do', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ ...paymentData })
})
.then(res => res.json())
.catch(err => console.error('跨域拦截:', err));
// 浏览器将阻止该请求，即使服务端可达

由此可见，试图通过客户端绕过CORS并非可行路径。必须从架构层面重构请求链路。

三、解决方案演进：从规避到规范遵循

以下是按实践深度递进的三种主流解决方案：

1. 方案一：使用后端代理转发支付请求

将敏感支付请求交由同源后端服务代理，避免前端直接暴露跨域风险。

# 前端请求 → 后端代理接口
POST /api/pay/alipay HTTP/1.1
Host: yourdomain.com
Content-Type: application/json

{ "amount": "9.9", "order_id": "123456" }

后端逻辑示例（Node.js）：

app.post('/api/pay/alipay', async (req, res) => {
  const response = await axios({
    url: 'https://openapi.alipay.com/gateway.do',
    method: 'POST',
    data: buildAlipayParams(req.body),
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' }
  });
  res.json(response.data);
});

2. 方案二：统一下单 + 授权跳转（推荐）

遵循支付宝/微信官方H5支付规范，流程如下：

graph TD A[H5页面提交订单] --> B[后端调用统一下单API] B --> C{生成支付链接} C --> D[前端location.href跳转] D --> E[用户进入支付网关] E --> F[完成支付] F --> G[异步通知+页面回跳]

此方式完全规避跨域，因最终跳转由浏览器主导，不受JS同源策略影响。

3. 方案三：CORS + Nginx反向代理（特定场景适用）

在可控网关层添加响应头，模拟CORS支持：

location /proxy/alipay/ {
    proxy_pass https://openapi.alipay.com/;
    add_header Access-Control-Allow-Origin "*";
    add_header Access-Control-Allow-Methods "GET, POST";
    proxy_set_header Host openapi.alipay.com;
}

注意：仅适用于调试或内部测试环境，生产环境仍需结合身份校验防止滥用。

四、安全考量与最佳实践建议

在实施上述方案时，必须兼顾安全性：

• 签名验证：所有支付参数须在服务端使用私钥签名，防止篡改。
• 敏感信息隔离：AppID、私钥等不得暴露于前端。
• 回调验证：支付结果通知必须通过服务器间通信验证来源真实性。
• HTTPS强制启用：全链路加密，防止中间人攻击。

综合评估后，推荐采用“后端统一下单 + 前端跳转授权”作为标准模式，既符合支付平台规范，又从根本上规避了浏览器安全策略带来的兼容性问题。