如何回复无效的ISO8583消息

Question

我们的系统接收ISO8583消息，我们对其进行适当的解码和处理。现在，我们收到了系统无法处理的无效ISO消息。事实上，它不会发送任何回报。这会在另一端导致超时。结果，(无效的)事务被恢复，这导致了相当大的消息，因为没有什么需要恢复的。

谁能给我一个关于如何处理/回答无效/无法解码的ISO8583消息的提示？是否有标准答案(例如‘'NAK’就像)？

Answer 1

根据ISO-8583规范，6XX (如果您使用的是'93版本，则为16XX )-class消息适用于管理通知。

• X6XX -表示管理消息，通常包含failure
• XX4X的详细信息-表示该消息是通知；发件人不重复该消息
• XXX4-表示消息的来源(acquirer/issuer/other)；此处为Other

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

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

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

Answer 2

我不认为有一个标准的方法来处理无效的ISO8583请求消息。您没有说明为什么会收到无效的请求消息，也不知道如何处理它们很困难。

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

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

Answer 3

根据我在集成ISO链接方面的经验，根据行业标准，无效的ISO消息通常是由访问主机的连接下拉列表处理的，然后是来自收购方服务提供商的愤怒邮件，指责您在其大型机上分段故障。

除此之外，当很好地实现时，不同的实现将以不同的方式处理无效消息，不同于@kolossus在解析器完全失败的情况下所说的，而是在一些子字段没有意义时使用特定响应代码(如RC 12“无效事务”)的正常**10响应(例如，使用令牌打包复杂子字段的问题，track2解析等)。

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

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