3DSecure 定期超时但正在付款答案

【问题标题】：3DSecure periodically timing out but taking payment3DSecure 定期超时但正在付款
【发布时间】：2020-03-12 16:41:39
【问题描述】：

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

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

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

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

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

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

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

有人有什么想法吗？

谢谢

【问题讨论】：

我在客户网站上遇到了同样的问题。在这种情况下，它开始于 4 月中旬左右。我今天才知道这个问题，我会仔细调查，如果我找到任何可以帮助解决它的方法，请告诉您。
我从来没有真正深入了解这个问题。我确实创建了一个普通的独立页面来处理发给第三方推荐人的帖子，因为 Sage 的建议是我可能在托管 iframe 的页面上有图像或 Javascript，这些图像或 Javascript 被授权者随机阻止。这减少了失败的数量，但没有对所有失败进行排序，所以最后我不得不关闭 3DS。
我正在等待 Sage 推出 3DS 的第 2 版，希望新的过程可能更宽容一点。与此同时，自从 3DS 被关闭以来，我在付款方面的此类失败次数为零，因此我可以高度自信地说，问题出在某些类型的 3DS 授权请求上。对于即将实施的解决方案来说，这很奇怪，而且不是一个好的结果。感谢您在某个时候找到的任何修复程序。
我发现我的系统问题是由于客户在 SagePay 的最后一次响应后“退出”并导致订单未完成。我为 iFrame 使用了模态。我删除了模式并在接收 SagePay 响应的页面上添加了一个按钮。该按钮执行回发，一切似乎都很好。我最好的猜测是服务器（Microsoft）更新导致了我的问题。
我也在等 v2。目前还没有消息会发生什么。

标签： opayo

【解决方案1】：

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

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

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

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

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

【讨论】：

我完全同意。这绝对是一团糟。我们从支持中提取了 sn-ps，例如“是的，在拨打电话之前请稍等一下，否则您将得到 1017”，但在任何地方都没有记录。不可行（好吧勉强可行）幂等性令人沮丧。 Opayo 刚刚将 API 文档复制并粘贴到他们的网站上，认为他们已经购买了一个柠檬，任何人下一次升级到 Stripe/Adyen/Braintree/Square

【解决方案2】：

我们最近增加了一些我认为可能是相同的东西。基本上客户会被发送到 3ds 页面，然后返回到回调页面，但由于我无法解释的原因，PHP 会话不会重新建立。对回调页面的 POST 响应足以识别订单并完成订单（因为我们已付款），但随后会提示客户再次登录 - 然后他们会看到他们的购物篮中仍有产品并下第二个订单（这将成功通过）。

经过数小时的调试和更改后，我设法在使用移动仿真的同时将其复制到开发服务器上...

长话短说，我所做的是补充：

session_regenerate_id();

当我执行初始 vsp 注册 CURL（这是您获得 ACSURL 的 CURL）时。到目前为止，这似乎足以确保在客户返回回调页面时重新建立会话。

【讨论】：