PayPal SDK v6：onApprove 未触发与 FraudNet CORS 错误

2026-11-04支付阿杰

从日志看，FraudNet 请求存在 CORS Origin 不匹配。如果该响应头由 PayPal 服务返回，商户修改自己网站的 CORS 配置无法解决问题。不过，现有日志还不能证明 FraudNet 失败直接导致 onApprove 未触发。下一步应确认订单的实际状态，并结合弹窗中的失败请求检查审批过程。

CORS 报错能说明什么？

日志中的请求来源是：

https://www.sandbox.paypal.com

响应允许的来源却是：

Access-Control-Allow-Origin: https://www.paypal.com

这两个 Origin 不相同。按日志所示，浏览器因此拒绝了预检请求，相关跨域请求无法按预期继续。

这说明该请求存在跨域访问问题，但不能单凭它认定整个 checkout 因此中断。Interrupted、CSP 报错和弹窗持续加载也可能是同一故障的不同表现，需要结合请求顺序、订单状态及服务端日志判断。

订单创建成功并返回 CREATED，也只说明创建订单这一步成功，不能据此认定买家已完成审批，或 SDK 的所有调用参数都正确。

先确认订单停在哪一步

复现时记录本次 orderId，再由服务端查询订单状态。查询所用的账户和 API 环境应与创建订单时一致，凭据保留在服务端。

如果订单仍为 CREATED，继续检查买家审批阶段的请求。目前尚无证据表明审批已经完成。
如果订单已为 APPROVED，但前端没有收到 onApprove，重点检查审批结果如何传回商户页面，以及会话是否仍然有效。
如果订单已经产生 capture 结果，核对服务端记录和 capture 状态，防止重复处理。

不要因为弹窗卡住或出现 CORS 报错，就直接调用 capture 或把订单标记为支付成功。后续操作必须以服务端核实的订单状态和支付结果为依据。

给会话调用补充可定位的日志

原示例没有展示 start() 抛出异常时的处理。可以先在现有调用外增加日志，确认问题是否也表现为 Promise 拒绝：

paypalBtn.addEventListener("click", async function () {
  console.info("PayPal session starting", {
    orderId: serverGeneratedOrderId
  });

  try {
    await paypalSession.start(
      { presentationMode: "auto" },
      Promise.resolve({ orderId: serverGeneratedOrderId })
    );
    console.info("PayPal session.start resolved");
  } catch (error) {
    console.error("PayPal session.start rejected", error);
  }
});

这段代码只为原调用增加观测点，并不代表已验证其符合所用 v6 SDK 的完整接口要求。还应在现有 onApprove、onCancel 和 onError 的入口分别记录时间及必要参数，并保留原有业务逻辑。

createInstance 的初始化参数、会话创建方式和 start() 的参数约定都需要单独核对。弹窗 URL 中出现 JS_SDK_V6，不能替代这些检查。start() 返回也不应直接作为支付成功的依据。

在 PayPal 弹窗里检查失败请求

打开弹窗自身的 DevTools，启用 Preserve log，重新创建订单并复现。重点记录：

/p1、/p2、/w 对应的 OPTIONS 请求状态、请求头 Origin、响应头和重定向链。
点击“Pay Now”后，审批相关请求是否发出，以及哪些请求最先失败。
CORS、CSP 和 Interrupted 的出现时间，以及它们与订单状态变化的关系。

两个浏览器和两个测试账户都能复现，降低了单一浏览器或账户问题的可能性，但仍不能直接确定故障归属。可以再用无扩展的干净浏览器配置测试一次；若使用了 VPN、代理或流量过滤工具，也应检查它们是否影响响应。

商户页面的 CSP 能修复这些错误吗？

应先确认 CSP 错误属于哪个文档。如果错误确实发生在 PayPal 托管的 hermes 页面，修改商户页面的 CSP 无法替该页面放行 'unsafe-eval' 或 blob: worker。

在商户服务器上添加 Access-Control-Allow-Origin，也不会改变 c.paypal.com 的响应头。给请求添加同名头或改用 no-cors，都无法为原请求取得所需的跨域访问权限。

不要通过关闭浏览器安全检查或代理改写 PayPal 风控请求作为上线方案。

何时提交给 PayPal 排查？

如果干净环境仍可复现，且弹窗 Network 记录确认 PayPal 服务对 Sandbox Origin 返回了不匹配的允许来源，应将证据提交给 PayPal 技术支持。报告中保留：

复现时间及其时区、SDK 地址、浏览器版本和最小复现步骤。
本次 orderId、服务端查询到的订单状态及相关 API 调试标识。
弹窗中的 CorrelationID：1VU87823S2094644K。
预检请求的请求头、响应头、状态码及错误时间顺序。
已脱敏的 HAR 和最小集成代码。

提交 HAR 前删除 Cookie、访问令牌、授权头和个人信息。描述故障时，可以写明“Sandbox 请求收到仅允许生产 Origin 的响应头”，并将“该错误导致审批回调缺失”列为待确认的关联，以便对方核查服务端日志。

现有金额明细满足 445.38 + 84.62 + 0.00 = 530.00，但金额加总一致不能验证完整请求或审批流程。当前应优先取得订单状态和弹窗网络证据，再决定是修正接入代码，还是等待 PayPal 修复托管服务问题。