ISO-8583消息处理(定义消息的优先级)

时间:2019-04-19 09:50:38

标签: iso8583

我需要了解ISO-8583消息平台,让我说我想执行卡交易授权,因此在特定情况下实时地说我收到了来自网络的100000个请求(VISA / MASTERCARD)全部用于授权,如何定义请求和响应的优先级,连接池是否可以处理它(在我的情况下为HIKARI),银行/金融机构如何完成对请求的授权。请向我提供一些见解来管理所有这些请求。我应该申请MQ吗?

使用的技术有:-spring boot,休眠,spring-tcp-starter

2 个答案:

答案 0 :(得分:0)

您的问题似乎没有得到很好的研究,因为今天有大量的交换平台可以在网上找到,并且他们的许多技术指南都可以在网上找到,包括ACI,FIS,AJB等主要供应商,..等,如果您看起来足够的话。

我已经处理过多个iso接口规范,商用交换机和本地平台,实际上它们在执行核心实时处理方面非常一致。

关于优先级排序的信息通常在每个ISO-8583消息处理规范中都有,并且在我所读过的几乎每个规范中,都是由熟悉ISO-8533的人编写的,而不仅仅是构成自己的变体或复制别人。

也就是说,一般而言,授权/财务(0100,0200)请求始终具有比强制发布(0x20)消息更高的优先级。

05xx,06xx和08xx中的管理消息有时也会比其他建议高。.但是这些仍然是建议,几乎总是先处理身份验证/财务信息,因为它们A)影响客户B)计时器更紧凑比任何建议都多一倍甚至更多。

我见过的大多数开关都完全在内存中完成它,而无需使用MQ和或其他用于核心授权过程的磁盘来管理它们。.但这并不是说有时没有某种本地化的中间件。非实时进程通常使用MQ进程将这些队列或磁盘排队到不符合此存储转发(SAF)处理批准顺序的进程中。但是,其中许多仍使用仅用于前端的内存处理他们的队列。

同样重要的是,还要区分100000个请求和100000个事务。内部和外部的各种交换即使在给定的时间内在飞行中的实际请求/响应的数量也有很大的不同。.基本事务可以完成就像两条消息一样..但是,对于预授权或完成组件而言,某些更复杂的消息可以轻易超过20条消息。

如果您要处理大量的批处理事务突发。我可以看到排队的挑战,但是我看到的几乎每个应用程序在建议和请求之间都在最大程度上相互分离..甚至有时使用不同的计时器。和发送交易的应用程序几乎总是等待响应返回,然后再发送更多信息,这对几乎每个人都适用,包括零售商和信用卡网络的大量发贴。因此,如果您的应用程序没有它们..您可能需要添加它们。

答案 1 :(得分:0)

实际上,您的100000个请求应按(终端ID和/或商家ID)+(时间戳/本地时间戳)+(STAN和/或RRN)进行排序。 重复的交易请求有望被拒绝。

如果您使用相同的测试卡模拟来自单个终端(或主机)的多个请求,则STAN / RRN会增加。

请参考有关STAN和RRN ISO 8583字段的先前答案。 In ISO message, what's the use of stan and rrn ?