时间戳

首页 > 解决方案 > 3DSecure 定期超时但正在付款

opayo - 3DSecure 定期超时但正在付款

问题描述

当信用卡支付引发 3DSecure 挑战时，我在使用 SagePay Direct 时遇到了一个非常令人沮丧的问题。

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

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

我遇到的问题是我无法控制发行人的响应（或缺乏），因为它在 iFrame 中。

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

有没有人有这个问题的经验并知道如何解决它？我想底线是关闭 3DSecure 检查，但这似乎与新的欧盟裁决适得其反。

值得指出的是，这只会影响我的一小部分客户群，并且很多交易都在成功处理（即使有密码挑战），但遇到问题的客户大声喊叫是正确的。

有人有什么想法吗？

谢谢

标签： opayo

解决方案

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

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

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

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

我希望这可以帮助你。如果 SagePay 失败，我建议实施后备支付供应商。一两年前，他们有 3 天（！！！！！！）停电，这对我们来说是相当毁灭性的。我们现在认真对待这件事！

推荐阅读