CN110766390A - 一种保证金支付方法及系统 - Google Patents

Abstract

本发明公开了一种保证金支付方法及系统，保证金管理端获取所投项目信息和银行子账户，绑定所投项目信息与银行子账户的关联关系，银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；保证金管理端获取所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送缴款信息至交易平台端；本发明为每一个投标人生成一个随机的银行子帐号，使得银行端、保证金管理端以及交易平台端在开标前都无法清楚所有情况，因此，任意一个系统的相关人员均无法通过保证金来确认投标人数量，从而保证投标的公平性。

Description

一种保证金支付方法及系统

技术领域

本发明涉及招投标技术领域，特别涉及一种保证金支付方法及系统。

背景技术

招标投标是基本建设领域促进竞争的全面经济责任制形式。一般由若干施工单位参与工程投标，招标单位择优入选，谁的工期短、造价低、质量高以及信誉好，就把工程任务包给谁，由承建单位与发包单位签订合同，一包到底，按交钥匙的方式组织建设。

而在招投标的过程中，投标人需要按照招标文件的要求向招标人提供投标保证金，投标保证金实质是为了避免因投标人在投标有效期内随意撤回、撤销投标或中标后不能提交履约保证金和签署合同等行为而给招标人造成损失。投标保证金除现金外，可以是银行出具的银行保函、保兑支票、银行汇票或现金支票。

在现代的交易支付方式，通过银行转账来支付保证金的方式，是当下最常用的保证金支付方式，然而这种方式容易被人知晓投标人数，从而影响投标的公平性。

发明内容

本发明所要解决的技术问题是：提供一种保证金支付方法及系统，能防止相关人员通过保证金来确认投标人数量的问题。

为了解决上述技术问题，本发明采用的技术方案为：

一种保证金支付方法，包括步骤：

S1、保证金管理端获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、保证金管理端获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种保证金支付系统，包括保证金管理端，所述保证金管理端包括第一存储器、第一处理器及存储在第一存储器上并可在第一处理器上运行的第一计算机程序，所述第一处理器执行所述第一计算机程序时实现以下步骤：

S1、获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

本发明的有益效果在于：一种保证金支付方法及系统，由银行端生成与招标方的母账户对应且无规律的银行子帐号，在投标人对某一标进行保证金缴纳时，由保证金管理端向银行端获取一个随机的银行子账户，根据分配的银行子帐号进行线下转账；后续开标时，通过向银行端获取所有银行子账户的缴款信息，来判断指定企业是否缴纳了保证金；在此过程中，银行端不知道所投项目信息和银行子账号的对应关系、保证金管理端在开标前不知道银行子账号是否缴纳且交易平台端在开标前不清楚银行子账号也不清楚转账情况，因此，任意一个系统的相关人员均无法通过保证金来确认投标人数量，从而保证投标的公平性。

附图说明

图1为本发明实施例的一种保证金支付方法的流程示意图；

图2为本发明实施例的一种保证金支付方法的功能示意图；

图3为本发明实施例的一种保证金支付方法在申请银行子账号时的流程示意图；

图4为本发明实施例的一种保证金支付方法在获取到账明细时的流程示意图；

图5为本发明实施例的一种保证金支付方法在退款时的流程示意图；

图6为本发明实施例涉及的申请银行子账号的操作说明示意图；

图7为本发明实施例涉及的申请银行子账号的标段说明示意图；

图8为本发明实施例涉及的申请银行子账号的界面示意图；

图9为本发明实施例涉及的申请银行子账号完成后的界面示意图；

图10为本发明实施例的一种保证金支付系统的结构示意图。

标号说明：

1、一种保证金支付系统；2、保证金管理端；3、第一处理器；4、第一存储器；5、银行端；6、第二处理器；7、第二存储器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

请参照图1至图9，一种保证金支付方法，包括步骤：

S1、保证金管理端获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、保证金管理端获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

从上述描述可知，本发明的有益效果在于：由银行端生成与招标方的母账户对应且无规律的银行子帐号，在投标人对某一标进行保证金缴纳时，由保证金管理端向银行端获取一个随机的银行子账户，根据分配的银行子帐号进行线下转账；后续开标时，通过向银行端获取所有银行子账户的缴款信息，来判断指定企业是否缴纳了保证金；在此过程中，银行端不知道所投项目信息和银行子账号的对应关系、保证金管理端在开标前不知道银行子账号是否缴纳且交易平台端在开标前不清楚银行子账号也不清楚转账情况，因此，任意一个系统的相关人员均无法通过保证金来确认投标人数量，从而保证投标的公平性。

进一步地，所述步骤S1之前还包括步骤：

银行端初始化所有的银行子账号，将所有银行子账号进行升序排列，并按照1、2、3…N的顺序进行一一对应编号，得到所述银行子账号的初始编号，所述N为所有银行子账号的总数；

所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息，向银行端发送子账号申请信息；

银行端接收所述子账号申请信息，获取当前可用的银行子账号，将所有当前可用的银行子账号进行升序排列，并按照1、2、3…M的顺序重新进行一一对应编号，得到当前可用的银行子账号的当前编号；

银行端对所有当前可用的银行子账号的初始编号进行求和，得到初始编号总数S；

银行端获取当前时间戳T，计算得到子账号序号R＝(S+T)％M，获取当前编号为R的银行子账号，将所述银行子账号返回至保证金管理端；

保证金管理端接收并显示所述银行子账号。

从上述描述可知，实现了子帐号的随机性，防止通过子帐号的规律猜测投标人数。

进一步地，所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息和所属银行信息，向与所述所属银行信息对应的银行端发送子账号申请信息，所述子账号申请信息包括招标方的第一母账户，所述银行端为两个以上，所述招标方的母账户为两个以上；

银行端获取并返回与所述第一母账户对应的银行子账号至保证金管理端；

保证金管理端接收并显示所述银行子账号。

从上述描述可知，采用多银行多母帐号方式，实现了没有任何一家银行能获取到全面的投标保证金信息，从而避免通过金额来猜测投标人数。

进一步地，所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息，验证当前手机号在所述所投项目信息上是否存有银行子账号，若是，则获取并显示所存储的银行子账号，否则获取并显示银行端分配的银行子账号，并保存所述当前手机号与分配的所述银行子账号的匹配关系。

从上述描述可知，通过绑定手机号，使得每一个手机号在每一个项目上只能申请一个银行子账号，避免资源浪费。

进一步地，所述步骤S2之后还包括：

S3、保证金管理端获取待退款银行子账号，将所述待退款银行子账号的状态修改为待处理，获取待退款银行子账号的待处理退款明细，判断所述待退款银行子账号所对应的银行端所使用的银行接口类型，根据所述银行接口类型调用对应的银行退款接口向对应的银行端发出退款请求，实时接收对应的银行端返回的退款状态，在接收到退款成功之后将所述待退款银行子账号的状态修改为已退款。

从上述描述可知，使得保证金能够及时有效的退还给对应的账户上。

请参照图10，一种保证金支付系统，包括保证金管理端，所述保证金管理端包括第一存储器、第一处理器及存储在第一存储器上并可在第一处理器上运行的第一计算机程序，所述第一处理器执行所述第一计算机程序时实现以下步骤：

S1、获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

从上述描述可知，本发明的有益效果在于：由银行端生成与招标方的母账户对应且无规律的银行子帐号，在投标人对某一标进行保证金缴纳时，由保证金管理端向银行端获取一个随机的银行子账户，根据分配的银行子帐号进行线下转账；后续开标时，通过向银行端获取所有银行子账户的缴款信息，来判断指定企业是否缴纳了保证金；在此过程中，银行端不知道所投项目信息和银行子账号的对应关系、保证金管理端在开标前不知道银行子账号是否缴纳且交易平台端在开标前不清楚银行子账号也不清楚转账情况，因此，任意一个系统的相关人员均无法通过保证金来确认投标人数量，从而保证投标的公平性。

进一步地，还包括银行端，所述银行端包括第二存储器、第二处理器及存储在第二存储器上并可在第二处理器上运行的第二计算机程序，在所述步骤S1之前，所述第二处理器执行所述第二计算机程序时实现以下步骤：

初始化所有的银行子账号，将所有银行子账号进行升序排列，并按照1、2、3…N的顺序进行一一对应编号，得到所述银行子账号的初始编号，所述N为所有银行子账号的总数；

所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息，向银行端发送子账号申请信息；

保证金管理端接收并显示银行子账号；

在所述步骤S1的“获取所投项目信息和银行子账户”中，所述第二处理器执行所述第二计算机程序时实现以下步骤：

接收所述子账号申请信息，获取当前可用的银行子账号，将所有当前可用的银行子账号进行升序排列，并按照1、2、3…M的顺序重新进行一一对应编号，得到当前可用的银行子账号的当前编号；

对所有当前可用的银行子账号的初始编号进行求和，得到初始编号总数S；

获取当前时间戳T，计算得到子账号序号R＝(S+T)％M，获取当前编号为R的银行子账号，将所述银行子账号返回至保证金管理端；

从上述描述可知，实现了子帐号的随机性，防止通过子帐号的规律猜测投标人数。

进一步地，所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息和所属银行信息，向与所述所属银行信息对应的银行端发送子账号申请信息，所述子账号申请信息包括招标方的第一母账户，所述银行端为两个以上，所述招标方的母账户为两个以上；

接收并显示银行子账号；

在所述步骤S1的“获取所投项目信息和银行子账户”中，所述第二处理器执行所述第二计算机程序时实现以下步骤：

银行端获取并返回与所述第一母账户对应的银行子账号至保证金管理端。

从上述描述可知，采用多银行多母帐号方式，实现了没有任何一家银行能获取到全面的投标保证金信息，从而避免通过金额来猜测投标人数。

进一步地，所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息，验证当前手机号在所述所投项目信息上是否存有银行子账号，若是，则获取并显示所存储的银行子账号，否则获取并显示银行端分配的银行子账号，并保存所述当前手机号与分配的所述银行子账号的匹配关系。

从上述描述可知，通过绑定手机号，使得每一个手机号在每一个项目上只能申请一个银行子账号，避免资源浪费。

进一步地，所述步骤S2之后，所述第一处理器执行所述第一计算机程序时还实现以下步骤：

S3、获取待退款银行子账号，将所述待退款银行子账号的状态修改为待处理，获取待退款银行子账号的待处理退款明细，判断所述待退款银行子账号所对应的银行端所使用的银行接口类型，根据所述银行接口类型调用对应的银行退款接口向对应的银行端发出退款请求，实时接收对应的银行端返回的退款状态，在接收到退款成功之后将所述待退款银行子账号的状态修改为已退款。

从上述描述可知，使得保证金能够及时有效的退还给对应的账户上。

请参照图1至图9，本发明的实施例一为：

一种保证金支付方法，包括步骤：

银行端初始化所有的银行子账号，将所有银行子账号进行升序排列，并按照1、2、3…N的顺序进行一一对应编号，得到银行子账号的初始编号，N为所有银行子账号的总数，如本实施例中N为10000；

S1、保证金管理端获取所投项目信息和银行子账户，绑定所投项目信息与银行子账户的关联关系，银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

在本实施例中，步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

如图2所示，保证金管理端获取所投项目信息，验证当前手机号在所投项目信息上是否存有银行子账号，若是，则获取并显示所存储的银行子账号，否则向银行端发送子账号申请信息；

银行端接收子账号申请信息，获取当前可用的银行子账号，将所有当前可用的银行子账号进行升序排列，并按照1、2、3…M的顺序重新进行一一对应编号，得到当前可用的银行子账号的当前编号，例如已经分配了3个银行子账号，则当前剩下9997个银行子账号，即M为9997；

银行端对所有当前可用的银行子账号的初始编号进行求和，得到初始编号总数S，例如初始编号为4、688、2657三个银行子账号已被分配，则剩下的9997个银行子账号的初始编号总数S为5001651；

银行端获取精度到毫秒的当前时间戳T，计算得到子账号序号R＝(S+T)％M，获取当前编号为R的银行子账号，将银行子账号返回至保证金管理端，例如当前时间戳为1572451269000，则R＝1572456270651％9997＝9093，则当前编号为9093的银行子账号的初始编号为9096，采用此算法，可以实现了子帐号的随机性，以防止通过子帐号的规律猜测投标人数；

保证金管理端接收并显示银行子账号，保存当前手机号与分配的银行子账号的匹配关系；

投标人根据分配的银行子帐号进行线下转账，即为每一个投标人生成一个随机的银行帐号，以防止相关人员通过银行保证金转帐信息确认投标人数量的问题；

在开标之前，如图4所示，可以获取到账明细；

S2、保证金管理端获取所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送缴款信息至交易平台端；

此时，交易平台端可以得知缴纳保证金的情况，确认投标人是否可以参与投标，在完成投标之后，需要将保证金退还给未得标的投标人，则执行以下步骤：

S3、如图5所示，保证金管理端获取待退款银行子账号，将待退款银行子账号的状态修改为待处理，获取待退款银行子账号的待处理退款明细，判断待退款银行子账号所对应的银行端所使用的银行接口类型，根据银行接口类型调用对应的银行退款接口向对应的银行端发出退款请求，实时接收对应的银行端返回的退款状态，在接收到退款成功之后将待退款银行子账号的状态修改为已退款。

其中，关于投标人在保证金管理端上进行申请银行子账号可参考图6至图9。

请参照图1至图9，本发明的实施例二为：

一种保证金支付方法，在上述实施例一的基础上，步骤S1中“保证金管理端获取所投项目信息和银行子账户”替换为：

保证金管理端获取所投项目信息和所属银行信息，向与所属银行信息对应的银行端发送子账号申请信息，子账号申请信息包括招标方的第一母账户，银行端为两个以上，招标方的母账户为两个以上，即提供多家银行的多个母帐号，使得每一个标的款明细都分散在各银行帐号中；

银行端获取并返回与第一母账户对应的银行子账号至保证金管理端；

保证金管理端接收并显示银行子账号。

由于采用多银行多母帐号方式，实现了没有任何一家银行能获取到全面的投标保证金信息。

同时，步骤S1中的“保证金管理端获取所投项目信息和银行子账户”在实施例一和实施例二的技术方案上可以叠加使用，具体的，本实施例中银行端获取并返回与第一母账户对应的银行子账号至保证金管理端可以对应上述实施例一种银行端分配银行子账号的过程，即将实施例一和实施例二的技术方案进行结合的新实施例是本实施例或上述实施例一的等同实施例。

请参照图10，本发明的实施例三为：

一种保证金支付系统1，包括保证金管理端2和银行端5，保证金管理端2包括第一存储器4、第一处理器3及存储在第一存储器4上并可在第一处理器3上运行的第一计算机程序，银行端5包括第二存储器7、第二处理器6及存储在第二存储器7上并可在第二处理器6上运行的第二计算机程序，第一处理器3执行第一计算机程序时实现上述实施例一对应的步骤，第二处理器6执行第二计算机程序时实现上述实施例一对应的步骤。

在本实施例中，保证金管理端2还以交易平台端连接，其中，保证金管理端2、银行端5以及交易平台端上的系统由各自的公司团队开发，没有一个团队能获取到完整的投标人信息，实现保证金数据去中心化，招标人与代理人员均不参与保证金相关业务，实现泄漏面最小化，且对数据的访问也进行的相互跟踪监督。

请参照图10，本发明的实施例四为：

一种保证金支付系统1，在上述实施例三的基础上，第一处理器3执行第一计算机程序时实现上述实施例二对应的步骤，第二处理器6执行第二计算机程序时实现上述实施例二对应的步骤。

综上所述，本发明提供的一种保证金支付方法及系统，采用多银行多母帐号方式，由多个银行端分别生成与招标方的多个母账户对应且无规律的银行子帐号，实现了没有任何一家银行能获取到全面的投标保证金信息，从而避免通过金额来猜测投标人数；在投标人对某一标进行保证金缴纳时，由保证金管理端向银行端获取一个随机的银行子账户，银行端通过随机算法分配一个银行子帐号，实现了子帐号的随机性，防止通过子帐号的规律猜测投标人数；投标人根据分配的银行子帐号进行线下转账；后续开标时，通过向银行端获取所有银行子账户的缴款信息，来判断指定企业是否缴纳了保证金；即通过银行子账号、随机分配算法以及多银行多母帐号的方式，使得任意一个系统的相关人员均无法通过保证金来确认或猜测出投标人数量，从而保证投标的公平性。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种保证金支付方法，其特征在于，包括步骤：

S1、保证金管理端获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、保证金管理端获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

2.根据权利要求1所述的一种保证金支付方法，其特征在于，所述步骤S1之前还包括步骤：

银行端初始化所有的银行子账号，将所有银行子账号进行升序排列，并按照1、2、3…N的顺序进行一一对应编号，得到所述银行子账号的初始编号，所述N为所有银行子账号的总数；

所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息，向银行端发送子账号申请信息；

银行端接收所述子账号申请信息，获取当前可用的银行子账号，将所有当前可用的银行子账号进行升序排列，并按照1、2、3…M的顺序重新进行一一对应编号，得到当前可用的银行子账号的当前编号；

银行端对所有当前可用的银行子账号的初始编号进行求和，得到初始编号总数S；

银行端获取当前时间戳T，计算得到子账号序号R＝(S+T)％M，获取当前编号为R的银行子账号，将所述银行子账号返回至保证金管理端；

保证金管理端接收并显示所述银行子账号。

3.根据权利要求1所述的一种保证金支付方法，其特征在于，所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息和所属银行信息，向与所述所属银行信息对应的银行端发送子账号申请信息，所述子账号申请信息包括招标方的第一母账户，所述银行端为两个以上，所述招标方的母账户为两个以上；

银行端获取并返回与所述第一母账户对应的银行子账号至保证金管理端；

保证金管理端接收并显示所述银行子账号。

4.根据权利要求1所述的一种保证金支付方法，其特征在于，所述步骤S1中“保证金管理端获取所投项目信息和银行子账户”具体为：

保证金管理端获取所投项目信息，验证当前手机号在所述所投项目信息上是否存有银行子账号，若是，则获取并显示所存储的银行子账号，否则获取并显示银行端分配的银行子账号，并保存所述当前手机号与分配的所述银行子账号的匹配关系。

5.根据权利要求1所述的一种保证金支付方法，其特征在于，所述步骤S2之后还包括：

S3、保证金管理端获取待退款银行子账号，将所述待退款银行子账号的状态修改为待处理，获取待退款银行子账号的待处理退款明细，判断所述待退款银行子账号所对应的银行端所使用的银行接口类型，根据所述银行接口类型调用对应的银行退款接口向对应的银行端发出退款请求，实时接收对应的银行端返回的退款状态，在接收到退款成功之后将所述待退款银行子账号的状态修改为已退款。

6.一种保证金支付系统，包括保证金管理端，所述保证金管理端包括第一存储器、第一处理器及存储在第一存储器上并可在第一处理器上运行的第一计算机程序，其特征在于，所述第一处理器执行所述第一计算机程序时实现以下步骤：

S1、获取所投项目信息和银行子账户，绑定所述所投项目信息与所述银行子账户的关联关系，所述银行子帐号为银行端生成与招标方的母账户对应且无规律的子帐号；

S2、获取所述所投项目信息关联的所有银行子账户，向银行端获取所有银行子账户的缴款信息，得到并发送所述缴款信息至交易平台端。

7.根据权利要求6所述的一种保证金支付系统，其特征在于，还包括银行端，所述银行端包括第二存储器、第二处理器及存储在第二存储器上并可在第二处理器上运行的第二计算机程序，在所述步骤S1之前，所述第二处理器执行所述第二计算机程序时实现以下步骤：

初始化所有的银行子账号，将所有银行子账号进行升序排列，并按照1、2、3…N的顺序进行一一对应编号，得到所述银行子账号的初始编号，所述N为所有银行子账号的总数；

所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息，向银行端发送子账号申请信息；

保证金管理端接收并显示银行子账号；

在所述步骤S1的“获取所投项目信息和银行子账户”中，所述第二处理器执行所述第二计算机程序时实现以下步骤：

接收所述子账号申请信息，获取当前可用的银行子账号，将所有当前可用的银行子账号进行升序排列，并按照1、2、3…M的顺序重新进行一一对应编号，得到当前可用的银行子账号的当前编号；

对所有当前可用的银行子账号的初始编号进行求和，得到初始编号总数S；

获取当前时间戳T，计算得到子账号序号R＝(S+T)％M，获取当前编号为R的银行子账号，将所述银行子账号返回至保证金管理端。

8.根据权利要求7所述的一种保证金支付系统，其特征在于，所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息和所属银行信息，向与所述所属银行信息对应的银行端发送子账号申请信息，所述子账号申请信息包括招标方的第一母账户，所述银行端为两个以上，所述招标方的母账户为两个以上；

接收并显示银行子账号；

在所述步骤S1的“获取所投项目信息和银行子账户”中，所述第二处理器执行所述第二计算机程序时实现以下步骤：

银行端获取并返回与所述第一母账户对应的银行子账号至保证金管理端。

9.根据权利要求6所述的一种保证金支付系统，其特征在于，所述第一处理器执行所述第一计算机程序中所述步骤S1的“获取所投项目信息和银行子账户”时具体实现以下步骤：

获取所投项目信息，验证当前手机号在所述所投项目信息上是否存有银行子账号，若是，则获取并显示所存储的银行子账号，否则获取并显示银行端分配的银行子账号，并保存所述当前手机号与分配的所述银行子账号的匹配关系。

10.根据权利要求6所述的一种保证金支付系统，其特征在于，所述步骤S2之后，所述第一处理器执行所述第一计算机程序时还实现以下步骤：

S3、获取待退款银行子账号，将所述待退款银行子账号的状态修改为待处理，获取待退款银行子账号的待处理退款明细，判断所述待退款银行子账号所对应的银行端所使用的银行接口类型，根据所述银行接口类型调用对应的银行退款接口向对应的银行端发出退款请求，实时接收对应的银行端返回的退款状态，在接收到退款成功之后将所述待退款银行子账号的状态修改为已退款。

Images