我在许多小型企业电子商务网站中看到的一个共同特征是，当我单击“结帐”按钮时，我被带离网站并被重定向到第三方支付网关（如 paypal、authorize.net 等）的 url。 . 在此第 3 方网站上付款后，我被重定向回小型企业电子商务网站。
我想为我的一些客户简化这个过程。我计划制作一个付款表格，其他人可以通过 iframe 将其嵌入到他们的网站中。付款表格将位于 SSL 后面。当我的支付表单收到信息时，我会将其传递给像 paypal 这样的商家网关，并使用成功/失败响应重新加载 iframe。
这种 iframe 方法有什么重大问题吗？我之所以问，是因为我不记得像 paypal 这样的支付网关为其支付页面提供 iframe 嵌入代码，尽管提供它似乎是一件微不足道的事情。如果他们可以向网站所有者提供结帐 url 以嵌入到他们的页面中，他们应该同样能够轻松地提供 iframe 嵌入代码。
HTTPS 连接安全性的一个基本方面是验证远程方的身份。与某人秘密交换数据是一回事，但您需要知道与谁。
从技术角度来看，服务器的身份是使用其证书来验证的：
然而，技术方面只是解决方案的一部分。用户需要能够看到浏览器正在尝试连接的站点。这是一个用户界面问题，只有用户可以检查浏览器正在尝试做什么，因为它的 UI 正在显示什么（期望大多数用户使用开发人员工具是不现实的）。
使用 iframe 会隐藏用户为该 iframe 实际连接的站点的名称（地址栏中仅显示主页的地址）。这可以防止用户进行此验证。
此外，如果 HTTPS iframe 位于 HTTP 页面中，情况会更糟，在这种情况下，用户甚至根本无法检查是否使用了 HTTPS。
嵌入式 iframe 有一些不好的例子，特别是3-D Secure，因为 (a) 它建议使用 iframe 和 (b) 即使不使用 iframe，该名称通常与用户的银行无关，商户网站或信用卡公司。
一个潜在的问题（作为用户，我实际上遇到了）是托管页面可能不会使用 SSL，并且在有关成为精明的 Internet 购物者的文章中告诉人们要寻找的小“提示”。由于用户谨慎，可能会在最后一刻失去销售。
跨域脚本也存在潜在问题。这是一个巨大的话题，即使您希望它成为可能，也可能非常具有挑战性，但这并非不可能，因此存在滥用的可能性。