3

我们的系统接收我们适当解码和处理的 ISO8583 消息。现在我们收到了系统无法处理的无效 ISO 消息。事实上，它没有任何回报。这会导致另一端超时。结果，（无效的）交易被还原，然后导致相当混乱，因为没有什么可以还原。

谁能给我一个关于如何处理/回答无效/不可解码的 ISO8583 消息的线索？是否有标准答案（例如“NAK”之类的）？

4

3 回答 3

3

根据 ISO-8583 规范，6XX（或者16XX，如果您使用的是 '93 版本）类消息适用于管理通知。通常，a644或1644MTI 用于通知发件人处理消息的问题，其中

  • X6XX - 表示管理消息，通常包含失败的详细信息

  • XX4X - 表示消息是通知；发件人不得重复消息

  • XXX4 - 表示消息的来源（acquirer/issuer/other）；这里是其他

综上所述，您的消息至少应包含以下字段

  1. MTI： 1644
  2. DE-24（功能代码）： 650（无法解析消息）

当然，您要包括标准消息标识字段：DE-7、11、12、39。这些字段对于消息发送者将您的响应与请求匹配是必需的。

于 2015-02-03T03:15:09.687 回答
1

我认为没有处理无效 ISO 8583 请求消息的标准方法。您没有说明为什么会收到无效的请求消息，并且不知道很难建议您应该如何处理它们。

根据具体情况，最好不要回答无效的 ISO 8583 请求。事实上，我知道一些系统不仅不会回复无效请求消息，还会将发送无效消息的设备列入黑名单并拒绝回复来自它的所有其他消息。

如果您决定不响应无效请求消息，那么您发现客户端可能会超时，然后尝试撤销事务。这通常不是问题，因为服务器通常会以批准消息响应对不存在的交易的撤销请求。请记住，当客户端在发送请求后超时时，它不知道请求是否被处理，甚至不知道请求是否被接收。因此，服务器必须准备好同时处理 1. 接收和处理的请求（通过撤消事务然后以批准响应），以及 2. 从未接收/处理的请求（通过发送批准）。注意：在情况 2 中，不需要撤消事务，因为事务从未发生过。

于 2015-02-03T06:24:36.910 回答
1

根据我在集成 ISO 链接方面的经验，按照行业标准，无效的 ISO 消息通常是通过断开获取主机的连接来处理的，然后是来自获取方服务提供商的愤怒邮件，指责您对他们的大型机进行分段故障。

除了不同的实现，如果实现得当，将处理不同的无效消息，从@kolossus 所说的以防解析器完全失败，到带有特定响应代码的正常 **10 响应，例如 RC 12“无效事务”某些子字段没有意义（例如使用标记打包复杂子字段的问题、track2 解析等）

@kolossus 解决方案没有真正意义以及 Stuard 有观点的实际原因是，如果客户端在形成 ISO 消息时遇到问题，那么它几乎肯定在解析它们时也存在问题，所以另一条 ISO 消息不会除了在他身边引发解析器异常之外，不会真正告诉客户任何事情。

最终结果将是相同的 - 客户的技术逆转，而不是在超时之后。基本上，使用 iso8583，处理无效消息的最佳方法是不拥有它们，没有干净的方法。

于 2016-08-06T07:13:28.100 回答