opayo - 3DSecure 定期超时但接受付款

Question

当卡付款发起 3DSecure 质询时，我在 SagePay Direct 中遇到了一个非常令人沮丧的问题。

客户报告 iFrame 挂起或付款被拒绝响应。更糟糕的是，在某些情况下，Sage 收取了付款，但用户没有意识到这一点并尝试再次购买查看我的日志，我的代码按预期工作，并且正在加载 iFrame，并将返回的 ACSURL 作为 src。

搜索网络后，这似乎是一个已知问题，我移交给的安全商家发行人发生超时。

我遇到的问题是，我无法控制发行者的响应(或缺乏响应)，因为它位于 iFrame 中。

Sage 并没有对这个问题提供太多帮助，只是说“我们听说有客户遇到过这个问题”

有谁有过这个问题的经验并知道如何解决吗？我想底线是关闭 3DSecure 检查，但这似乎对欧盟在某个时候生效的新裁决产生反作用。

值得指出的是，这仅影响了我的一小部分客户群，并且许多交易正在成功处理(即使有密码挑战)，但遇到问题的客户理所当然地大声喊叫。

有人有什么想法吗？

谢谢

Answer 1

我们每天通过 SagePay 使用 Direct 协议(protocol)处理多达 1000-2000 笔交易。他们非常便宜，但老实说他们的服务相当糟糕。我们每天都有个位数的交易以这种方式失败。我们还有另一家提供商，但没有遇到同样的问题。

我们有一项例行工作，向 SagePay Reporting API 询问失败的交易，以查看当前状态(SagePay 是否收到交易？是否已成功授权？等)。这个 API 非常非常糟糕，集成起来简直就是一场噩梦，但它很有用，因为至少我们可以在不登录 SagePay 仪表板的情况下向客户退款。

---

我们发现的一件事(据我所知，SagePay 网站上任何地方都没有记录)是，您一次只能进行一笔交易，或者大约 20-默认情况下每分钟 30 笔交易。如果您超过了这个时间(临时高峰或其他什么)，您的交易就会排队并被延迟。如果它变得真的很忙，它就会完全崩溃，并且需要一段时间才能恢复。因此，我们不得不完全关闭 SagePay 几个小时(我们已经做好了备份)。

无论如何，事实证明我们的交易都是在一个 TID(终端 ID 的缩写)上处理的。这类似于商店中的物理卡终端，一次只能处理一笔交易。我们请求 SagePay 支持更多，现在我们有 10-15 个。

---

希望这对您有帮助。我建议实现后备支付供应商，以防 SagePay 失败。一两年前，他们发生了 3 天(!!!) 的停电，这对我们来说是相当毁灭性的。我们现在认真对待这个问题!