首页> 中国专利> 电子支付平台的支付渠道对接方法、系统及电子设备

电子支付平台的支付渠道对接方法、系统及电子设备

摘要

本发明公开了一种电子支付平台的支付渠道对接方法、系统及电子设备,通过将电子支付平台与支付渠道对接来完成电子支付平台上的电子支付行为,其中方法包括:封装支付指令统一API,通过支付指令统一API指定并调用与支付渠道对接的支付插件服务,其中,支付插件服务和支付渠道一一对接;通过支付插件服务封装与支付渠道对接的支付报文数据,并将支付报文数据发送至支付渠道;由支付渠道根据支付报文数据生成支付结果,并将支付结果通过对接的支付插件服务反馈至支付服务。本发明通过选择不同的支付插件服务,可以实现对接不同的支付渠道,并且降低了业务代码的耦合性,业务逻辑简单,维护代码方便,降低了研发成本和运维成本。

著录项

  • 公开/公告号CN114897523A

    专利类型发明专利

  • 公开/公告日2022-08-12

    原文格式PDF

  • 申请/专利权人 北京合思信息技术有限公司;

    申请/专利号CN202210473315.2

  • 发明设计人 马春荃;俞德明;种飞;

    申请日2022-04-29

  • 分类号G06Q20/32(2012.01);G06F9/445(2018.01);G06Q20/40(2012.01);

  • 代理机构北京知果之信知识产权代理有限公司 11541;

  • 代理人高科

  • 地址 100000 北京市海淀区丹棱街1号院1号楼22层2201室

  • 入库时间 2023-06-19 16:22:17

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-08-30

    实质审查的生效 IPC(主分类):G06Q20/32 专利申请号:2022104733152 申请日:20220429

    实质审查的生效

说明书

技术领域

本发明涉及电子支付技术领域,具体涉及一种电子支付平台的支付渠道对接方法、系统及电子设备。

背景技术

随着企业的发展,企业系统的电子支付平台对接的支付渠道越来越多,每对接一个新的支付渠道,都要重新编码做所有接口对接,对所有的支付渠道和支付逻辑做全量自测试与测试,修改原来的业务逻辑或在原来业务逻辑的基础上追加业务。

这种对接方式会导致业务逻辑越来越复杂,业务代码的耦合性越来越强,无法实现电子支付平台和支付渠道的灵活对接,影响所有支付渠道,同时,业务代码的耦合性太强会导致代码维护困难,增加研发成本和运维成本。

针对相关技术中电子支付平台对接的支付渠道增多,导致业务逻辑复杂、代码耦合性增强、无法实现灵活对接的问题,目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种电子支付平台的支付渠道对接方法及系统,以解决相关技术中电子支付平台对接的支付渠道增多,导致业务逻辑复杂、代码耦合性增强、无法实现灵活对接的问题。

为了实现上述目的,本发明的第一方面提供了一种电子支付平台的支付渠道对接方法,通过将电子支付平台与支付渠道对接来完成电子支付平台上的电子支付行为,包括:

封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,其中,所述支付插件服务和支付渠道一一对接;

通过所述支付插件服务封装与支付渠道对接的支付报文数据,并将所述支付报文数据发送至所述支付渠道;

由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务。

可选地,在封装支付指令统一API之前,所述方法还包括:

将电子支付平台和支付渠道进行认证授权;

完成认证授权后,在所述电子支付平台中配置收款账户,并在所述支付渠道中配置付款账户;

在所述电子支付平台中制作单据,根据所述单据生成支付计划;

根据所述支付计划选择付款账户和支付渠道,生成支付数据;

校验所述支付数据和所述支付计划是否相同,如果相同,则校验成功。

可选地,所述封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,包括:

定义对接规范,基于对接规范封装支付指令统一API;

通过所述支付指令统一API,从所有支付插件服务中选择与支付渠道对接的支付插件服务;

其中,所述所有支付插件服务包括电子支付平台提供的支付插件服务和/或第三方供应商自有的支付插件服务;

电子支付平台提供的支付插件服务能够与所述电子支付平台提供的支付渠道一一对接;和/或

第三方供应商自有的支付插件服务能够与所述第三方供应商提供的支付渠道一一对接。

可选地,所述通过所述支付插件服务封装与支付渠道对接的支付报文数据,包括:

将各种支付插件服务独立部署,并按照所述对接规范将各种支付插件服务各自提供的支付业务逻辑解耦;

通过所述支付插件服务提供的解耦后的支付业务逻辑,封装与支付渠道对接的支付报文数据。

可选地,所述由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务,包括:

由所述支付渠道根据支付报文数据进行支付处理;

支付处理完成后,生成支付结果,并将所述支付结果发送至对接的支付插件服务;

通过所述支付插件服务将所述支付结果反馈至支付服务。

可选地,在将所述支付结果通过对接的支付插件服务反馈至支付服务之后,所述方法还包括:

电子支付平台根据接收到的支付结果更新支付状态和支付计划;

通过所述支付指令统一API调用所述支付插件服务,获取回单数据并更新回单数据状态。

进一步地,所述通过所述支付指令统一API调用所述支付插件服务,获取回单数据并更新回单数据状态,包括:

定时通过所述支付指令统一API调用所述支付插件服务,通过所述支付插件服务向所述支付渠道发出回单请求;

所述支付渠道对回单请求做出响应,将回单数据通过所述支付插件服务反馈至电子支付平台;

所述电子支付平台存储接收到的回单数据,展示所述回单数据并更新回单数据状态。

本发明的第二方面提供了一种电子支付平台的支付渠道对接系统,通过将电子支付平台与支付渠道对接来完成电子支付平台上的电子支付行为,包括:

支付插件服务调用单元,用于封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,并调用所述支付插件服务,其中,所述支付插件服务和支付渠道一一对接;

支付报文数据发送单元,用于通过所述支付插件服务封装与支付渠道对接的支付报文数据,并将所述支付报文数据发送至所述支付渠道;

支付插件服务反馈单元,用于由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务。

本发明的第三方面提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机指令,所述计算机指令用于使计算机执行第一方面任意一项提供的电子支付平台的支付渠道对接方法。

本发明的第四方面提供了一种电子设备,所述电子设备包括:至少一个处理器;以及与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的计算机程序,所述计算机程序被所述至少一个处理器执行,以使所述至少一个处理器执行第一方面任意一项提供的电子支付平台的支付渠道对接方法。

在本发明实施例提供的电子支付平台的支付渠道对接方法中,封装支付指令统一API,实现支付指令的标准化流程;通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,其中,所述支付插件服务和支付渠道一一对接;通过选择并调用不同的支付插件服务,可以实现对接不同的支付渠道,并且,由于支付插件服务和支付渠道一一对接,因此可以降低业务代码的耦合性,业务逻辑简单,维护代码方便,降低了研发成本和运维成本;

通过所述支付插件服务封装与支付渠道对接的支付报文数据,并将所述支付报文数据发送至所述支付渠道,由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务,实现了支付渠道的灵活对接,解决了相关技术中电子支付平台对接的支付渠道增多,导致业务逻辑复杂、代码耦合性增强、无法实现灵活对接的问题。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的电子支付平台的支付渠道对接方法流程示意图;

图2为本发明实施例提供的对接方法的整体逻辑图;

图3为本发明实施例提供的电子支付平台的支付渠道对接系统框图;

图4为本发明实施例提供的电子设备框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。

需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本发明中,术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本发明及其实施例,并非用于限定所指示的系统、元件或组成部分必须具有特定方位,或以特定方位进行构造和操作。

需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

随着企业的发展,企业系统的电子支付平台对接的支付渠道越来越多,每对接一个新的支付渠道,都要重新编码做所有接口对接,对所有的支付渠道和支付逻辑做全量自测试与测试,修改原来的业务逻辑或在原来业务逻辑的基础上追加业务。这种对接方式会导致业务逻辑越来越复杂,业务代码的耦合性越来越强,无法实现电子支付平台和支付渠道的灵活对接,影响所有支付渠道,同时,业务代码的耦合性太强会导致代码维护困难,增加研发成本和运维成本。

为了解决上述问题,本发明实施例提供了一种电子支付平台的支付渠道对接方法,通过将电子支付平台与支付渠道对接来完成电子支付平台上的电子支付行为,电子支付平台提供支付服务和支付插件服务,如图1所示,该方法包括如下的步骤S101至步骤S103:

步骤S101:支付服务封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,其中,所述支付插件服务和支付渠道一一对接;API(Application Programming Interface)为应用程序编程接口,通过API可以调用服务或文件,支付服务标准化支付指令统一API,定义支付插件服务对接流程,可以实现支付指令的标准化流程,标准化对接规范与流程;支付服务和支付插件服务均位于电子支付平台中,由电子支付平台提供,并且,电子支付平台中的支付服务通过支付插件服务与支付渠道一一对接。

本发明实施例通过选择不同的支付插件服务,可以实现对接不同的支付渠道,并且,通过将支付插件服务和支付渠道一一对接,可以降低业务代码的耦合性,业务逻辑简单,维护代码方便,降低了研发成本和运维成本。

本发明提供的一种可选的实施方式中,在步骤S101中的封装支付指令统一API之前,所述方法还包括:

将电子支付平台和支付渠道进行认证授权;在标准化认证授权流程中,可以将电子支付平台中的扩展中心和支付渠道中的网银端进行授权绑定,完成认证授权;

完成认证授权后,在所述电子支付平台中配置收款账户,并在所述支付渠道中配置付款账户;分别配置收款账户和付款账户,以便于对接支付渠道后,在支付时通过付款账户和收款账户完成支付;

在所述电子支付平台中制作单据,根据所述单据生成支付计划;其中,单据为可支付的数据;

根据所述支付计划选择付款账户和支付渠道,生成支付数据;可以选择电子支付平台对接的支付渠道,也可以选择第三方供应商对接的支付渠道,满足不同用户的对接需求,实现灵活对接支付渠道;

校验所述支付数据和所述支付计划是否相同,如果相同,则校验成功。在校验成功的情况下,进入步骤S101,否则,校验失败,返回至制作单据,重新根据单据生成支付计划,以在封装支付指令统一API之前完成校验逻辑。

具体的,所述步骤S101中的封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,包括:

定义对接规范,基于对接规范封装支付指令统一API;支付服务根据已对接支付渠道建立统一的配置表,该配置表中包含与每个支付渠道对应的支付渠道名称、支付渠道编码和支付指令的接口地址,基于对接规范将配置表封装为支付指令统一API,每新对接一个支付渠道,则在配置表中新增一条与新对接支付渠道对应的数据,通过该配置表动态完成电子支付平台与支付渠道的对接;其中,支付指令包括支付下单、支付结果查询和支付回单,支付服务标准化支付指令统一API,定义支付插件服务对接流程,可以实现支付指令的标准化流程,标准化对接规范与流程;

通过所述支付指令统一API,从所有支付插件服务中选择与支付渠道对接的支付插件服务;

其中,所述所有支付插件服务包括电子支付平台提供的支付插件服务和/或第三方供应商自有的支付插件服务;

电子支付平台提供的支付插件服务能够与所述电子支付平台提供的支付渠道一一对接;和/或

第三方供应商自有的支付插件服务能够与所述第三方供应商提供的支付渠道一一对接。

本发明实施例提供的对接方法的整体逻辑如图2所示,其中,通过电子支付平台支付指令统一API和支付插件服务传输指令,各种支付插件服务通过封装指令向对接的支付渠道发起请求,各种支付渠道接收对应的请求后进行响应,封装指令具体包括认证授权、支付下单、支付受理、支付结果查询、支付回单和支付回单受理;

各种支付插件服务包括电子支付平台提供的支付插件服务和第三方供应商自有的支付插件服务,当选择电子支付平台提供的支付插件服务时,可以是银企联插件服务、招商云直连插件服务、杭银财资插件服务,此时一一对接的支付渠道分别是银企联、招商云直连、杭银财资,当选择第三方供应商自有的支付插件服务时,一一对接的是第三方供应商提供的支付渠道,这样可以满足第三方供应商的对接需求,实现支付渠道的灵活选择。

本发明实施例在对接支付渠道时,可以使用电子支付平台对接的支付渠道,也可以使用由第三方供应商自行对接的支付渠道,满足第三方供应商的对接需求,实现支付渠道的灵活选择和扩展,提供对接方式的可选性;

并且,不同的支付插件服务对接不同的支付渠道,通过将支付插件服务和支付渠道一一对接,每个支付插件服务提供的业务逻辑对接一个支付渠道,可以降低业务代码的耦合性,业务逻辑简单,维护代码方便。

步骤S102:通过所述支付插件服务封装与支付渠道对接的支付报文数据,并将所述支付报文数据发送至所述支付渠道;

具体的,所述步骤S102中的通过所述支付插件服务封装与支付渠道对接的支付报文数据,包括:

将各种支付插件服务独立部署,并按照所述对接规范将各种支付插件服务各自提供的支付业务逻辑解耦;各种支付插件服务部署相互独立,各种支付插件服务之间互不影响,降低运维成本,并且,支付业务逻辑解耦,各种支付插件服务之间不存在侵入或交叉,只需要按照对接规范提供自身的支付业务逻辑,因此业务逻辑简单,降低了研发成本;

通过所述支付插件服务提供的解耦后的支付业务逻辑,封装与支付渠道对接的支付报文数据。支付报文数据包括支付插件服务与对接的支付渠道之间的请求和响应,具体包括认证授权、支付下单、支付受理、支付结果查询、支付回单和支付回单受理。

本发明实施例在增加新的支付渠道时,只需要增加与该支付渠道一一对接的支付插件服务,在支付插件服务中提供其自身的支付业务逻辑,不需要考虑或修改其他支付插件服务中的业务逻辑和业务代码,也不用重新部署整个项目服务,因此,降低了降低业务代码的耦合性,也降低了研发成本和运维成本。

步骤S103:由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务。

具体的,所述步骤S103包括:

由所述支付渠道根据支付报文数据进行支付处理;

支付处理完成后,生成支付结果,并将所述支付结果发送至对接的支付插件服务;

通过所述支付插件服务将所述支付结果反馈至支付服务。通过与支付渠道对接的支付插件服务,可以将支付结果反馈至电子支付平台中的支付服务。

本发明提供的一种可选的实施方式中,在步骤S103中的将所述支付结果通过对接的支付插件服务反馈至支付服务之后,所述方法还包括:

电子支付平台根据接收到的支付结果更新支付状态和支付计划;电子支付平台在接收到支付结果后,可以立即更新支付状态,进而根据支付状态的更新情况更新支付计划;

通过所述支付指令统一API调用所述支付插件服务,获取回单数据并更新回单数据状态。在更新支付计划之后,还可以发出支付回单请求,在获取到获取回单数据后对回单数据状态进行更新。

其中,所述通过所述支付指令统一API调用所述支付插件服务,获取回单数据并更新回单数据状态,包括:

定时通过所述支付指令统一API调用所述支付插件服务,通过所述支付插件服务向所述支付渠道发出回单请求;

所述支付渠道对回单请求做出响应,将回单数据通过所述支付插件服务反馈至电子支付平台;

所述电子支付平台存储接收到的回单数据,展示所述回单数据并更新回单数据状态。

本发明实施例可以按照预定的时间点获取回单数据,如设定每天6点、13点、21点调用支付插件服务,也可以按照预定的时间间隔获取回单数据,如设定从当前时刻起,每隔7个小时调用支付插件服务。

从以上的描述中,可以看出,本发明实现了如下技术效果:

本发明实施例在对接支付渠道时,可以使用电子支付平台对接的支付渠道,也可以使用由第三方供应商自行对接的支付渠道,满足第三方供应商的对接需求,实现支付渠道的灵活选择和扩展,提供对接方式的可选性;

本发明实施例中各种支付插件服务部署相互独立,各种支付插件服务之间互不影响,降低运维成本,并且,支付业务逻辑解耦,各种支付插件服务之间不存在侵入或交叉,只需要按照对接规范提供自身的支付业务逻辑,因此业务逻辑简单,降低了研发成本;

本发明实施例在增加新的支付渠道时,只需要增加与该支付渠道一一对接的支付插件服务,在支付插件服务中提供其自身的支付业务逻辑,不需要考虑或修改其他支付插件服务中的业务逻辑和业务代码,也不用重新部署整个项目服务,因此,降低了降低业务代码的耦合性,也降低了研发成本和运维成本。

需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。

本发明实施例还提供了一种用于实施上述电子支付平台的支付渠道对接方法的电子支付平台的支付渠道对接系统,通过将电子支付平台与支付渠道对接来完成电子支付平台上的电子支付行为,如图3所示,该系统包括:

支付插件服务调用单元31,用于封装支付指令统一API,通过所述支付指令统一API指定并调用与支付渠道对接的支付插件服务,其中,所述支付插件服务和支付渠道一一对接;

支付报文数据发送单元32,用于通过所述支付插件服务封装与支付渠道对接的支付报文数据,并将所述支付报文数据发送至所述支付渠道;

支付插件服务反馈单元33,用于由所述支付渠道根据支付报文数据生成支付结果,并将所述支付结果通过对接的支付插件服务反馈至支付服务。

本发明实施例还提供了一种电子设备,如图4所示,该电子设备包括一个或多个处理器41以及存储器42,图4中以一个处理器41为例。

该控制器还可以包括:输入装置43和输出装置44。

处理器41、存储器42、输入装置43和输出装置44可以通过总线或者其他方式连接,图4中以通过总线连接为例。

处理器41可以为中央处理器(Central Processing Unit,简称为CPU),处理器41还可以为其他通用处理器、数字信号处理器(Digital Signal Processor,简称为DSP)、专用集成电路(Application Specific Integrated Circuit,简称为ASIC)、现场可编程门阵列(Field-Programmable Gate Array,简称为FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片,或者上述各类芯片的组合,通用处理器可以是微处理器或者任何常规的处理器。

存储器42作为一种非暂态计算机可读存储介质,可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块,如本发明实施例中的控制方法对应的程序指令/模块。处理器41通过运行存储在存储器42中的非暂态软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例的电子支付平台的支付渠道对接方法。

存储器42可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储根据服务器操作的处理装置的使用所创建的数据等。此外,存储器42可以包括高速随机存取存储器,还可以包括非暂态存储器,例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中,存储器42可选包括相对于处理器41远程设置的存储器,这些远程存储器可以通过网络连接至网络连接装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置43可接收输入的数字或字符信息,以及产生与服务器的处理装置的用户设置以及功能控制有关的键信号输入。输出装置44可包括显示屏等显示设备。

一个或者多个模块存储在存储器42中,当被一个或者多个处理器41执行时,执行如图1所示的方法。

本领域技术人员可以理解,实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成的,程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各电机控制方法的实施例的流程。其中,存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,简称为ROM)、随机存储记忆体(Random AccessMemory,简称为RAM)、快闪存储器(Flash Memory,简称为FM)、硬盘(Hard Disk Drive,简称为HDD)或固态硬盘(Solid-State Drive,简称为SSD)等;存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本发明的实施方式,但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型,这样的修改和变型均落入由所附权利要求所限定的范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号