CN114187999A - 一种医院统一支付管理平台及控制方法 - Google Patents

Abstract

本发明公开了一种医院统一支付管理平台及控制方法，应用于通信技术领域，包括第一服务器和第二服务器。第二服务器，被配置为：监听第一服务器的接收端口；根据获取交易ID的时间建立第一队列；根据获取交易ID的时间建立第二队列；将同时存在于第一队列和第二队列的交易ID从第一队列中移除；从第一队列中选出第一交易ID建立第三队列；当从第二队列检测到第一交易ID时，从第三队列中移除第一交易ID。本发明一种医院统一支付管理平台及控制方法，通过第二服务器对交易ID进行监控，并且直接检索出未完成交易的交易ID，有效降低了对账时服务器的计算压力，也避免了在海量数据中检索时产生的错误和误差。

Description

一种医院统一支付管理平台及控制方法

技术领域

本发明涉及通信技术领域，具体涉及一种医院统一支付管理平台及控制方法。

背景技术

目前应用在现代化医院的支付方式主要是通过医院和各金融机构直接对接，完成费用支付、退款等诸多操作。所以统一的支付平台应运而生，其为各医疗机构和金融机构提供统一的接口，从而减少网络接口，实现数据标准统一。

现有的医院统一支付平台与外部的数据交互普遍采用异步回调方式进行通知，这种方式可以及时的执行多个支付操作，大大加快多窗口的支付效率。但是由于异步回调的通知方式是不需要等待信息返回的，所以缺少对支付情况的监控，尤其是支付或退款迟迟得不到响应时，只能通过检索金融机构的回执进行对账等操作，造成平台本身计算压力增大，财务对账也不够精准。

发明内容

为了至少克服现有技术中的上述不足，本申请的目的在于提供一种医院统一支付管理平台及控制方法。

在一个方面，本申请实施例提供了一种医院统一支付管理平台，包括：

第一服务器，被配置为：

接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

第二服务器，被配置为：

监听所述第一服务器的接收端口；

在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

当从所述第二队列检测到所述第一交易ID时，从所述第三队列中移除所述第一交易ID。

本申请实施例实施时，第一服务器的主要作用和现有的医院统一支付平台作用较为类似，以一个中间平台的形式为医院终端和支付服务器提供统一的接口和信息交互，同时用户终端也需要和支付服务器进行交互实现身份验证等功能，从而形成完整的支付或者退款过程；其为现有技术在此不多做复述。同样的，本申请实施例中的支付服务器对应不同金融机构的服务器，如微信支付、支付宝支付或其他银行支付的服务器，在此不多做限定。

本申请实施例中，发明人发现现有的医院统一支付平台在进行对账时，需要先将未响应过的交易信息剔出进行单独核算，经常需要检查每笔交易信息的情况才能完成对账，极为不便，造成了平台计算资源的大量浪费，并且在对账过程中，平台基本是不能同步进行交易处理的。本申请实施例采用了第二服务器实现每一笔交易的监控，将未响应的交易挑选出来，便于后续对账使用。

具体的，第二服务器通过监听所述第一服务器的接收端口来获取数据，由于第一服务器需要进行信息收发，所以对于不同的医院终端和支付服务器会分配不同的接收端口和发送端口，在本申请实施例中，采用接收端口可以减少一半的数据获取率，提高数据获取效率。

具体的，第二服务器在监听所述接收端口时，主要获取第一交易请求的交易ID和第二交易结果的交易ID，在本申请实施例中交易ID是表征一项交易过程的特征，可以采用订单编号、交易编号、流水编号等可以表征一笔交易的特征，在此不多做限定。

具体的，第一队列是用于进行第一交易请求的监控的，而第二队列是用于进行第二交易结果的监控的，每次第二队列中出现了第一队列中的交易ID时，说明该交易结束，无论结果是退回、完成等可以标记其已经交易结束，此时将对应的交易ID移出第一队列，而一直没有完成交易ID会持续的留在第一队列中。本申请实施例中的这种方式类似于通过同步的方式检测异步线程是否返回的过程，既可以不阻塞异步线程，也可以对线程的返回情况进行检测。在第一队列中所保留的交易ID即为没有得到信息反馈的交易请求对应的交易ID，没有得到信息反馈的原因很多，主要原因在于支付服务器的响应不及时或者线路阻塞，尤其是在支付高峰期，很多金融机构的支付服务器会发生这种无法及时响应的问题。第一队列的存在可以在对账时便于查询未反馈的交易结果。同时，本申请实施例还设置了第三队列，第三队列是存在于第一队列中时长超过第一预设值的交易ID的集合；第一预设值根据对账周期进行设置，这样进行对账时，可以从第三队列中取出第一交易ID，避免了对未结交易重新检索查询的问题。

示例的，网络支付平台的对账周期采用1小时、3小时、6小时时，将第一预设值设置为1小时、3小时、6小时。

具体的，当进行对账时，所述第二服务器将所述第三队列中的第一交易ID发送至所述第一服务器；所述第一服务器对账时根据所述第一交易ID修正对账结果。修正方式为，第一服务器将所述第三队列中的第一交易ID从对账结果中剔除。本申请实施例实施时，通过第二服务器对交易ID进行监控，并且直接检索出未完成交易的交易ID，有效降低了对账时服务器的计算压力，也避免了在海量数据中检索时产生的错误和误差。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当从所述第一队列检测到存在于所述第三队列的第一交易ID时，向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，将该第一交易ID作为第二交易ID；

向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当根据所述第一历史数据对所述第二交易ID发出响应时，将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，向所述第一服务器发起垫付请求；

所述第一服务器，被配置为：

收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

在一种可能的实现方式中，所述第二服务器，还被配置为：

向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

在另一个方面，本申请实施例提供了一种医院统一支付管理平台控制方法，所述一种医院统一支付管理平台包括第一服务器和第二服务器；

所述方法包括：

第一服务器接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

第一服务器接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

第二服务器监听所述第一服务器的接收端口；

第二服务器在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

第二服务器在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

第二服务器轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

第二服务器从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

当从所述第二队列检测到所述第一交易ID时，第二服务器从所述第三队列中移除所述第一交易ID。

在一种可能的实现方式中，还包括：

当第二服务器从所述第一队列检测到存在于所述第三队列的第一交易ID时，第二服务器向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

在一种可能的实现方式中，还包括：

当第二服务器查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，第二服务器将该第一交易ID作为第二交易ID；

第二服务器向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

在一种可能的实现方式中，根据所述第一历史数据对所述第二交易ID发出响应包括：

第二服务器将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，第二服务器向所述第一服务器发起垫付请求；

第一服务器收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

在一种可能的实现方式中，还包括：

第二服务器向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当第二服务器监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

本发明与现有技术相比，具有如下的优点和有益效果：

本发明一种医院统一支付管理平台及控制方法，通过第二服务器对交易ID进行监控，并且直接检索出未完成交易的交易ID，有效降低了对账时服务器的计算压力，也避免了在海量数据中检索时产生的错误和误差。

附图说明

此处所说明的附图用来提供对本发明实施例的进一步理解，构成本申请的一部分，并不构成对本发明实施例的限定。在附图中：

图1为本申请实施例系统结构示意图；

图2为本申请实施例方法步骤示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请实施例的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其它操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其它实施例，都属于本申请保护的范围。

为了便于对上述的一种医院统一支付管理平台进行阐述，请结合参考图1，提供了本发明实施例所公开的一种医院统一支付管理平台的通信架构示意图。其中，所述一种医院统一支付管理平台可以包括：

第一服务器，被配置为：

接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

第二服务器，被配置为：

监听所述第一服务器的接收端口；

在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

当从所述第二队列检测到所述第一交易ID时，从所述第三队列中移除所述第一交易ID。

本申请实施例实施时，第一服务器的主要作用和现有的医院统一支付平台作用较为类似，以一个中间平台的形式为医院终端和支付服务器提供统一的接口和信息交互，同时用户终端也需要和支付服务器进行交互实现身份验证等功能，从而形成完整的支付或者退款过程；其为现有技术在此不多做复述。同样的，本申请实施例中的支付服务器对应不同金融机构的服务器，如微信支付、支付宝支付或其他银行支付的服务器，在此不多做限定。

本申请实施例中，发明人发现现有的医院统一支付平台在进行对账时，需要先将未响应过的交易信息剔出进行单独核算，经常需要检查每笔交易信息的情况才能完成对账，极为不便，造成了平台计算资源的大量浪费，并且在对账过程中，平台基本是不能同步进行交易处理的。本申请实施例采用了第二服务器实现每一笔交易的监控，将未响应的交易挑选出来，便于后续对账使用。

具体的，第二服务器通过监听所述第一服务器的接收端口来获取数据，由于第一服务器需要进行信息收发，所以对于不同的医院终端和支付服务器会分配不同的接收端口和发送端口，在本申请实施例中，采用接收端口可以减少一半的数据获取率，提高数据获取效率。

具体的，第二服务器在监听所述接收端口时，主要获取第一交易请求的交易ID和第二交易结果的交易ID，在本申请实施例中交易ID是表征一项交易过程的特征，可以采用订单编号、交易编号、流水编号等可以表征一笔交易的特征，在此不多做限定。

具体的，第一队列是用于进行第一交易请求的监控的，而第二队列是用于进行第二交易结果的监控的，每次第二队列中出现了第一队列中的交易ID时，说明该交易结束，无论结果是退回、完成等可以标记其已经交易结束，此时将对应的交易ID移出第一队列，而一直没有完成交易ID会持续的留在第一队列中。本申请实施例中的这种方式类似于通过同步的方式检测异步线程是否返回的过程，既可以不阻塞异步线程，也可以对线程的返回情况进行检测。在第一队列中所保留的交易ID即为没有得到信息反馈的交易请求对应的交易ID，没有得到信息反馈的原因很多，主要原因在于支付服务器的响应不及时或者线路阻塞，尤其是在支付高峰期，很多金融机构的支付服务器会发生这种无法及时响应的问题。第一队列的存在可以在对账时便于查询未反馈的交易结果。同时，本申请实施例还设置了第三队列，第三队列是存在于第一队列中时长超过第一预设值的交易ID的集合；第一预设值根据对账周期进行设置，这样进行对账时，可以从第三队列中取出第一交易ID，避免了对未结交易重新检索查询的问题。同时，从第一队列中选出第一交易ID时，应当把第一交易ID从第一队列中移除，避免第一队列和第三队列发生冲突。

示例的，网络支付平台的对账周期采用1小时、3小时、6小时时，将第一预设值设置为1小时、3小时、6小时。

具体的，当进行对账时，所述第二服务器将所述第三队列中的第一交易ID发送至所述第一服务器；所述第一服务器对账时根据所述第一交易ID修正对账结果。修正方式为，第一服务器将所述第三队列中的第一交易ID从对账结果中剔除。本申请实施例实施时，通过第二服务器对交易ID进行监控，并且直接检索出未完成交易的交易ID，有效降低了对账时服务器的计算压力，也避免了在海量数据中检索时产生的错误和误差。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当从所述第一队列检测到存在于所述第三队列的第一交易ID时，向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

本申请实施例实施时，现有技术中，如果出现了交易未被响应的情况，很容易出现信息重复发送，进一步的加剧支付服务器的信息堵塞和处理压力，并且交易容易被重复处理。而在本申请实施例中，从第一队列中选出第一交易ID时，应当把第一交易ID从第一队列中移除，此时如果第一队列中出现了存在于所述第三队列的第一交易ID，说明该第一交易ID发生了重复提交，重复提交的内容可能是付款、退款等内容，此时通过拦截指令暂停对应的第二交易请求的发送，可以有效降低对应支付服务器的信息堵塞，减少处理压力。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，将该第一交易ID作为第二交易ID；

向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

本申请实施例实施时，在医院当中，很多时候会出现用户需要及时支付医疗检查诊断治疗等相关费用，但是由于支付服务器无法及时响应，造成延误。目前对于这种情况主要的解决方案是，采用预付款制，即用户付款至统一支付平台，并在统一支付平台上进行交易，再由统一支付平台与支付服务器进行结算，但是这种方式一方面有很高的金融风险，另一方面在技术实现时，需要大量的结算端口与支付服务器对账，系统复杂性较高。而在本申请实施例中，根据所述第一历史数据对所述第二交易ID发出响应一般是指通过第一历史数据对第二交易ID的用户的历史情况进行判断后，根据判断结果由平台对用户的费用进行垫付，从而保证用户可以及时的进行医疗诊断或治疗。

在一种可能的实现方式中，所述第二服务器，还被配置为：

当根据所述第一历史数据对所述第二交易ID发出响应时，将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，向所述第一服务器发起垫付请求；

所述第一服务器，被配置为：

收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

本实施例实施时，对于第一历史数据的处理，本申请实施例提供了一种具体的处理方案，即通过训练模型的方式进行判断，而为了减少模型的运算量，发明人将模型的输出结果确定为两种：是和否，所以采用了成熟的SVM技术进行模型训练，最终生成的模型即为二元分类器模型，二元分类器模型的输入结果为第一历史数据，输出数据为是或者否。

示例的，第一历史数据为：本次支付间隔（十五日），支付金额（560元）；上次支付间隔（十四日），支付金额（400元）；将这两个数组输入到二元分类器模型，二元分类器模型输出数据为是，那么第二服务器向所述第一服务器发起垫付请求。

示例的，二元分类器生成时，通过对样本数据进行标注后训练模型获取，可以通过支持向量机进行训练，也可以通过神经网络模型进行训练，只需要实现的结果为二元分类器即可。样本数据的维度一般为支付金额、支付周期、支付金融机构的数量等中的至少一种。

在一种可能的实现方式中，所述第二服务器，还被配置为：

向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

本实施例实施时，垫付的交易同样可以通过第二服务器进行监控，监控方式和前述实施例的监控方式基本相同，即通过建立队列的方式进行，便于查找。

在上述基础上，请结合参阅图2，为本发明实施例所提供的一种医院统一支付管理平台控制方法的流程示意图，所述一种医院统一支付管理平台控制方法可以应用于图1中的一种医院统一支付管理平台，进一步地，所述一种医院统一支付管理平台控制方法方法具体可以包括以下步骤S21-步骤S23所描述的内容。

S1：第一服务器接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

S2：第一服务器接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

S3：第二服务器监听所述第一服务器的接收端口；

S4：第二服务器在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

S5：第二服务器在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

S6：第二服务器轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

S7：第二服务器从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

S8：当从所述第二队列检测到所述第一交易ID时，第二服务器从所述第三队列中移除所述第一交易ID。

在一种可能的实现方式中，还包括：

当第二服务器从所述第一队列检测到存在于所述第三队列的第一交易ID时，第二服务器向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

在一种可能的实现方式中，还包括：

当第二服务器查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，第二服务器将该第一交易ID作为第二交易ID；

第二服务器向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

在一种可能的实现方式中，根据所述第一历史数据对所述第二交易ID发出响应包括：

第二服务器将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，第二服务器向所述第一服务器发起垫付请求；

第一服务器收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

在一种可能的实现方式中，还包括：

第二服务器向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当第二服务器监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显然本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种医院统一支付管理平台，其特征在于，包括：

第一服务器，被配置为：

接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

第二服务器，被配置为：

监听所述第一服务器的接收端口；

在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

当从所述第二队列检测到所述第一交易ID时，从所述第三队列中移除所述第一交易ID。

2.根据权利要求1所述的一种医院统一支付管理平台，其特征在于，所述第二服务器，还被配置为：

当从所述第一队列检测到存在于所述第三队列的第一交易ID时，向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

3.根据权利要求1所述的一种医院统一支付管理平台，其特征在于，所述第二服务器，还被配置为：

当查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，将该第一交易ID作为第二交易ID；

向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

4.根据权利要求3所述的一种医院统一支付管理平台，其特征在于，所述第二服务器，还被配置为：

当根据所述第一历史数据对所述第二交易ID发出响应时，将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，向所述第一服务器发起垫付请求；

所述第一服务器，被配置为：

收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

5.根据权利要求4所述的一种医院统一支付管理平台，其特征在于，所述第二服务器，还被配置为：

向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

6.一种医院统一支付管理平台控制方法，其特征在于，所述一种医院统一支付管理平台包括第一服务器和第二服务器；

所述方法包括：

第一服务器接收医院终端发送的第一交易请求，并根据所述第一交易请求向对应的支付服务器发送第二交易请求；

第一服务器接收所述支付服务器根据所述第二交易请求生成的第二交易结果信息，并根据所述第二交易结果信息向所述医院终端发送第一交易结果信息；

第二服务器监听所述第一服务器的接收端口；

第二服务器在所述第一服务器接收到所述第一交易请求时获取所述第一交易请求的交易ID，并根据获取所述交易ID的时间建立第一队列；

第二服务器在所述第一服务器接收到所述第二交易结果信息时获取所述第二交易结果信息对应的交易ID，并根据获取所述交易ID的时间建立第二队列；

第二服务器轮询所述第二队列，并将同时存在于所述第一队列和第二队列的交易ID从所述第一队列中移除；

第二服务器从所述第一队列中选出第一交易ID建立第三队列；所述第一交易ID为在所述第一队列中存在时长超过第一预设值的交易ID；

当从所述第二队列检测到所述第一交易ID时，第二服务器从所述第三队列中移除所述第一交易ID。

7.根据权利要求6所述的一种医院统一支付管理平台控制方法，其特征在于还包括：

当第二服务器从所述第一队列检测到存在于所述第三队列的第一交易ID时，第二服务器向所述第一服务器发送对应所述第一交易ID的第一拦截指令；

所述第一服务器收到所述第一拦截指令时，暂停对应所述第一交易ID的第二交易请求的发送。

8.根据权利要求6所述的一种医院统一支付管理平台控制方法，其特征在于，还包括：

当第二服务器查询到所述第三队列中的任意第一交易ID存在的时长超过第二预设值时，判断所述第一交易ID对应的第一交易请求的类型；

如果所述第一交易ID对应的第一交易请求的类型为支付，第二服务器将该第一交易ID作为第二交易ID；

第二服务器向所述第一服务器发起对应所述第二交易ID的用户的历史交易记录的查询请求，并获取所述第一服务器响应于所述查询请求发送的历史交易记录作为第一历史数据；

根据所述第一历史数据对所述第二交易ID发出响应。

9.根据权利要求8所述的一种医院统一支付管理平台控制方法，其特征在于，根据所述第一历史数据对所述第二交易ID发出响应包括：

第二服务器将所述第一历史数据输入配置于所述第二服务器的二元分类模型，并接收所述二元分类模型输出的结果；所述二元分类模型输出的结果为是或者否；

如果所述二元分类模型输出的结果为是，第二服务器向所述第一服务器发起垫付请求；

第一服务器收到所述垫付请求时为对应所述第二交易ID的所述第一交易请求进行资金垫付。

10.根据权利要求9所述的一种医院统一支付管理平台控制方法，其特征在于，还包括：

第二服务器向所述第一服务器发起垫付请求时，将所述第二交易ID放入第四队列；

当第二服务器监听到对应所述第二交易ID的第二交易结果信息为完成时，将所述第四队列移出所述第四队列。

Images