CN115809874A - 交易处理方法、装置、系统及电子设备 - Google Patents
交易处理方法、装置、系统及电子设备 Download PDFInfo
- Publication number
- CN115809874A CN115809874A CN202211510708.2A CN202211510708A CN115809874A CN 115809874 A CN115809874 A CN 115809874A CN 202211510708 A CN202211510708 A CN 202211510708A CN 115809874 A CN115809874 A CN 115809874A
- Authority
- CN
- China
- Prior art keywords
- ciphertext
- bank
- bank account
- target
- account
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请公开了一种交易处理方法、装置、系统及电子设备,涉及信息安全领域。其中,该方法包括:从第一服务端中获取第三方支付程序生成的交易请求;从预设数据库中读取与第三方支付账户相关联的至少一个银行账户;根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;检测至少一个待确认密文中是否存在与目标密文相同的第一密文;在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。本申请解决了现有技术中跨银行交易时存在的信息安全性差的技术问题。
Description
技术领域
本申请涉及信息安全领域,具体而言,涉及一种交易处理方法、装置、系统及电子设备。
背景技术
随着移动互联网技术的飞速发展,二维码支付等线上支付方式被广泛应用,为人们的生活带来了极大方便。但是,现有技术在跨银行交易,尤其是使用第三方支付程序的付款码进行跨银行交易时,由于付款对象的银行账户在支付过程中是明文显示的状态,因此,收单银行可以直接获取付款对象的银行账户,从而导致用户的账户信息存在信息泄露的风险,容易被不法分子盗取。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种交易处理方法、装置、系统及电子设备,以至少解决现有技术中跨银行交易时存在的信息安全性差的技术问题。
根据本申请实施例的一个方面,提供了一种交易处理方法,包括:从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行;从预设数据库中读取与第三方支付账户相关联的至少一个银行账户;根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;检测至少一个待确认密文中是否存在与目标密文相同的第一密文;在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
进一步地,交易处理方法还包括:在从预设数据库中读取与第三方支付账户相关联的至少一个银行账户之前,接收账户绑定请求,其中,账户绑定请求用于绑定银行账户以及第三方支付账户;根据账户绑定请求生成目标索引表,其中,目标索引表用于记录银行账户以及第三方支付账户之间的绑定关系;将目标索引表存储至第二服务端的预设数据库中,其中,第二服务端为发卡银行的服务端,发卡银行为给付款对象提供目标银行账户的银行。
进一步地,交易处理方法还包括:在检测至少一个待确认密文中是否存在与目标密文相同的第一密文之后,在至少一个待确认密文中不存在第一密文时,生成第一提示信息,其中,第一提示信息用于表征第二服务端未成功识别到目标银行账户;将第一提示信息发送至第三方支付程序。
进一步地,交易处理方法还包括:检测目标银行账户中的资金余额;在资金余额大于或等于待付款金额时,在目标银行账户中扣除待付款金额;在资金余额小于待付款金额时,生成第二提示信息,并将第二提示信息发送至第三方支付程序,其中,第二提示信息用于表征待付款金额扣除失败。
进一步地,交易处理方法还包括:在确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额之后,生成扣款结果,其中,扣款结果至少包括待付款金额以及扣款时间;将扣款结果发送至第一服务端中。
进一步地,交易处理方法还包括:在将扣款结果发送至第一服务端中之后,接收第一服务端返回的回复结果,其中,回复结果表征收单银行已经记录扣款结果;将回复结果发送至第三方支付程序中。
根据本申请实施例的另一方面,还提供了一种交易处理系统,包括:第一终端设备,用于依据第三方支付程序生成交易请求,其中,交易请求中至少包括付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文;第一服务端,与第一终端设备连接,用于接收交易请求,并将交易请求转发至第二服务端中,其中,第一服务端为收单银行的服务端,第二服务端为发卡银行的服务端,收单银行为给收款对象提供银行账户的银行,发卡银行为给付款对象提供目标银行账户的银行;第二服务端,与第一服务端连接,用于获取与第三方支付账户相关联的至少一个银行账户,并根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;第二服务端还用于检测至少一个待确认密文中是否存在与目标密文相同的第一密文,并在至少一个待确认密文中存在第一密文时,将第一密文对应的银行账户确定为目标银行账户,进而在目标银行账户中扣除待付款金额。
根据本申请实施例的另一方面,还提供了一种交易处理装置,包括:获取模块,用于从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行;读取模块,用于从预设数据库中读取与第三方支付账户相关联的至少一个银行账户;加密模块,用于根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;检测模块,用于检测至少一个待确认密文中是否存在与目标密文相同的第一密文;确定模块,用于在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
根据本申请实施例的另一方面,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,其中,计算机程序被设置为运行时执行上述的交易处理方法。
根据本申请实施例的另一方面,还提供了一种电子设备,包括一个或多个处理器和存储器,存储器用于存储一个或多个程序,其中,当一个或多个程序被一个或多个处理器执行时,使得一个或多个处理器实现上述的交易处理方法。
在本申请中,采用对付款对象的银行账户进行加密的方式,首先从第一服务端中获取第三方支付程序生成的交易请求,其中,所述交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,所述目标密文为所述第三方支付程序通过加密算法对所述付款对象的目标银行账户进行加密后得到的密文,所述第一服务端为收单银行的服务端,所述收单银行为给收款对象提供银行账户的银行,然后从预设数据库中读取与所述第三方支付账户相关联的至少一个银行账户,并根据所述加密算法对所述至少一个银行账户进行加密,得到至少一个待确认密文,最后检测所述至少一个待确认密文中是否存在与所述目标密文相同的第一密文,并在所述至少一个待确认密文中存在所述第一密文时,确定所述第一密文对应的银行账户为所述目标银行账户,并从所述目标银行账户中扣除所述待付款金额。其中,每个待确认密文与一个银行账户相对应。
由上述内容可知,本申请通过对付款对象的银行账户进行加密,确保了第一服务端(即收单银行的服务端)在转发交易请求时无法识别到付款对象的银行账户,从而提高了用户银行账户的安全性。并且,本申请通过对与第三方支付账户相关联的银行账户同样进行加密,从而根据生成的待确认密文,与目标密文进行比对,进而确保了发卡银行的服务端(即第二服务端)能够准确识别用于付款的目标银行账户,保证了交易的顺利完成。
由此可见,通过本申请的技术方案,达到了避免泄露付款对象的银行账户信息的目的,从而实现了提高跨银行交易过程中的信息安全性的效果,进而解决了现有技术中跨银行交易时存在的信息安全性差的技术问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例的一种可选的交易处理方法的流程图;
图2是根据现有技术的交易处理方法的流程图;
图3是根据本申请实施例中一种可选的交易处理方法流程图;
图4是根据本申请实施例的一种可选的交易处理系统的示意图;
图5是根据本申请实施例的一种可选的交易处理装置的示意图;
图6是根据本申请实施例的一种可选的电子设备示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
另外,还需要说明的是,本公开所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等),均为经用户授权或者经过各方充分授权的信息和数据。例如,本系统和相关用户或机构间设置有接口,在获取相关信息之前,需要通过接口向前述的用户或机构发送获取请求,并在接收到前述的用户或机构反馈的同意信息后,获取相关信息。
实施例1
根据本申请实施例,提供了一种交易处理方法的实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
另外,为了方便对本申请实施例中的方案进行描述,以下对本申请中所涉及到的名词进行简要说明:
聚合支付二维码:起初各支付机构之间的二维码互相不兼容,导致商户需要安装各金融机构的二维码识别设备,例如POS(point of sale,销售终端)机,造成了大量设备重复投入。为解决该问题,各金融机构联合推出聚合支付二维码,统一了二维码格式,相互之间可以解析,例如甲银行解析出支付二维码是A机构的,就通过银联等清算组织将交易数据转发给A机构的第三方支付程序。
图1是根据本申请实施例的一种可选的交易处理方法的流程图,如图1所示,该方法包括如下步骤:
步骤S101,从第一服务端中获取第三方支付程序生成的交易请求。
在步骤S101中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行。
具体的,上述的交易请求可以是一种用于移动支付的聚合支付二维码,例如,付款码、收款码。上述的第三方支付程序为一种具有支付功能的应用程序,举例而言,用户A使用第三方支付程序1生成了一个付款码,该付款码中所包含的信息至少包括用户A的第三方支付账户、待付款金额以及目标密文,其中,目标密文为针对用户A的一个银行账户进行加密后的密文,该银行账户为用户A用于支付待付款金额的银行账户。用户A将付款码展示给商户B的POS机上,然后POS机将付款码发送至第一服务端中,其中,第一服务端为收单银行的服务端,收单银行可以理解为是为商户B提供POS机的银行,也是为商户B提供银行账户的银行。
需要注意到的是,第一服务端在接收到交易请求之后,一方面会记录交易请求,一方面还会将交易请求转发至第二服务端中,其中,第二服务端为发卡银行的服务端,发卡银行可以理解为是为用户A提供目标银行账户(即支付待付款金额的银行账户)的银行。发卡银行与收单银行可以是不同的银行,例如,发卡银行为bank1,收单银行为bank2。
步骤S102,从预设数据库中读取与第三方支付账户相关联的至少一个银行账户。
在步骤S102中,假设用户A的第三方支付账户为账户V,第二服务端对应的银行为bank1,在第二服务端的预设数据库中保留有用户A在bank1银行下开通的所有银行账户,并且第二服务端的预设数据库中还记录有这些银行账户中有哪些银行账户与账户V进行了绑定。
步骤S103,根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文。
在步骤S103中,每个待确认密文与一个银行账户相对应。假设用户A的账户V与用户A在bank1银行下开通的三个银行账户进行了绑定,分别为银行账户1、银行账户2以及银行账户3。如果第三方支付程序使用的是哈希加密算法对用户A的目标银行账户进行的加密,则第二服务端也采用哈希加密算法对银行账户1、银行账户2以及银行账户3分别进行加密,从而得到三个待确认密文。
需要注意到的是,本申请中的加密算法包括并不限于上述的哈希加密算法。
步骤S104,检测至少一个待确认密文中是否存在与目标密文相同的第一密文。
容易注意到的是,由于第三方支付程序与第二服务端所采用的加密算法相同,因此,针对同一个银行账户进行加密后所得到的密文也相同。基于此原理,如果第三方支付程序是对用户A的银行账户1进行的加密,则其所得到的目标密文与第二服务端对银行账户1进行加密后的待确认密文是相同的,换言之,第二服务端可以确定银行账户1对应的待确认密文为第一密文。
步骤S105,在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
需要注意到的是,交易的最终目的是确定从用户的哪一个银行账户中扣除对应的待付款金额,因此,在确认得到第一密文之后,第二服务端可确定第一密文对应的银行账户是用于支付待付款金额的目标银行账户。在此基础上,第二服务端只需要从目标银行账户中扣除待付款金额,既可以实现该笔交易。
基于上述步骤S101至步骤S105的内容可知,在本申请中,采用对付款对象的银行账户进行加密的方式,首先从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行,然后从预设数据库中读取与第三方支付账户相关联的至少一个银行账户,并根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,最后检测至少一个待确认密文中是否存在与目标密文相同的第一密文,并在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。其中,每个待确认密文与一个银行账户相对应。
由上述内容可知,本申请通过对付款对象的银行账户进行加密,确保了第一服务端(即收单银行的服务端)在转发交易请求时无法识别到付款对象的银行账户,从而提高了用户银行账户的安全性。并且,本申请通过对与第三方支付账户相关联的银行账户同样进行加密,从而根据生成的待确认密文,与目标密文进行比对,进而确保了发卡银行的服务端(即第二服务端)能够准确识别用于付款的目标银行账户,保证了交易的顺利完成。
由此可见,通过本申请的技术方案,达到了避免付款对象的银行账户泄露的目的,从而实现了提高跨银行交易过程中的信息安全性的效果,进而解决了现有技术中跨银行交易时存在的信息安全性差的技术问题。
另外,通过本申请实施例的交易处理方法,不仅可以提高跨银行交易过程中的信息安全性,还可以提高交易数据的处理效率。其中,图2示出了根据现有技术中的交易处理方法的流程图,如图2所示,假设商户B是甲银行(编号:H001)的商户,在甲银行收单账号为A001。持卡人A是乙银行(编号:H002)的客户,其将在乙银行的银行账户B001与第三方支付账户号WX001进行了绑定。
在上述背景下,如果持卡人A用第三方支付账户WX001支付在商户B消费的费用时,支付过程的数据交换处理流程为:商户B的POS机收单识别第三方支付程序生成的聚合支付二维码,该聚合支付二维码包括待付款金额、明文状态下的银行账户B001以及第三方支付账户号WX001。然后,商户B的POS机将聚合支付二维码提交到甲银行(该笔交易的收单银行)的服务端中,甲银行的服务端会对聚合支付二维码进行解析,得到交易数据,然后将交易数据转到银联(清算机构)。
银联在接收到交易数据之后,首先将交易数据加工为交易数据1,然后再将交易数据1转发给第三方支付程序对应的第三方服务端中,其中,在交易数据1中,收单机构为甲银行,发卡机构为第三方支付程序对应的机构,支付账户为第三方支付账户WX001。第三方服务端在接收到交易数据1之后,在对交易数据1进行解析之后,重新生成交易数据2,然后通过银联将交易数据2发送给乙银行(该笔交易的发卡银行)的服务端中,其中,在交易数据2中,收单机构为第三方支付程序对应的机构,发卡机构为乙银行,支付账户为持卡人A的银行账户B001。
最后,乙银行从银行账户B001中进行支付扣款,然后将支付结果通过银联反馈至第三方支付程序对应的机构,第三方支付程序对应的机构在通过银联反馈至甲银行,在甲银行对商户B的收款账户进行入账处理之后,通知商户收款成功。
由上述内容可知,现有技术虽然已经实现了各机构对二维码格式的统一、相互解析的效果,但仍存在交易链路过长的问题。目前的数据交换处理流程非常冗长,支付过程和清算过程都需要经过四个阶段的数据交换处理过程(含发送请求数据和反馈结果数据的双向流程),可见数据交换处理效率很低而且增加了数据传输失败的风险,影响支付过程的正常处理。
而在本申请的交易处理过程中,交易请求直接由第一服务端转发至第二服务端进行处理,即只需要从收单银行直接到发卡银行完成支付处理的数据交换即可,避免了在中间过程中需要经过第三方支付程序对应的机构的问题,从而提高了数据传输效率、降低了数据传输失败风险,并且后续的资金清算流程也与第三方支付机构完全无关,直接在收单银行和发卡银行之间即可完成。
在一种可选的实施例中,在从预设数据库中读取与第三方支付账户相关联的至少一个银行账户之前,第二服务端会接收账户绑定请求,然后根据账户绑定请求生成目标索引表,其中,目标索引表用于记录银行账户以及第三方支付账户之间的绑定关系。最后,第二服务端将目标索引表存储至第二服务端的预设数据库中,其中,第二服务端为发卡银行的服务端,发卡银行为给付款对象提供目标银行账户的银行,账户绑定请求用于绑定银行账户以及第三方支付账户。
可选的,第二服务端为付款对象提供目标银行账户的银行的服务端。其中,容易理解的是,一个用户在一家银行所开通的银行账户可以是多个,并且,一个用户不一定会将所有的银行账户都与某一个第三方支付账户进行绑定。为了准确掌握与第三方支付账户进行了绑定的银行账户,第二的服务端可以在接收到账户绑定请求之后,将建立绑定关系的银行账户与第三方支付账户存储于目标索引表中。
在一种可选的实施例中,在检测至少一个待确认密文中是否存在与目标密文相同的第一密文之后,如果在至少一个待确认密文中不存在第一密文,则第二服务端将生成第一提示信息,其中,第一提示信息用于表征第二服务端未成功识别到目标银行账户,然后第二服务端还会将第一提示信息发送至第三方支付程序。
可选的,如果第二服务端在至少一个待确认密文中未识别到与目标密文相同的第一密文时,则说明出现了异常情况,产生异常情况的原因可能有两种,一种是第三方支付程序生成目标密文时出现了错误,另一种是第二服务端在生成待确认密文时出现了错误。但是,无论是哪一种原因,异常情况的发生都会导致交易失败,因此,第二服务端会第一时间生成第一提示信息,并将第一提示信息发送至第三方支付程序中。
另外,为了排查上述两种产生异常情况的原因,第三方支付程序在接收到第一提示信息之后,可以重新通过加密算法对目标付款账户进行加密,得到新的目标密文以及包含新的目标密文的第一交易请求,随后第二服务端通过第一服务端获取得到第一交易请求,并将新的目标密文与至少一个待确认密文进行比较,如果存在与新的目标密文相同的待确认密文,则将该待确认密文确定为第一密文。
进一步地,如果至少一个待确认密文中仍然不存在与新的目标密文相同的密文,则第二服务端将重新根据加密算法对至少一个银行账户进行加密,得到至少一个第一待确认密文,然后第二服务端检测至少一个第一待确认密文中是否存在与新的目标密文相同的第一密文;在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
可选的,第二服务端还可以先检测每个待确认密文与新的目标密文之间相似度,并根据相似度对至少一个待确认密文进行排序,根据排序结果先针对相似度高的待确认密文对应的银行账户进行重新加密,得到该银行账户的第一待确认密文,如果该第一待确认密文与目标密文相同,则直接确定该第一待确认密文为第一密文。如果该第一待确认密文与目标密文不同,则继续根据排序结果对下一个银行账户进行重新加密。
在一种可选的实施例中,第二服务端还会检测目标银行账户中的资金余额;在资金余额大于或等于待付款金额时,第二服务端从目标银行账户中扣除待付款金额;在资金余额小于待付款金额时,第二服务端生成第二提示信息,并将第二提示信息发送至第三方支付程序,其中,第二提示信息用于表征待付款金额扣除失败。
可选的,通过检测目标银行账户中的资金余额,可以确定目标银行账户是否有足够的资金用于支付待付款金额,如果没有,需要及时通知走第三方支付程序,以避免商户遭受资金损失。
在一种可选的实施例中,在确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额之后,第二服务端生成扣款结果,其中,扣款结果至少包括待付款金额以及扣款时间,然后第二服务端将扣款结果发送至第一服务端中。
可选的,在第二服务端扣款成功之后,第二服务端会将扣款结果发送至第一服务端中,然后由第一服务端根据扣款结果对商户的账户进行入账处理,实现整个交易的闭环。
在一种可选的实施例中,在将扣款结果发送至第一服务端中之后,第二服务端还会接收第一服务端返回的回复结果,其中,回复结果表征收单银行已经记录扣款结果。然后,第二服务端会将回复结果发送至第三方支付程序中。
可选的,在第一服务端记录扣款结果并且对商户的账户进行了入账处理之后,第一服务端会生成回复结果,并将回复结果返回至第二服务端中,第二服务端在接收到回复结果之后,可以确定该笔交易已经完成,因此,第二服务端可以将回复结果发送至第三方支付程序中,以便付款对象也可以及时了解该笔交易已经完成。
在一种可选的实施例中,图3示出了根据本申请实施例中一种可选的交易处理方法流程图。如图3所示,该方法包括如下步骤:
步骤S301,第三方支付程序生成聚合支付二维码的时候,将付款对象的目标银行账户用哈希加密算法进行加密,生成账号加密摘要(对应目标密文)代替原来的目标银行账户放到聚合支付二维码中。其中,由于哈希加密算法不可逆,因此收单银行无法解析出原来的目标银行账户。
步骤S302,商户的POS机扫描聚合支付二维码;
步骤S303,POS机将聚合支付二维码发送至收单银行的第一服务端中;
步骤S304,第一服务端对聚合支付二维码进行解析,得到交易请求,并通过银联将交易请求转发至发卡银行的第二服务端;
步骤S305,第二服务端将与第三方支付账户绑定的至少一个银行账户均用哈希加密算法进行加密,得到至少一个待确认密文;
步骤S306,第二服务端将目标密文与每个待确认密文进行比对,得到与目标密文相同的第一密文,并确定第一密文对应的银行账户为目标银行账户;
步骤S307,第二服务端从目标银行账户中扣除待付款金额;
步骤S308,第二服务端通过银联将扣款结果反馈给收单银行;
步骤S309,第一服务端在接收到扣款结果之后,对商户的账户进行入账处理,并且通知商户入账成功,同时通过银联向第二服务端返回回复结果。
由上述内容可知,本申请解决了聚合支付和清算过程中数据交换过程长、效率低的问题,通过直通方式实现了从收单银行直接到发卡银行的数据交换处理过程,在支付和清算过程中避免经过第三方支付机构,大大提高了移动支付过程数据处理效率,降低数据传输失败的风险。同时,应用哈希加密等技术来增强聚合支付交易过程中数据信息安全、保护客户隐私,防止持卡人卡号等客户信息向收单银行、大量商户泄漏,从而实现了提升信息传输安全的效果。
实施例2
本申请实施例还提供了一种交易处理系统,需要说明的是,本申请实施例的交易处理系统可以用于执行本申请实施例1所提供的交易处理方法。以下对本申请实施例提供的交易处理系统进行介绍。
图4是根据本申请实施例的交易处理系统的示意图。如图4所示,该系统包括:第一终端设备,用于依据第三方支付程序生成交易请求,其中,交易请求中至少包括付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文;
第一服务端,与第一终端设备连接,用于接收交易请求,并将交易请求转发至第二服务端中,其中,第一服务端为收单银行的服务端,第二服务端为发卡银行的服务端,收单银行为给收款对象提供银行账户的银行,发卡银行为给付款对象提供目标银行账户的银行;
第二服务端,与第一服务端连接,用于获取与第三方支付账户相关联的至少一个银行账户,并根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;第二服务端还用于检测至少一个待确认密文中是否存在与目标密文相同的第一密文,并在至少一个待确认密文中存在第一密文时,将第一密文对应的银行账户确定为目标银行账户,进而在目标银行账户中扣除待付款金额。
可选的,上述的第一终端设备可以是智能手机、智能平板、智能可佩戴设备以及笔记本电脑等可运行第三方支付程序的终端设备。另外,可选的,交易处理系统还可以包括第二终端设备,用于与第一终端设备以及第一服务端连接。具体的,第二终端设备可以是商户使用的POS机等用于扫描付款码或者收款码的设备。
在一种可选的实施例中,具体的,上述的交易请求可以是一种用于移动支付的聚合支付二维码,例如,付款码、收款码。上述的第三方支付程序为一种具有支付功能的应用程序,举例而言,用户A使用第三方支付程序1生成了一个付款码,该付款码中所包含的信息至少包括用户A的第三方支付账户、待付款金额以及目标密文,其中,目标密文为针对用户A的一个银行账户进行加密后的密文,该银行账户为用户A支付待付款金额的银行账户。用户A将付款码展示给商户B的POS机上,然后POS会将付款码发送至第一服务端中,其中,第一服务端为收单银行的服务端,收单银行可以理解为是为商户B提供POS机的银行,也是为商户B提供银行账户的银行。
需要注意到的是,第一服务端在接收到交易请求之后,一方面会记录交易请求,一方面还会将交易请求转发至第二服务端中,其中,第二服务端为发卡银行的服务端,发卡银行可以理解为是为用户A提供目标银行账户(即支付待付款金额的银行账户)的银行。发卡银行与收单银行可以是不同的银行,例如,发卡银行为bank1,收单银行为bank2。
可选的,假设用户A的第三方支付账户为账户V,第二服务端对应的银行为bank1,在第二服务端的预设数据库中保留有用户A在bank1银行下开通的所有银行账户,并且第二服务端的预设数据库中还记录有这些银行账户中有哪些银行账户与账户V进行了绑定。
举例而言,如果用户A的账户V与用户A在bank1银行下开通的三个银行账户进行了绑定,分别为银行账户1、银行账户2以及银行账户3。如果第三方支付程序使用的是哈希加密算法对用户A的目标银行账户进行的加密,则第二服务端也采用哈希加密算法对银行账户1、银行账户2以及银行账户3分别进行加密,从而得到三个待确认密文。需要注意到的是,本申请中的加密算法包括并不限于上述的哈希加密算法。
另外,还需要注意到的是,由于第三方支付程序与第二服务端所采用的加密算法相同,因此,针对同一个银行账户进行加密后所得到的密文也相同。基于此原理,如果第三方支付程序是对用户A的银行账户1进行的加密,则其所得到的目标密文与第二服务端对银行账户1进行加密后的待确认密文是相同,换言之,第二服务端可以确定银行账户1对应的待确认密文为第一密文。在确认得到第一密文之后,第二服务端可确定第一密文对应的银行账户为用于支付待付款金额的目标银行账户。在此基础上,第二服务端只需要从目标银行账户中扣除待付款金额,既可以实现该笔交易。
基于上述的内容可知,在本申请中,采用对付款对象的银行账户进行加密的方式,首先从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行,然后从预设数据库中读取与第三方支付账户相关联的至少一个银行账户,并根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,最后检测至少一个待确认密文中是否存在与目标密文相同的第一密文,并在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。其中,每个待确认密文与一个银行账户相对应。
由上述内容可知,本申请通过对付款对象的银行账户进行加密,确保了第一服务端(即收单银行的服务端)在转发交易请求时无法识别到付款对象的银行账户,从而提高了用户银行账户的安全性。并且,本申请通过对与第三方支付账户相关联的银行账户同样进行加密,从而根据生成的待确认密文,与目标密文进行比对,进而确保了发卡银行的服务端(即第二服务端)能够准确识别用于付款的目标银行账户,保证了交易的顺利完成。
由此可见,通过本申请的技术方案,达到了避免付款对象的银行账户泄露的目的,从而实现了提高跨银行交易过程中的信息安全性的效果,进而解决了现有技术中跨银行交易时存在的信息安全性差的技术问题。
实施例3
本申请实施例还提供了一种交易处理装置,需要说明的是,本申请实施例的交易处理装置可以用于执行本申请实施例1所提供的交易处理方法。以下对本申请实施例提供的交易处理装置进行介绍。
图5是根据本申请实施例的交易处理装置的示意图。如图5所示,该装置包括:获取模块501,用于从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行;读取模块502,用于从预设数据库中读取与第三方支付账户相关联的至少一个银行账户;加密模块503,用于根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;检测模块504,用于检测至少一个待确认密文中是否存在与目标密文相同的第一密文;确定模块505,用于在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
可选的,交易处理装置还包括:接收模块、生成模块以及存储模块。其中,接收模块,用于接收账户绑定请求,其中,账户绑定请求用于绑定银行账户以及第三方支付账户;生成模块,用于根据账户绑定请求生成目标索引表,其中,目标索引表用于记录银行账户以及第三方支付账户之间的绑定关系;存储模块,用于将目标索引表存储至第二服务端的预设数据库中,其中,第二服务端为发卡银行的服务端,发卡银行为给付款对象提供目标银行账户的银行。
可选的,交易处理装置还包括:第一生成模块以及发送模块。其中,第一生成模块,用于在至少一个待确认密文中不存在第一密文时,生成第一提示信息,其中,第一提示信息用于表征第二服务端未成功识别到目标银行账户;发送模块,用于将第一提示信息发送至第三方支付程序。
可选的,确定模块还包括:检测单元、扣除单元以及第一生成单元。其中,检测单元,用于检测目标银行账户中的资金余额;扣除单元,用于在资金余额大于或等于待付款金额时,从目标银行账户中扣除待付款金额;第一生成单元,用于在资金余额小于待付款金额时,生成第二提示信息,并将第二提示信息发送至第三方支付程序,其中,第二提示信息用于表征待付款金额扣除失败。
可选的,交易处理装置还包括:第二生成模块以及第一发送模块。其中,第二生成模块,用于生成扣款结果,其中,扣款结果至少包括待付款金额以及扣款时间;第一发明模块,用于将扣款结果发送至第一服务端中。
可选的,交易处理装置还包括:第一接收模块意思第二发送模块。其中,第一接收模块,用于接收第一服务端返回的回复结果,其中,回复结果表征收单银行已经记录扣款结果;第二发送模块,用于将回复结果发送至第三方支付程序中。
实施例4
根据本申请实施例的另一方面,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,其中,计算机程序被设置为运行时执行上述实施例1中的交易处理方法。
实施例5
根据本申请实施例的另一方面,还提供了一种电子设备,该电子设备包括一个或多个处理器和存储器,存储器用于存储一个或多个程序,其中,当一个或多个程序被一个或多个处理器执行时,使得一个或多个处理器实现上述实施例1中的交易处理方法。
如图6所示,本申请实施例提供了一种电子设备,设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序,处理器执行程序时实现以下步骤:
从第一服务端中获取第三方支付程序生成的交易请求,其中,交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,目标密文为第三方支付程序通过加密算法对付款对象的目标银行账户进行加密后得到的密文,第一服务端为收单银行的服务端,收单银行为给收款对象提供银行账户的银行;从预设数据库中读取与第三方支付账户相关联的至少一个银行账户;根据加密算法对至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;检测至少一个待确认密文中是否存在与目标密文相同的第一密文;在至少一个待确认密文中存在第一密文时,确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额。
可选的,处理器执行程序时还实现以下步骤:在从预设数据库中读取与第三方支付账户相关联的至少一个银行账户之前,接收账户绑定请求,其中,账户绑定请求用于绑定银行账户以及第三方支付账户;根据账户绑定请求生成目标索引表,其中,目标索引表用于记录银行账户以及第三方支付账户之间的绑定关系;将目标索引表存储至第二服务端的预设数据库中,其中,第二服务端为发卡银行的服务端,发卡银行为给付款对象提供目标银行账户的银行。
可选的,处理器执行程序时还实现以下步骤:在检测至少一个待确认密文中是否存在与目标密文相同的第一密文之后,在至少一个待确认密文中不存在第一密文时,生成第一提示信息,其中,第一提示信息用于表征第二服务端未成功识别到目标银行账户;将第一提示信息发送至第三方支付程序。
可选的,处理器执行程序时还实现以下步骤:检测目标银行账户中的资金余额;在资金余额大于或等于待付款金额时,在目标银行账户中扣除待付款金额;在资金余额小于待付款金额时,生成第二提示信息,并将第二提示信息发送至第三方支付程序,其中,第二提示信息用于表征待付款金额扣除失败。
可选的,处理器执行程序时还实现以下步骤:在确定第一密文对应的银行账户为目标银行账户,并从目标银行账户中扣除待付款金额之后,生成扣款结果,其中,扣款结果至少包括待付款金额以及扣款时间;将扣款结果发送至第一服务端中。
可选的,处理器执行程序时还实现以下步骤:在将扣款结果发送至第一服务端中之后,接收第一服务端返回的回复结果,其中,回复结果表征收单银行已经记录扣款结果;将回复结果发送至第三方支付程序中。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如单元的划分,可以为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (10)
1.一种交易处理方法,其特征在于,包括:
从第一服务端中获取第三方支付程序生成的交易请求,其中,所述交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,所述目标密文为所述第三方支付程序通过加密算法对所述付款对象的目标银行账户进行加密后得到的密文,所述第一服务端为收单银行的服务端,所述收单银行为给收款对象提供银行账户的银行;
从预设数据库中读取与所述第三方支付账户相关联的至少一个银行账户;
根据所述加密算法对所述至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;
检测所述至少一个待确认密文中是否存在与所述目标密文相同的第一密文;
在所述至少一个待确认密文中存在所述第一密文时,确定所述第一密文对应的银行账户为所述目标银行账户,并从所述目标银行账户中扣除所述待付款金额。
2.根据权利要求1所述的方法,其特征在于,在从预设数据库中读取与所述第三方支付账户相关联的至少一个银行账户之前,所述方法还包括:
接收账户绑定请求,其中,所述账户绑定请求用于绑定所述银行账户以及所述第三方支付账户;
根据所述账户绑定请求生成目标索引表,其中,所述目标索引表用于记录所述银行账户以及所述第三方支付账户之间的绑定关系;
将所述目标索引表存储至第二服务端的预设数据库中,其中,所述第二服务端为发卡银行的服务端,所述发卡银行为给所述付款对象提供所述目标银行账户的银行。
3.根据权利要求2所述的方法,其特征在于,在检测所述至少一个待确认密文中是否存在与所述目标密文相同的第一密文之后,所述方法还包括:
在所述至少一个待确认密文中不存在所述第一密文时,生成第一提示信息,其中,所述第一提示信息用于表征所述第二服务端未成功识别到所述目标银行账户;
将所述第一提示信息发送至所述第三方支付程序。
4.根据权利要求1所述的方法,其特征在于,确定所述第一密文对应的银行账户为所述目标银行账户,并从所述目标银行账户中扣除所述待付款金额,包括:
检测所述目标银行账户中的资金余额;
在所述资金余额大于或等于所述待付款金额时,从所述目标银行账户中扣除所述待付款金额;
在所述资金余额小于所述待付款金额时,生成第二提示信息,并将所述第二提示信息发送至所述第三方支付程序,其中,所述第二提示信息用于表征所述待付款金额扣除失败。
5.根据权利要求4所述的方法,其特征在于,在确定所述第一密文对应的银行账户为所述目标银行账户,并从所述目标银行账户中扣除所述待付款金额之后,所述方法还包括:
生成扣款结果,其中,所述扣款结果至少包括所述待付款金额以及扣款时间;
将所述扣款结果发送至所述第一服务端中。
6.根据权利要求5所述的方法,其特征在于,在将所述扣款结果发送至所述第一服务端中之后,所述方法还包括:
接收所述第一服务端返回的回复结果,其中,所述回复结果表征所述收单银行已经记录所述扣款结果;
将所述回复结果发送至所述第三方支付程序中。
7.一种交易处理系统,其特征在于,包括:
第一终端设备,用于依据第三方支付程序生成交易请求,其中,所述交易请求中至少包括付款对象的第三方支付账户、待付款金额以及目标密文,所述目标密文为所述第三方支付程序通过加密算法对所述付款对象的目标银行账户进行加密后得到的密文;
第一服务端,与所述第一终端设备连接,用于接收所述交易请求,并将所述交易请求转发至第二服务端中,其中,所述第一服务端为收单银行的服务端,第二服务端为发卡银行的服务端,所述收单银行为给收款对象提供银行账户的银行,所述发卡银行为给所述付款对象提供所述目标银行账户的银行;
所述第二服务端,与所述第一服务端连接,用于获取与所述第三方支付账户相关联的至少一个银行账户,并根据所述加密算法对所述至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;所述第二服务端还用于检测所述至少一个待确认密文中是否存在与所述目标密文相同的第一密文,并在所述至少一个待确认密文中存在所述第一密文时,将所述第一密文对应的银行账户确定为所述目标银行账户,进而在所述目标银行账户中扣除所述待付款金额。
8.一种交易处理装置,其特征在于,包括:
获取模块,用于从第一服务端中获取第三方支付程序生成的交易请求,其中,所述交易请求中至少包含付款对象的第三方支付账户、待付款金额以及目标密文,所述目标密文为所述第三方支付程序通过加密算法对所述付款对象的目标银行账户进行加密后得到的密文,所述第一服务端为收单银行的服务端,所述收单银行为给收款对象提供银行账户的银行;
读取模块,用于从预设数据库中读取与所述第三方支付账户相关联的至少一个银行账户;
加密模块,用于根据所述加密算法对所述至少一个银行账户进行加密,得到至少一个待确认密文,其中,每个待确认密文与一个银行账户相对应;
检测模块,用于检测所述至少一个待确认密文中是否存在与所述目标密文相同的第一密文;
确定模块,用于在所述至少一个待确认密文中存在所述第一密文时,确定所述第一密文对应的银行账户为所述目标银行账户,并从所述目标银行账户中扣除所述待付款金额。
9.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求1至6任一项中所述的交易处理方法。
10.一种电子设备,其特征在于,包括一个或多个处理器和存储器,所述存储器用于存储一个或多个程序,其中,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现权利要求1至6中任意一项所述的交易处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211510708.2A CN115809874A (zh) | 2022-11-29 | 2022-11-29 | 交易处理方法、装置、系统及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211510708.2A CN115809874A (zh) | 2022-11-29 | 2022-11-29 | 交易处理方法、装置、系统及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115809874A true CN115809874A (zh) | 2023-03-17 |
Family
ID=85484415
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211510708.2A Pending CN115809874A (zh) | 2022-11-29 | 2022-11-29 | 交易处理方法、装置、系统及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115809874A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117436119A (zh) * | 2023-10-23 | 2024-01-23 | 拉卡拉支付股份有限公司 | 用户数字钱包的隐私保护方法、装置、电子设备及介质 |
-
2022
- 2022-11-29 CN CN202211510708.2A patent/CN115809874A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117436119A (zh) * | 2023-10-23 | 2024-01-23 | 拉卡拉支付股份有限公司 | 用户数字钱包的隐私保护方法、装置、电子设备及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6360101B2 (ja) | Ic識別カードを使用した支払いシステムおよび方法 | |
AU2010295188B2 (en) | Asset storage and transfer system for electronic purses | |
CN105160523B (zh) | 加密切换处理 | |
US7747539B2 (en) | Contactless-chip-initiated transaction system | |
CN104599408B (zh) | 基于动态二维码的第三方账户自动柜员机取款方法及系统 | |
US20110010289A1 (en) | Method And System For Controlling Risk Using Static Payment Data And An Intelligent Payment Device | |
US8886932B2 (en) | Message storage and transfer system | |
AU2023201327B2 (en) | Techniques for secure channel communications | |
CN105117963A (zh) | 基于数字签名的装置和方法 | |
CN104933565A (zh) | 一种ic卡交易方法及系统 | |
US20230222475A1 (en) | Rules engine for communication round trips optimization of kernel-in-cloud payment transaction | |
JP2013505487A (ja) | 電子財布のための資産価値記憶、転送システム | |
CN115809874A (zh) | 交易处理方法、装置、系统及电子设备 | |
CN101673443B (zh) | 网络收银机系统及其实现方法 | |
US20190034891A1 (en) | Automated transaction system, method for control thereof, and card reader | |
CN114981810A (zh) | 通用非接触式内核系统和方法 | |
CN114912148B (zh) | 鉴权方法及装置、系统、计算机存储介质、电子设备 | |
CN103871163A (zh) | 复合金融交易方法和系统 | |
CN116823476A (zh) | 基于区块链的跨区域交易数据处理方法和装置 | |
KR20130052552A (ko) | 메시지 저장 및 전송 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |