CN111178888A

CN111178888A - 一种支付服务的管理方法及系统

Info

Publication number: CN111178888A
Application number: CN201911393167.8A
Authority: CN
Inventors: 雷欣; 张子辉; 杨青刚; 郑如意; 李严桵; 武有文; 李�昊; 郑友杰; 李书源
Original assignee: Bank of China Ltd
Current assignee: Bank of China Ltd
Priority date: 2019-12-30
Filing date: 2019-12-30
Publication date: 2020-05-19

Abstract

本发明提出了一种支付服务的管理方法及系统，该方法包括：获取支付服务数据，查询服务开关参数；当服务开关参数为开时，生成交易请求；根据交易请求进行交易处理，得到支付信息，包括资源占用率、交易异常的支付信息；根据支付信息进行数据分析，其中，在资源占用率超过预设阈值的情况下，关闭外围支付服务，保留核心支付服务；在一预设时间内，如果出现交易异常的数量达到阈值，关闭对应的支付服务，修改服务开关参数为关。利用该方法及系统可以在支付服务出现异常时实时下线服务，避免资金损失；在资源占用率较高时，能够策略性地关闭某些外围支付服务，保证核心服务安全稳定；在下线服务的同时能够保留拓展服务，尽可能保证客户的使用。

Description

一种支付服务的管理方法及系统

技术领域

本发明涉及支付处理技术领域，尤指一种支付服务的管理方法及系统，用于APP内支付服务的管理。

背景技术

目前，金融业APP中往往包含较多支付服务，支付场景涉及客户动帐，对安全性、实时性、体验性均要求极高，一旦出现扣款异常，容易引发客户投诉。

另外，针对金融业APP的后台服务，并发过高时若不能及时暂停交易，可能引发服务崩溃，造成更大风险。

因此，亟需一种可以对支付服务进行自动管理、控制的方案，保证支付安全性、稳定性、体验性。

发明内容

为解决上述问题，本发明提出了一种支付服务的管理方法及系统，可以针对金融业APP中的支付服务，在已经或即将无法正常提供服务时自动下线，关闭支付功能，同时保留其他拓展功能(如交易记录查询，商品浏览等)，保证支付安全性、稳定性、体验性。

在本发明一实施例中，提出了一种支付服务的管理方法，该方法包括：

获取支付服务数据，查询服务开关参数；

当服务开关参数为开时，生成交易请求；

根据所述交易请求进行交易处理，得到支付信息，所述支付信息包括资源占用率、交易异常的支付信息；

根据所述支付信息进行数据分析，得到分析结果，其中，

在资源占用率超过预设阈值的情况下，关闭外围支付服务，保留核心支付服务；

在一预设时间内，如果出现交易异常的数量达到阈值，关闭对应的支付服务，修改服务开关参数为关。

进一步的，获取支付服务数据，查询服务开关参数，当服务开关参数为开时，生成交易请求，还包括：

当服务开关参数为关时，生成无法支付的提示信息。

进一步的，根据所述支付信息进行数据分析，包括：

根据所述支付信息，分析资源占用率，其中，所述资源占用率由CPU占用率、内存占用率和数据库占用率来界定；

当其中一项占用率达到80％以上，判定进入高风险运行态，关闭外围支付服务，保留核心支付服务。

进一步的，根据所述支付信息，分析资源占用率，还包括：

获取并发数，当并发数连续一定时间达到最大并发值的75％以上，判定进入高风险运行态。

进一步的，根据所述交易请求进行交易处理，得到支付信息，包括：

由支付后台向核心支付服务申请动账，如果超过一设定时间未收到回复，判定为交易失败，生成交易异常的支付信息。

进一步的，根据所述支付信息进行数据分析，包括：

对每分钟的所述支付信息进行批量处理，统计异常交易的数量；如果交易发起方在1分钟内的交易异常数达到阈值，判定交易发起方已发生支付报错故障，关闭对应的支付服务，修改服务开关参数为关。

在本发明另一实施例中，还提出了一种支付服务的管理系统，该系统包括：

数据获取模块，用于获取支付服务数据，查询服务开关参数；

交易请求生成模块，用于在服务开关参数为开的情况下，生成交易请求；

交易处理模块，用于根据所述交易请求进行交易处理，得到支付信息，所述支付信息包括资源占用率、交易异常的支付信息；

数据分析模块，用于根据所述支付信息进行数据分析，得到分析结果，其中，

进一步的，该系统还包括：配置服务器，用于存储服务开关参数，所述服务开关参数的初始状态为开。

在本发明另一实施例中，还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现支付服务的管理方法。

在本发明另一实施例中，还提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现支付服务的管理方法。

利用本发明提出的支付服务的管理方法及系统，可以在支付服务出现异常时实时下线服务，避免资金损失；在资源占用率较高时，能够策略性地关闭某些外围支付服务，保证核心服务安全稳定；在下线服务的同时能够保留拓展服务，尽可能保证客户的使用。

附图说明

图1示意性地示出了本发明实施方式可以在其中实施的应用场景。

图2是本发明一实施例的支付服务的管理方法流程示意图。

图3是本发明一具体实施例的数据分析的详细流程示意图。

图4是本发明一具体实施例的支付服务的管理逻辑示意图。

图5是本发明一具体实施例的交易异常的支付信息处理流程示意图。

图6是本发明一实施例的支付服务的管理系统架构示意图。

图7是本发明一实施例的计算机设备结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种支付服务的管理方法及系统。

首先参考图1，其示出了本发明的实施方式可以在其中实施的应用场景。

图1中所示的场景包括终端100和服务器200。

终端100可以是能够登录金融APP的移动终端，例如手机、平板电脑、笔记本电脑、个人数字助理等，还可以是能够显示金融页面的台式电脑。

服务器200可以是后台系统，用于处理支付信息，管理支付服务。

终端100与服务器200之间例如可以通过移动互联网等进行通信连接。

其中，终端100中装载的金融APP里封装有支付组件，服务器200内设置有支付后台、数据分析平台及配置服务器。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

图2是本发明一实施例的支付服务的管理方法流程示意图。如图2所示，该方法包括：

步骤S101，获取支付服务数据，查询服务开关参数；其中，服务开关参数的默认开关参数为开，通过步骤S103的数据分析后可能会更改开关参数。

步骤S102，当服务开关参数为开时，生成交易请求；

步骤S102'，当服务开关参数为关时，生成无法支付的提示信息

步骤S103，根据所述交易请求进行交易处理，得到支付信息，所述支付信息包括资源占用率、交易异常的支付信息；

步骤S104，根据所述支付信息进行数据分析，得到分析结果，其中，

在一实施例中，结合图3，步骤S104进行数据分析的详细过程为：

步骤S1041，根据所述支付信息，分析资源占用率，其中，所述资源占用率由CPU占用率、内存占用率和数据库占用率来界定；

当其中一项占用率达到80％以上，判定进入高风险运行态，关闭外围支付服务，保留核心支付服务；

另外，还可以通过获取并发数(TPS)进行辅助判断，当并发数连续一定时间(如10分钟)达到最大并发值的75％以上，判定进入高风险运行态。

通常，金融APP中引入的支付服务有多种，可以把客户最常用或时效性强的定义为核心支付服务(如，商城购物类、线下联动购票类等)，把使用率不高的定义为外围服务(如，抽奖、优惠券购买等)。

步骤S1042，对每分钟的所述支付信息进行批量处理，统计异常交易的数量；

如果交易发起方在1分钟内的交易异常数达到阈值，判定交易发起方已发生支付报错故障，关闭对应的支付服务，修改服务开关参数为关。

由于服务开关参数为关，则交易发起方再次发起交易请求时，无法进行支付。

在一实施例中，对于交易异常的支付信息，可以在步骤S102的处理过程中进行分析，具体过程为：

为了对上述支付服务的管理方法进行更为清楚的解释，下面结合具体的实施例来进行说明。

结合图4，为本发明一具体实施例的支付服务的管理逻辑示意图。如图4所示，支付组件410封装于金融APP内，设置在客户端；支付后台420、数据分析平台430、配置服务器440位于后台系统中；支付服务450是用户可以查看、操作的服务内容。

其中，

支付组件410：触发支付服务450时，会调起支付组件410，在调起支付组件410时，会将开关参数也一并传送给支付组件410；支付组件410包含开和关两个逻辑分支，可根据配置服务器440上配置参数进行切换。开关参数为开时，调用支付后台的接口实现支付，为关时，则提示客户无法支付。

在本实施例中，通过开发支付组件410，可以将支付服务450中的支付要素提取总结，形成统一支付组件410，每个支付服务450调起支付时均调用此组件，无需另行开发。

支付后台420：实现支付服务的后台。在完成支付交易的同时，异步将支付交易数据、资源占用数据推送给数据分析平台430。

在本实施例中，将支付后台420进行了改造，除原有支付功能外，还加入了数据推送，异步将支付交易数据、资源占用数据推送给数据分析平台430。

数据分析平台430：分析支付后台420推送的支付交易数据、支付后台资源占用情况，判断某个支付服务是否达到关闭阈值，若已达到阈值则向配置服务器440发送相应服务的关闭指令。

具体的，该平台可以根据各支付服务450推送的支付信息进行统筹分析，判断是否需要关闭报错支付服务、是否为了保持核心支付服务关闭外围服务等，并将支付开关数据以“服务：开/关”的形式推送给配置服务器440。

在本实施例中，数据分析平台430是新增模块，可以分析交易数据，对支付交易数据、资源占用情况进行数据分析，并判断某个支付服务是否达到关闭阈值。

配置服务器440：设置开关参数，通常默认开关参数为开；配置服务器440用于接收数据分析平台430推送指令，实时修改某个或多个支付服务的开关参数。当支付组件410发起支付服务查询时，还用于发送相应服务的开关参数给支付组件410。

在本实施例中，配置服务器440是新增设备，通过建立配置机制，使支付服务的流程可配置，当支付服务被调起时，需要先查询配置服务器，根据配置服务器返回的参数动态调整支付流程。

支付服务450：根据金融APP中的支付组件410实现支付功能的服务，例如购买电影票服务、缴纳电话费服务等。在接收到支付服务450时，主动通过支付组件410去配置服务器440上查询开关参数。

在一具体实施例中，支付后台对于支付交易信息，可以通过打标的方式标记交易异常；对未成功动帐(指没有从银行核心系统账户维度入账或出账)的交易，进行打标并将其信息发送至数据分析平台，来进行数据分析，详细过程如图5所示：

步骤S501，金融APP向支付后台申请动帐；

步骤S502，支付后台向核心申请动帐；

步骤S503，如果申请信息中途丢失，支付后台超过阈值未收到回复，提示金融APP前端客户交易未明；

步骤S504，支付后台放弃交易并将此交易打标，传送至数据分析平台；

步骤S505，数据分析平台记录异常交易数；

步骤S506，数据分析平台进行每分钟批量处理，对异常交易的发起方进行统计，若某发起方1分钟内交易异常数达到阈值，则认定此时发起方已发生支付报错故障。

在一具体实施例中，在支付后台还可以将资源占用数据推送给数据分析平台，由数据分析平台对资源占用数据进行分析，当支付系统占用率过高时，优先保证核心支付服务，也就是说，当资源占用率过高时，即使外围服务并没有报错，也会下线外围服务，以保证核心支付服务平稳运行。

本发明提出的支付服务的管理方法实现了在支付服务异常时能够实时下线服务，避免资金损失；在资源占用率较高时，能够策略性地关闭某些外围支付服务，保证核心服务安全稳定；在下线服务的同时能够保留拓展服务，尽可能保证客户的使用。

需要说明的是，尽管在上述实施例及附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

在介绍了本发明示例性实施方式的方法之后，接下来，参考图6对本发明示例性实施方式的支付服务的管理系统进行介绍。

支付服务的管理系统的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语“模块”或者“单元”，可以是实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

基于同一发明构思，本发明还提出了一种支付服务的管理系统，如图6所示，该系统包括：

数据获取模块610，用于获取支付服务数据，查询服务开关参数；

交易请求生成模块620，用于在服务开关参数为开的情况下，生成交易请求；

交易处理模块630，用于根据所述交易请求进行交易处理，得到支付信息，所述支付信息包括资源占用率、交易异常的支付信息；

数据分析模块640，用于根据所述支付信息进行数据分析，得到分析结果，其中，在资源占用率超过预设阈值的情况下，关闭外围支付服务，保留核心支付服务；

该系统还包括：配置服务器650，用于存储服务开关参数，所述服务开关参数的初始状态为开。

应当注意，尽管在上文详细描述中提及了支付服务的管理系统的若干模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

基于前述发明构思，如图7所示，本发明还提出了一种计算机设备700，包括存储器710、处理器720及存储在存储器710上并可在处理器720上运行的计算机程序730，所述处理器720执行所述计算机程序730时实现前述支付服务的管理方法。

在本发明另一实施例中，还提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现前述支付服务的管理方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims

1.一种支付服务的管理方法，其特征在于，该方法包括：

获取支付服务数据，查询服务开关参数；

当所述服务开关参数为开时，生成交易请求；

根据所述交易请求进行交易处理，得到支付信息；其中，所述支付信息包括资源占用率、交易异常的支付信息；

根据所述支付信息进行数据分析，得到分析结果，其中，

2.根据权利要求1所述的支付服务的管理方法，其特征在于，获取支付服务数据，查询服务开关参数，还包括：

当服务开关参数为关时，生成无法支付的提示信息。

3.根据权利要求1所述的支付服务的管理方法，其特征在于，根据所述支付信息进行数据分析，得到分析结果，包括：

4.根据权利要求3所述的支付服务的管理方法，其特征在于，根据所述支付信息进行数据分析，得到分析结果，还包括：

根据所述支付信息，获取并发数，当所述并发数连续一定时间达到最大并发值的75％以上，判定进入高风险运行态。

5.根据权利要求1所述的支付服务的管理方法，其特征在于，根据所述交易请求进行交易处理，得到支付信息，包括：

6.根据权利要求5所述的支付服务的管理方法，其特征在于，根据所述支付信息进行数据分析，得到分析结果，包括：

7.一种支付服务的管理系统，其特征在于，该系统包括：

8.根据权利要求7所述的支付服务的管理系统，其特征在于，该系统还包括：配置服务器，用于存储服务开关参数，所述服务开关参数的初始状态为开。

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6任一所述方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至6任一所述方法。