3DSecure 周期性超时但收款
3DSecure periodically timing out but taking payment
当卡支付发起 3DSecure 质询时，我遇到了一个非常令人沮丧的 SagePay Direct 问题。
客户报告 iFrame 挂起或拒绝付款响应。更糟糕的是，在某些情况下，Sage 收取了款项，但用户并不知道这一点并尝试再次购买
查看我的日志，我的代码按预期工作，并且正在使用返回的 ACSURL 作为 src 加载 iFrame。
在网上搜索后，我发现这是一个已知问题，即我转交给的安全商户发卡机构发生超时。
我遇到的问题是我无法控制来自发行人的响应（或缺乏响应），因为它在 iFrame 中。
Sage 对这个问题的帮助不大，只是说 "we have heard of customers who experience this issue"
有没有人遇到过这个问题并且知道如何解决？我想最重要的是关闭 3DSecure 检查，但这似乎与在某个时候生效的新欧盟裁决适得其反。
值得指出的是，这只影响了我客户群的一小部分，很多交易都在成功处理（即使密码挑战），但遇到问题的客户大声喊叫是正确的。
有人有什么想法吗？
谢谢
我们每天使用 Direct 协议通过 SagePay 处理多达 1000-2000 笔交易。它们非常便宜，但老实说，它们的服务相当糟糕。我们每天 有一位数的交易以这种方式失败。我们还有另一家供应商，没有遇到同样的问题。
我们有一项例行工作，询问 SagePay 报告 API 有关失败的交易，以查看当前状态（SagePay 是否收到交易？是否已成功授权？等）。这个 API 非常非常糟糕，集成起来简直就是一场噩梦，但它很有用，因为至少我们可以在不登录 SagePay 仪表板的情况下为客户退款。
我们发现的一件事（据我所知，在 SagePay 网站上任何地方 都没有记录）是您一次只能进行一笔交易，或者默认情况下每分钟大约 20-30 个事务。如果你超过这个（临时高峰或其他），你的交易就会排队并被延迟。如果它变得 真的很忙 它就会完全崩溃，并且需要一段时间才能恢复。由于这个原因，我们不得不完全关闭 SagePay 几个小时（我们有备份）。
无论如何，事实证明我们的交易都是在一个 TID（Terminal ID 的缩写）上处理的。这类似于商店中的实体卡终端，一次只能处理一笔交易。我们要求 SagePay 支持更多，现在我们有 10-15 个。
希望对您有所帮助。我建议实施后备支付供应商以防 SagePay 失败。一两年前，他们发生了 3 天 (!!!!) 的中断，这对我们来说是相当毁灭性的。我们现在认真对待这件事！
我们最近增加了我认为可能是同一件事的事情。基本上客户会被发送到 3ds 页面，然后返回到回调页面，但由于我无法解释的原因，PHP 会话不会重新建立。 POST 对回调页面的响应足以识别订单并完成它（因为我们已经付款），但随后会提示客户再次登录 - 然后他们会看到他们的购物篮仍然有产品并下第二个订单（这将成功完成）。
经过数小时的调试和更改后，我设法在使用移动仿真的同时将其复制到开发服务器上...
长话短说，我所做的是添加：
session_regenerate_id();
当我执行初始 vsp 注册 CURL（这是您获得 ACSURL 的 CURL）。到目前为止，这似乎足以确保在客户 returns 到回调页面时重新建立会话。
当卡支付发起 3DSecure 质询时，我遇到了一个非常令人沮丧的 SagePay Direct 问题。
客户报告 iFrame 挂起或拒绝付款响应。更糟糕的是，在某些情况下，Sage 收取了款项，但用户并不知道这一点并尝试再次购买 查看我的日志，我的代码按预期工作，并且正在使用返回的 ACSURL 作为 src 加载 iFrame。
在网上搜索后，我发现这是一个已知问题，即我转交给的安全商户发卡机构发生超时。
我遇到的问题是我无法控制来自发行人的响应（或缺乏响应），因为它在 iFrame 中。
Sage 对这个问题的帮助不大，只是说 "we have heard of customers who experience this issue"
有没有人遇到过这个问题并且知道如何解决？我想最重要的是关闭 3DSecure 检查，但这似乎与在某个时候生效的新欧盟裁决适得其反。
值得指出的是，这只影响了我客户群的一小部分，很多交易都在成功处理（即使密码挑战），但遇到问题的客户大声喊叫是正确的。
有人有什么想法吗？
谢谢
我们每天使用 Direct 协议通过 SagePay 处理多达 1000-2000 笔交易。它们非常便宜，但老实说，它们的服务相当糟糕。我们每天 有一位数的交易以这种方式失败。我们还有另一家供应商，没有遇到同样的问题。
我们有一项例行工作，询问 SagePay 报告 API 有关失败的交易，以查看当前状态（SagePay 是否收到交易？是否已成功授权？等）。这个 API 非常非常糟糕，集成起来简直就是一场噩梦，但它很有用，因为至少我们可以在不登录 SagePay 仪表板的情况下为客户退款。
我们发现的一件事（据我所知，在 SagePay 网站上任何地方 都没有记录）是您一次只能进行一笔交易，或者默认情况下每分钟大约 20-30 个事务。如果你超过这个（临时高峰或其他），你的交易就会排队并被延迟。如果它变得 真的很忙 它就会完全崩溃，并且需要一段时间才能恢复。由于这个原因，我们不得不完全关闭 SagePay 几个小时（我们有备份）。
无论如何，事实证明我们的交易都是在一个 TID（Terminal ID 的缩写）上处理的。这类似于商店中的实体卡终端，一次只能处理一笔交易。我们要求 SagePay 支持更多，现在我们有 10-15 个。
希望对您有所帮助。我建议实施后备支付供应商以防 SagePay 失败。一两年前，他们发生了 3 天 (!!!!) 的中断，这对我们来说是相当毁灭性的。我们现在认真对待这件事！
我们最近增加了我认为可能是同一件事的事情。基本上客户会被发送到 3ds 页面，然后返回到回调页面，但由于我无法解释的原因，PHP 会话不会重新建立。 POST 对回调页面的响应足以识别订单并完成它（因为我们已经付款），但随后会提示客户再次登录 - 然后他们会看到他们的购物篮仍然有产品并下第二个订单（这将成功完成）。
经过数小时的调试和更改后，我设法在使用移动仿真的同时将其复制到开发服务器上...
长话短说，我所做的是添加：
session_regenerate_id();
当我执行初始 vsp 注册 CURL（这是您获得 ACSURL 的 CURL）。到目前为止，这似乎足以确保在客户 returns 到回调页面时重新建立会话。