Hostinger 网站嵌入 iframe 代码在支付时超时

结论

这通常不是 Hostinger 服务器在处理支付时发生了”超时”，而是支付流程位于跨域 iframe 中，受到了第三方 Cookie、跨站跟踪防护、弹窗或跳转限制、安全策略、支付域名白名单等因素的影响。

预约阶段只需读写普通表单数据，所以可以正常运行。进入支付阶段后，系统通常需要创建跨域会话、设置 Cookie、加载支付网关，或者跳转到验证页面。只要其中一个环节被浏览器、Hostinger 页面配置或支付服务商拦截，页面就可能持续加载，最后显示超时。

优先排查的原因

1. 第三方 Cookie 被阻止

Hostinger 页面与预约组件使用的不是同一个域名：

• 外层页面：Hostinger 网站域名
• 内嵌页面：app.youngmindshypnotherapy.co.uk
• 支付页面：还可能使用 Stripe 等其他域名

如果支付会话依赖第三方 Cookie，而 Cookie 未正确设置 SameSite=None; Secure，那么它在 iframe 中可能无法维持登录状态或支付状态。Safari、Firefox，以及开启了严格隐私设置的 Chrome，更容易遇到这类问题。

可以用无痕窗口和其他浏览器进行测试。如果关闭跨站跟踪防护后支付恢复正常，问题基本与 Cookie 或浏览器隐私策略有关。关闭浏览器安全设置只适合用来诊断，不能作为提供给访客的正式解决办法。

2. 支付网关不允许在 iframe 中完成验证

部分支付流程需要打开新窗口、跳转到银行页面，或者执行 3-D Secure 验证。支付服务商可能通过以下机制限制嵌入：

• Content-Security-Policy: frame-ancestors
• X-Frame-Options
• 弹窗拦截
• 顶层页面跳转限制
• 第三方支付域名的嵌套 iframe 限制

这些限制通常到了支付阶段才会触发。因此，即使不含支付的日历可以正常使用，也不能排除嵌入兼容性问题。

3. Hostinger 页面设置了 CSP 或 iframe 限制

如果 Hostinger 网站启用了安全响应头、Cookie 同意工具、脚本优化或防火墙规则，支付阶段动态加载的新域名可能会被拦截。常见的控制项包括：

• script-src
• frame-src
• connect-src
• form-action
• frame-ancestors

只把预约组件的域名加入白名单可能还不够，还要允许支付网关实际使用的脚本、接口和嵌套页面域名。具体需要放行哪些域名，应以浏览器控制台报错和 LeadConnector 支付集成文档为准，不要直接将规则放宽为 *。

4. LeadConnector 或支付平台没有登记当前网站域名

有些支付组件会校验来源域名、回调地址或允许的重定向地址。WordPress 测试站点可能已经获得授权，但 Hostinger 网站使用的域名，或其 www、非 www 版本，可能尚未加入配置。

需要检查：

• 当前正式域名是否已加入允许来源或授权域名
• https://example.com 和 https://www.example.com 是否都已考虑
• 支付成功及取消支付的回调地址是否正确
• 网站是否全程使用 HTTPS
• 是否会从一个域名版本跳转到另一个版本

5. 嵌入代码被页面编辑器改写

示例代码最外层带有反引号：

`<iframe ...></iframe><br><script ...></script>`

如果反引号只是提问时使用的排版符号，可以忽略。如果它们也被粘贴到了 Hostinger 的 HTML 区块中，则需要删除。还要确认代码放在”自定义 HTML/嵌入代码”组件中，而不是普通文本组件中。

建议的排查步骤

在出现超时的页面中打开浏览器开发者工具，然后重新完成一次支付流程：

1. 在 Console 中查找与 CSP、Cookie、跨域、弹窗或 X-Frame-Options 有关的报错。
2. 在 Network 中筛选失败或长时间停留在 Pending 状态的请求。
3. 查看失败请求的域名、HTTP 状态码和响应头。
4. 检查是否出现 blocked by Content Security Policy、third-party cookie、refused to frame、CORS 或 popup blocked 等信息。
5. 临时停用 Hostinger 页面上的 Cookie 管理、脚本延迟加载和第三方脚本优化功能，并分别测试。
6. 使用不同浏览器和移动网络访问同一个 Hostinger 页面链接，借此区分浏览器限制、网络问题和页面配置问题。

如果控制台显示某个支付域名被 CSP 阻止，只添加报错中确实需要的可信域名。如果出现 X-Frame-Options 或 frame-ancestors 拒绝加载的报错，说明限制来自被嵌入服务的服务器端，无法通过修改外层 HTML 绕过。

推荐的嵌入代码

可以先整理嵌入代码，删除多余的反引号和 <br>：

<iframe
  src="https://app.youngmindshypnotherapy.co.uk/widget/booking/RiQVGOr8LeygJHkkEaK6"
  id="RiQVGOr8LeygJHkkEaK6_1739904432678"
  title="Booking calendar"
  style="width: 100%; border: 0; overflow: hidden;"
  scrolling="no"
></iframe>

<script
  src="https://app.youngmindshypnotherapy.co.uk/js/form_embed.js"
  type="text/javascript"
></script>

不要自行添加过于严格的 sandbox 属性。例如，下面的配置可能会阻止表单提交、弹窗和支付跳转：

<iframe
  src="https://example.com"
  sandbox
></iframe>

如果 Hostinger 编辑器自动为嵌入内容添加沙箱限制，需要检查它是否允许支付流程所需的权限。具体需要哪些 allow-* 权限，取决于 LeadConnector 和支付网关的实现。在没有错误日志的情况下无法确定。

最可靠的解决方式

如果支付服务没有明确说明它支持跨域 iframe，建议不要让用户在嵌入框内付款，而是通过顶层页面打开预约地址：

<a
  href="https://app.youngmindshypnotherapy.co.uk/widget/booking/RiQVGOr8LeygJHkkEaK6"
  target="_blank"
  rel="noopener noreferrer"
>
  打开预约和支付页面
</a>

页面在顶层打开后，不再处于第三方 iframe 环境，通常可以避开第三方 Cookie、3-D Secure 跳转和嵌套页面限制。也可以继续嵌入日历，同时保留这个链接，作为支付失败时的备用入口。

如果顶层页面可以正常支付，而嵌入 Hostinger 页面后失败，基本可以确定问题出在跨域嵌入限制，而不是日历本身，也不是 Hostinger 的 PHP 或服务器执行超时。此时，应将 Console 和 Network 中的具体错误、Hostinger 页面地址以及失败请求的域名提供给 LeadConnector 和 Hostinger 支持方，请他们确认需要加入的允许域名或调整的安全策略。

备注：内容仅供参考。