直接协议 4.00 - ThreeDSRequestorPriorAuthenticationInfo.threeDSReqPriorRef - 我如何填充它？答案

【问题标题】：Direct Protocol 4.00 - ThreeDSRequestorPriorAuthenticationInfo.threeDSReqPriorRef - how do I populate this?直接协议 4.00 - ThreeDSRequestorPriorAuthenticationInfo.threeDSReqPriorRef - 我如何填充它？
【发布时间】：2019-12-25 14:02:52
【问题描述】：

我想知道如何填充字段。

直接集成规范的“A1.2 ThreeDSRequestorPriorAuthenticationInfoXML”部分说明

3DS 请求者先前交易身份验证信息包含有关在当前交易之前发生的 3DS 持卡人身份验证的可选信息。

threeDSReqPriorRef 字段有描述：

此数据元素向 ACS 提供附加信息，以确定处理请求的最佳方法。它将包含先前已验证交易的 ACS 交易 ID（例如，与持卡人验证的第一笔重复交易）。此 ID 将在未来通过 My Sage Pay 和 Reporting and Admin API 提供。

显然提供一个先前的参考会“更好”，但我想知道如何填充它？

所以我正在查看 CReq 的内容：

{
  "messageType" : "CReq",
  "messageVersion" : "2.1.0",
  "threeDSServerTransID" : "0868ead0-8e3e-4c29-be1a-9689500b52fe",
  "acsTransID" : "44d368d3-31c5-472d-a27e-ad2fd2a75cc7",
  "challengeWindowSize" : "05"

我假设所需的数据是从acsTransID 获得的，我大概必须存储这些数据以备下次使用？但我在犹豫是否应该打开 CRreq，因为这似乎是一种万能的气味？（另请注意，来自 SagePay 测试系统的上述内容也不是有效的 JSON）

SagePay 肯定应该在回复中给出这个参考吗？（我真的不想使用 Reporting API 来获取参考 TBH ......这有点像老鼠窝）

【问题讨论】：

标签： opayo 3d-secure

【解决方案1】：

听起来您需要从损坏的 JSON 响应中提取 acsTransID 并使用它。这是一个最好的猜测。听起来 SagePay 目前并没有以任何形式返回它。

【讨论】：

我认为我不应该这样做。如果实时系统中的行为（或 CReq 的内容）不同怎么办？我必须解析 JSON，如果它不解析，请附加一个尾随花括号，然后重试。然后我遇到了字段不存在等问题。我想如果这一切都失败了，我会默认不存储任何东西。
是的，不是很好。这是一个可选值，所以我想您可以将其保留，直到它得到更好的支持。
我刚刚意识到从 CReq 中破坏 ACS 交易 ID 的另一个缺陷……大多数付款甚至没有 CReq，因为它们是“无摩擦的”。所以我对这个 TBH 有点难过。我目前已经准备好为经过大量单元测试的数据分解 CReq，如果它不起作用，它不会使事务失败。烦人的是一个半生不熟的 SagePay 解决方案。

【解决方案2】：

您可以找到如何重定向 3DAuth 的详细信息，持卡人姓名为“Challenge”，但仍然没有将 3D 值发送到银行的完整解决方案。

Sagepay - Payment Authorised despite 3dSecure Failure

【讨论】：