CN110415118A - 处理方法及其装置、电子设备和介质 - Google Patents

Abstract

本公开提供了一种针对交易行为的处理方法，包括：获取待交易行为的属性信息，其中，属性信息包括待交易行为的交易属性信息和执行待交易行为的账户的属性信息；通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果；以及基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用。此外，本公开还提供了一种针对交易行为的处理装置，一种电子设备以及一种计算机可读存储介质。

Description

处理方法及其装置、电子设备和介质

技术领域

本公开涉及计算机技术领域，特别是涉及一种针对交易行为的处理方法及其装置、电子设备和介质。

背景技术

商业银行在为客户提供各种优质金融服务时，会收取合理范围的费用作为佣金，同时也会从不同维度定制手续费优惠策略作为回馈客户或者推广新产品的手段。通常，不同的金融服务产品、不同的金融市场环境支付习惯千差万别，且常随着市场的变化发生改变。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题，针对不同的金融产品、不同的金融市场环境，需要开发不同的支付系统，容易造成重复开发维护，或者不易扩展的技术问题。

发明内容

有鉴于此，本公开提供了一种针对交易行为的处理方法及其装置、电子设备和计算机可读存储介质，为解决相关技术中在针对不同的金融产品、不同的金融市场环境时，需要开发不同的支付系统，容易造成重复开发维护，或者不易扩展的技术问题，提供一种针对交易行为的解决方案，实现可以根据金融产品、金融市场环境而随时扩展，同时可以避免各产品线系统重复开发维护。

为实现上述目的，本公开的一个方面提供了一种针对交易行为的处理方法，上述方法可以包括：获取待交易行为的属性信息，其中，上述属性信息包括上述待交易行为的交易属性信息和执行上述待交易行为的账户的属性信息，通过利用预定支付规则解析引擎来解析上述待交易行为的账户属性信息，确定上述待交易行为是否符合支付条件，以获得确定结果，以及基于上述确定结果和上述待交易行为的交易属性信息，确定执行上述待交易行为的账户需支付的服务费用。

根据本公开的实施例，在确定上述待交易行为是否符合支付条件，以获得确定结果之前，上述方法还可以包括：针对多个已交易行为，提取多个支付规则，配置各支付规则对应的支付条件，配置上述多个支付规则彼此之间的逻辑规则，基于上述多个支付规则、与上述各支付规则对应的支付条件和上述多个支付规则彼此之间的逻辑规则，配置多个预设条件参数，以及基于上述多个预设条件参数，创建上述预定支付规则解析引擎。

根据本公开的实施例，上述通过利用预定支付规则解析引擎来解析上述待交易行为的账户属性信息，确定上述待交易行为是否符合支付条件，以获得确定结果可以包括：获取上述预定支付规则解析引擎中的多个预设条件参数，将上述待交易行为的账户的属性信息与上述多个预设条件参数进行匹配，以获得匹配结果，以及基于上述匹配结果，确定上述待交易行为是否符合支付条件，以获得确定结果。

根据本公开的实施例，上述基于上述确定结果和上述待交易行为的交易属性信息，确定执行上述待交易行为的账户需支付的服务费用可以包括：在上述确定结果指示符合上述支付条件的情况下，基于上述待交易行为的交易属性信息，获取上述待交易行为的交易金额和支付场景信息，针对上述支付场景信息，获取预设的服务费用，以及基于上述待交易行为的交易金额以及上述预设的服务费用，确定执行上述待交易行为的账户需支付的服务费用。

根据本公开的实施例，上述基于上述确定结果和上述待交易行为的交易属性信息，确定执行上述待交易行为的账户需支付的服务费用还可以包括：在上述确定结果指示不符合上述支付条件的情况下，确定执行上述待交易行为的账户需支付的服务费用为零。

根据本公开的实施例，上述方法还可以包括：检测上述支付规则是否发生变化，以及在检测到上述支付规则发生变化的情况下，更新上述预定支付规则解析引擎，以得到更新后的预定支付规则解析引擎。

为实现上述目的，本公开的另一个方面提供了一种针对交易行为的支付装置，上述装置可以包括：获取模块，被配置为获取待交易行为的属性信息，其中，上述属性信息包括上述待交易行为的交易属性信息和执行上述待交易行为的账户的属性信息，第一确定模块，被配置为通过利用预定支付规则解析引擎来解析上述待交易行为的账户属性信息，确定上述待交易行为是否符合支付条件，以获得确定结果，以及第二确定模块，被配置为基于上述确定结果和上述待交易行为的交易属性信息，确定执行上述待交易行为的账户需支付的服务费用。

根据本公开的实施例，上述装置还可以包括：提取模块，被配置为针对多个已交易行为，提取多个支付规则，第一配置模块，被配置为配置各支付规则对应的支付条件，第二配置模块，被配置为配置上述多个支付规则彼此之间的逻辑规则，第三配置模块，被配置为基于上述多个支付规则、与上述各支付规则对应的支付条件和上述多个支付规则彼此之间的逻辑规则，配置多个预设条件参数，以及创建模块，被配置为基于上述多个预设条件参数，创建上述预定支付规则解析引擎。

根据本公开的实施例，上述第一确定模块可以包括：第一获取子模块，被配置为获取上述预定支付规则解析引擎中的多个预设条件参数，匹配子模块，被配置为将上述待交易行为的账户的属性信息与上述多个预设条件参数进行匹配，以获得匹配结果，以及第一确定子模块，被配置为基于上述匹配结果，确定上述待交易行为是否符合支付条件，以获得确定结果。

根据本公开的实施例，上述第二确定模块可以包括：第二获取子模块，被配置为在上述确定结果指示符合上述支付条件的情况下，基于上述待交易行为的交易属性信息，获取上述待交易行为的交易金额和支付场景信息，第三获取子模块，被配置为针对上述支付场景信息，获取预设的服务费用，以及第二确定子模块，被配置为基于上述待交易行为的交易金额以及上述预设的服务费用，确定执行上述待交易行为的账户需支付的服务费用。

根据本公开的实施例，上述第二确定模块还可以包括：第三确定子模块，被配置为在上述确定结果指示不符合上述支付条件的情况下，确定执行上述待交易行为的账户需支付的服务费用为零。

根据本公开的实施例，上述方法还可以包括：检测模块，被配置为检测上述支付规则是否发生变化，以及更新模块，被配置为在检测到上述支付规则发生变化的情况下，更新上述预定支付规则解析引擎，以得到更新后的预定支付规则解析引擎。

为实现上述目的，本公开的另一方面提供了一种电子设备，可以包括：一个或多个处理器，存储器，用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现如上所述的针对交易行为的处理方法。

为实现上述目的，本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现如上所述的针对交易行为的处理方法。

为实现上述目的，本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现如上所述的针对交易行为的处理方法。

由上可见，与相关技术相比，本公开实施例提供的针对交易行为的处理方法，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果，以及基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用，可以在金融产品的交易过程中动态识别支付场景，实现支付场景的随时可扩展。此外，可以在支付场景中的支付规则发生变化的情况下，对预定支付规则解决引擎执行自动更新，以适应更新的支付场景，扩展应用场景，还可以集成在商业银行提供的各产品系统中，以达到提升商业银行系统的可维护性，降低开发成本的技术效果。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了适用于本公开实施例的针对交易行为的处理方法及其装置的系统架构；

图2示意性示出了适用于本公开实施例的针对交易行为的处理方法及其装置的应用场景；

图3示意性示出了根据本公开实施例的针对交易行为的处理方法的流程图；

图4示意性示出了根据本公开另一实施例的针对交易行为的处理方法的流程图；

图5示意性示出了根据本公开另一实施例的针对交易行为的处理的流程图；

图6示意性示出了根据本公开另一实施例的针对交易行为的处理的流程图；

图7示意性示出了根据本公开另一实施例的针对交易行为的处理方法的流程图；

图8示意性示出了根据本公开实施例的针对交易行为的处理装置的框图；

图9示意性示出了根据本公开另一实施例的针对交易行为的处理装置的框图；以及

图10示意性示出了根据本公开实施例的适于实现上文描述的针对交易行为的处理方法及其装置的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了上述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

作为交易行为的服务提供方，金融机构或银行在通过提供各种优质的金融服务为客户提供交易行为时，可以收取合理范围的服务费用作为佣金。具体地，可以针对不同类型的待交易行为和/或针对执行待交易行为的不同账户的属性信息，制定服务费用的收取规则，以实现收取合理范围的服务费用作为佣金，同时也会从不同维度定制服务费用的优惠策略作为回馈客户或者推广新产品的手段。

作为交易行为的服务发起方，客户在使用金融机构或银行提供的金融服务执行交易行为时，需要向金融机构或银行支付一定的服务费用。但是，金融服务涉及到的服务产品以及市场环境计费规则千差万别，且经常随着市场变化，针对不同的金融产品，需要指定不同的支付系统来实现支付处理，并没有统一的处理方法，可以在交易过程中动态识别支付场景。

本公开的实施例提供了一种针对交易行为的处理方法，包括：在某账户发生交易行为时，首先可以获取待交易行为的属性信息，该属性信息可以包括待交易行为的交易属性信息和执行待交易行为的账户的属性信息。接着，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果。最后，基于确定结果和待交易行为的交易属性信息，可以确定执行待交易行为的账户需支付的服务费用。可以在金融产品的交易行为的执行过程中动态识别支付场景，实现支付场景的随时可扩展。

图1示意性示出了本公开实施例的针对交易行为的处理方法及其装置的系统架构100。需要说明的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如金融机构提供的各种支付应用，购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的针对交易行为的处理方法一般可以由服务器105执行。相应地，本公开实施例所提供的针对交易行为的处理装置一般可以设置于服务器105中。本公开实施例所提供的针对交易行为的处理方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的针对交易行为的处理装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

可以理解，本公开的交易行为可以包括但不限于取款交易行为、汇款交易行为、转账交易行为。具体地，可以包括以下交易行为中的任何一种：从个人储蓄账户取款的交易行为，从个人信用卡账户取现的交易行为，从个人某一账户向其他账户汇款或/转账的交易行为，从个人某一账户向其他客户的第三方账户(储蓄账户和/或信用卡账户)汇款或/转账的交易行为。

图2示意性示出了适用于本公开实施例的针对交易行为的处理方法及其装置的应用场景200。需要注意的是，图2所示仅为可以应用本公开实施例的应用场景的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

鉴于针对不同的交易行为，本公开提供的处理方法具有相同的实施方式。因此，本公开实施例的下文将以待交易行为是从个人储蓄账户取款的交易行为为例，阐述本公开的具体实施方式。如图2所示，适用于本公开实施例的针对交易行为的处理方法和装置的应用场景200可以包括AA银行的自动取款机(Automatic Teller Machine，简称ATM)，也称为自动柜员机。用户利用该ATM，从AA银行提供的个人储蓄账户中取款10000元。利用本公开提供的针对该取款交易行为的处理方法，可以自动识别该交易场景中的属性信息，确定待交易行为是否符合支付条件，以获得确定结果，最终识别出执行此次交易行为的用户的个人储蓄账户是否需要向AA银行支付一定的服务费用，若需要支付，还可以确定需要向AA银行支付多少服务费用。

可以理解的是，该交易行为不是对本公开提供的针对交易行为的处理方法所针对的待交易行为的限定。其他交易行为的处理方法可以依据从个人储蓄账户取款的交易行为的具体实施方式适当展开。

以下将结合图2所示的应用场景，参考附图并结合具体实施例详细阐述本公开。

图3示意性示出了根据本公开实施例的针对交易行为的处理方法的流程图。

如图3所示，该方法包括操作S310～操作S330。

首先，在操作S310，获取待交易行为的属性信息。

根据本公开的实施例，待交易行为的属性信息用于作为判断此次待交易行为是否需要支付服务费用的判断依据。

作为一种可选的实施例，属性信息可以包括待交易行为的交易属性信息，也可以包括执行待交易行为的账户的属性信息。其中，交易属性信息包括但不限于交易类型、交易地点、交易日期以及交易金额。账户的属性信息可以包括但不限于账户开户日期、账户所属客户的用于标识该客户是本地居民还是非本地居民的标识信息、账户年均余额、账户当前是否透支以及账户所属开户网点。

可以人工识别待执行交易行为即取款交易的相关属性，拆解出账户的属性信息，也可以自动识别待执行交易行为即取款交易的相关属性，拆解出账户的属性信息。

接下来，在操作S320，通过利用预定支付规则解析引擎来解析待交易行为的账户的属性信息，确定待交易行为是否符合支付条件，以获得确定结果。

然后，在操作S330，基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用。

根据本公开的实施例，预定支付规则解析引擎用于解析账户的属性信息，确定待交易行为符合支付条件，还是不符合支付条件。预定支付规则解析引擎(Engine)是金融机构或银行的电子平台上开发程序或系统的核心组件。

可以理解的是，针对不同的交易行为，用户支付的服务费用不同，甚至针对同一交易行为涉及的不同交易金额，用户支付的服务费用也不同。因此，若符合支付条件，则可以根据待交易行为的交易属性信息和不同的条件配置所配置的不同的收费标准，确定需支付的服务费用。

例如，若预定支付规则解析引擎规定日均余额小于10000元，本地居民，开户日期大于2012-01-01，并且账户发生透支时，若发生取款交易则收取手续费，若不满足，则不收取手续费。则针对图2所示的应用场景，若用户的账户日均余额大于10000元，本地居民，开户时间小于2012-01-01，账户未发生透支，若用户不需向银行AA支付服务费用。通过本公开的实施例，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果，以及基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用，可以在金融产品的交易过程中动态识别支付场景，实现支付场景的随时可扩展。同时在支付场景中的支付规则发生变化的情况下，对预定支付规则解决引擎执行自动更新，以适应更新的支付场景，扩展应用场景，还可以集成在商业银行提供的各产品系统中，以达到提升商业银行系统的可维护性，降低开发成本的技术效果。

图4示意性示出了根据本公开另一实施例的针对交易行为的处理方法的流程图。如图4所示，该方法除了可以包括前述操作S310～操作S330之外，在操作S320之前，该方法还可以包括操作S410～操作S450。

在操作S410，针对多个已交易行为，提取多个支付规则。

在操作S420，配置各支付规则对应的支付条件。

在操作S430，配置多个支付规则彼此之间的逻辑规则。

在操作S440，基于多个支付规则、与各支付规则对应的支付条件和多个支付规则彼此之间的逻辑规则，配置多个预设条件参数。

在操作S450，基于多个预设条件参数，创建预定支付规则解析引擎。

根据本公开的实施例，预定支付规则解析引擎是可以预先创建的，用于为不同交易场景中的交易行为提供规则解析，实现了支付场景的参数化配置，可以扩展于多个不同的支付场景的支付行为，扩大预定支付规则解析引擎的适应范围。

根据本公开的实施例，可以针对多个已经执行过的交易行为，引入费用条件参数，将多个费用场景中的每个条件抽象成多个支付规则。另外，不同的支付规则具有不同的类型，包括但不限于数值型、字符型和日期型。也可以为多个支付规则配置每种支付规则对应的条件关系，即支付条件，该条件关系包括大于、等于、小于。还可以为多个支付规则配置彼此之间的逻辑规则，包括但不限于与、或、非。其中，“与”指示只有多个支付规则都是true，结果才是true。“或”指示一个支付规则或多个支付规则为true，结果才是true，只有多个支付规则全部为false，结果才是false。“非”指示支付规则为false，结果才是true。

例如，交易金额可以抽象为数值型，支付规则名称、交易地区、服务费用名称可以抽象为字符型，交易日期可以抽象为日期型。为数值型的支付规则配置对应的支付条件为大于，为字符型的支付规则配置对应的支付条件为等于，为日期型的支付规则配置对应的支付条件为小于。为交易金额和交易地区彼此之间配置的逻辑规则为“与”，为交易金额和交易日期彼此之间配置的逻辑规则为“或”。

作为一种可选的实施例，也可以根据不同的费用场景，引入费用条件参数，将多个费用场景中的每个条件抽象成多个支付规则。另外，不同的支付规则具有不同的类型，包括但不限于数值型、字符型和日期型。也可以为多个支付规则配置每种支付规则对应的条件关系，即支付条件，该条件关系可以包括大于、大于等于、小于、小于等于、等于、不等于。还可以为多个支付规则配置彼此之间的逻辑规则，包括但不限于与、或、非。符合多个预设条件参数，则可以不同的条件配置不同的收费标准确定最终需支付的服务费用。具体的配置方式如前所述，此次不再赘述。

例如，融资类贷款承诺金额大于1000万人民币时，收取承诺额1％的手续费。在该场景中可以抽象出两个支付规则，一是贷款类型为融资类贷款，二是承诺额大于1000万人民币，两个支付规则是“与”的判定关系，将该场景参数化配置后，在贷款交易过程中，预定支付规则解析引擎可以自动根据交易信息解析是否需要收费。

表1示意性列出了本公开的实施例配置的取款手续费的判定参数。

表1

如表1所示，列出判断序号分别为N1、N2和N3的三种取款手续费的支付规则的判断方式。其中，判断序号为N1的判定方法是“A”与“B”，判断序号为N2的判定方法是“C”与“C”，判断序号为N3的判定方法是“N1”或“N2”。

表2示意性示出了根据本公开的实施例创建的预定支付规则解析引擎中的预设条件参数。

如表2所示，以北京地区和上海地区的取款手续费的支付场景为例。沿用表1中所示的条件序号A、B、C、D。其中，条件A和条件B对应北京地区的取款手续费的支付场景中预设条件参数，条件C和条件D对应上海地区的取款手续费的支付场景中预设条件参数。结合表1所示的判断方式，可以自动识别待交易行为需要支付的服务费用。

具体地，条件A是条件名称为日均余额的数值型条件，对应的条件参数代码为100，条件规则为小于，条件值为10000。条件B是条件名称为居民标识的字符型条件，对应的条件参数代码为101，条件规则为等于，条件值为1。条件C是条件名称为是否透支的数值型条件，对应的条件参数代码为102，条件规则为等于，条件值为1。条件D是条件名称为开户日期的日期型条件，对应的条件参数代码为103，条件规则为大于，条件值为2012-01-01。

需要说明的是，A、B、C和D仅代表根据支付场景抽象出来的支付规则，根据不同的支付场景，可以具有不同的实际含义。

表2

通过本公开的实施例，可以基于多个支付规则、与各支付规则对应的支付条件和多个支付规则彼此之间的逻辑规则，配置多个预设条件参数，以创建预定支付规则解析引擎，实现预定支付规则解析引擎的自由配置，方便在支付系统中集成和扩展预定支付规则解析引擎。

图5示意性示出了根据本公开实施例的确定待交易行为是否符合支付条件，以获得确定结果的流程图。

如图5所示，前述操作S320可以包括操作S510～操作S530。

在操作S510，获取预定支付规则解析引擎中的多个预设条件参数。

在操作S520，将待交易行为的账户的属性信息与多个预设条件参数进行匹配，以获得匹配结果。

在操作S530，基于匹配结果，确定待交易行为是否符合支付条件，以获得确定结果。

根据本公开的实施例，在检测到取款交易发生时，针对该取款交易行为的支付场景，可以获取预定支付规则解析引擎中的多个预设条件参数，将包括待交易行为的账户的属性信息的全量条件上送至预定支付规则解析引擎，由预定支付规则解析引擎判断是否匹配到支付场景以获得确定结果

根据本公开的实施例，确定待交易行为是否符合支付条件，可以获得两种确定结果，第一种是符合支付条件，第二种是不符合支付条件。

针对符合支付条件的确定结果，图6示意性示出了根据本公开实施例的基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用的流程图。如图6所示，前述操作S330可以包括操作S610～操作S630。

在操作S610，在确定结果指示符合支付条件的情况下，基于待交易行为的交易属性信息，获取待交易行为的交易金额和支付场景信息。

在操作S620，针对支付场景信息，获取预设的服务费用。

在操作S630，基于待交易行为的交易金额以及预设的服务费用，确定执行待交易行为的账户需支付的服务费用。

作为一种可选的实施例，在确定结果指示不符合支付条件的情况下，确定执行待交易行为的账户需支付的服务费用为零。

例如，某账户发生取款交易行为，提取出账户的属性信息如下。

账户开户日期：2019-01-01。

账户所属客户本地居民非本地居民标志：1-是。

账户的年均余额：20000。

账户当前是否透支：0-否。

账户所属开户网点：1。

本次取款交易行为的交易金额：8000。

根据预定支付规则解析引擎进行规则匹配，本地居民符合条件，但开户日期、年均余额、是否透支均不符合条件，因此该笔取款交易行为不收取手续费。

图7示意性示出了根据本公开另一实施例的针对交易行为的处理方法的流程图。

如图7所示，该方法除了可以包括前述操作S310～操作S330、前述操作S410～操作S450之外，还可以包括操作S710和操作S720。

在操作S710，检测支付规则是否发生变化。

在操作S720，在检测到支付规则发生变化的情况下，更新预定支付规则解析引擎，以得到更新后的预定支付规则解析引擎。

在相关技术中，若交易行为的支付规则发生变化，则需要开发人员根据改变的支付规则重新开发支付系统的相关部分，开发投入成本较大，且开发期间将影响正常业务的运行，降低用户的体验感受。

而根据本公开的实施例，由于预定支付规则解析引擎是通过参数化配置实现的，若交易行为的支付规则发生变化，仅需修改引擎参数配置，并不需要开发人员根据改变的支付规则重新开发支付系统的相关部分，可以避免由于重新开发影响正常的业务运行导致的用户体验感受降低的技术问题。

根据本公开的实施例，针对多个已交易行为或支付场景，可以提取至少一个更新的支付规则，以获得多个更新后的支付规则。接着，为多个更新后的支付规则配置对应的支付条件。同时，为多个更新后的支付规则的各支付规则配置彼此之间的逻辑规则。基于多个更新后的支付规则、为多个更新后的支付规则配置对应的支付条件和多个更新后的支付规则的各支付规则配置彼此之间的逻辑规则，配置多个更新后的预设条件参数。基于多个更新后的预设条件参数，更新预定支付规则解析引擎，以获得更新后的预定支付规则解析引擎。

通过利用更新后的预定支付规则解析引擎来解析待交易行为的账户的属性信息，确定待交易行为是否符合支付条件，以获得确定结果。然后，基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用。

图8示意性示出了根据本公开实施例的针对交易行为的支付装置的框图。

如图8所示，该装置800可以包括获取模块810、第一确定模块820以及第二确定模块830。

获取模块810，被配置为执行例如前述操作S310，获取待交易行为的属性信息，其中，属性信息包括待交易行为的交易属性信息和执行待交易行为的账户的属性信息。

第一确定模块820，被配置为执行例如前述操作S320，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果。

第二确定模块830，被配置为执行例如前述操作S330，基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用。

通过本公开的实施例，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果，以及基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用，可以在金融产品的交易过程中动态识别支付场景，实现支付场景的随时可扩展。同时在支付场景中的支付规则发生变化的情况下，对预定支付规则解决引擎执行自动更新，以适应更新的支付场景，扩展应用场景，还可以集成在商业银行提供的各产品系统中，以达到提升商业银行系统的可维护性，降低开发成本的技术效果。

图9示意性示出了根据本公开另一实施例的针对交易行为的支付装置的框图。

如图9所示，该装置900除了可以包括前述获取模块810、第一确定模块820以及第二确定模块830之外，还可以包括提取模块910、第一配置模块920、第二配置模块930、第三配置模块940以及创建模块950。

提取模块910，被配置为执行例如前述操作S410，针对多个已交易行为，提取多个支付规则。

第一配置模块920，被配置为执行例如前述操作S420，配置各支付规则对应的支付条件。

第二配置模块930，被配置为执行例如前述操作S430，配置多个支付规则彼此之间的逻辑规则。

第三配置模块940，被配置为执行例如前述操作S440，基于多个支付规则、与各支付规则对应的支付条件和多个支付规则彼此之间的逻辑规则，配置多个预设条件参数。

在本公开中，符合多个预设条件参数指示需支付的服务费用可以为零，也可以不为零，具体支付的费用可以不同的条件配置不同的收费标准

创建模块950，被配置为执行例如前述操作S450，基于多个预设条件参数，创建预定支付规则解析引擎。

需要说明的是，针对交易行为的处理装置部分的实施例方式与针对交易行为的处理方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

通过本公开的实施例，可以基于多个支付规则、与各支付规则对应的支付条件和多个支付规则彼此之间的逻辑规则，配置多个预设条件参数，以创建预定支付规则解析引擎，实现预定支付规则解析引擎的自由配置，方便在支付系统中集成和扩展预定支付规则解析引擎。

作为一种可选的实施例，前述第一确定模块可以包括：第一获取子模块，被配置为获取前述预定支付规则解析引擎中的多个预设条件参数，匹配子模块，被配置为将前述待交易行为的账户的属性信息与前述多个预设条件参数进行匹配，以获得匹配结果，以及第一确定子模块，被配置为基于前述匹配结果，确定前述待交易行为是否符合支付条件，以获得确定结果。

作为一种可选的实施例，前述第二确定模块可以包括：第二获取子模块，被配置为在前述确定结果指示符合前述支付条件的情况下，基于前述待交易行为的交易属性信息，获取前述待交易行为的交易金额和支付场景信息，第三获取子模块，被配置为针对前述支付场景信息，获取预设的服务费用，以及第二确定子模块，被配置为基于前述待交易行为的交易金额以及前述预设的服务费用，确定执行前述待交易行为的账户需支付的服务费用。

作为一种可选的实施例，前述第二确定模块还可以包括：第三确定子模块，被配置为在前述确定结果指示不符合前述支付条件的情况下，确定执行前述待交易行为的账户需支付的服务费用为零。

作为一种可选的实施例，前述方法还可以包括：检测模块，被配置为检测前述支付规则是否发生变化，以及更新模块，被配置为在检测到前述支付规则发生变化的情况下，更新前述预定支付规则解析引擎，以得到更新后的预定支付规则解析引擎。

根据本公开的实施例的模块、子模块中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，获取模块810、第一确定模块820、第二确定模块830、提取模块910、第一配置模块920、第二配置模块930、第三配置模块940、创建模块950、第一获取子模块、匹配子模块、第一确定子模块、第二获取子模块、第三获取子模块、第二确定子模块、第三确定子模块、检测模块以及更新模块中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，获取模块810、第一确定模块820、第二确定模块830、提取模块910、第一配置模块920、第二配置模块930、第三配置模块940、创建模块950、第一获取子模块、匹配子模块、第一确定子模块、第二获取子模块、第三获取子模块、第二确定子模块、第三确定子模块、检测模块以及更新模块中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块810、第一确定模块820、第二确定模块830、提取模块910、第一配置模块920、第二配置模块930、第三配置模块940、创建模块950、第一获取子模块、匹配子模块、第一确定子模块、第二获取子模块、第三获取子模块、第二确定子模块、第三确定子模块、检测模块以及更新模块中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图10示意性示出了根据本公开实施例的适于实现上文描述的针对交易行为的处理方法的电子设备的框图。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，根据本公开实施例的计算机系统1000包括处理器1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。处理器1001例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1001还可以包括用于缓存用途的板载存储器。处理器1001可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1003中，存储有系统1000操作所需的各种程序和数据。处理器1001、ROM1002以及RAM 1003通过总线1004彼此相连。处理器1001通过执行ROM 1002和/或RAM 1003中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除ROM 1002和RAM 1003以外的一个或多个存储器中。处理器1001也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统1000还可以包括输入/输出(I/O)接口1005，输入/输出(I/O)接口1005也连接至总线1004。系统1000还可以包括连接至I/O接口1005的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被处理器1001执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。当程序产品在电子设备1000上运行时，程序代码用于使电子设备1000执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的针对交易行为的处理方法中的步骤。例如，电子设备1000可以执行如图3中所示的操作S310，获取待交易行为的属性信息。操作S320，通过利用预定支付规则解析引擎来解析待交易行为的账户属性信息，确定待交易行为是否符合支付条件，以获得确定结果。操作S330，基于确定结果和待交易行为的交易属性信息，确定执行待交易行为的账户需支付的服务费用。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1002和/或RAM 1003和/或ROM 1002和RAM 1003以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种针对交易行为的处理方法，包括：

获取待交易行为的属性信息，其中，所述属性信息包括所述待交易行为的交易属性信息和执行所述待交易行为的账户的属性信息；

通过利用预定支付规则解析引擎来解析所述待交易行为的账户的属性信息，确定所述待交易行为是否符合支付条件，以获得确定结果；以及

基于所述确定结果和所述待交易行为的交易属性信息，确定执行所述待交易行为的账户需支付的服务费用。

2.根据权利要求1所述的方法，在确定所述待交易行为是否符合支付条件，以获得确定结果之前，所述方法还包括：

针对多个已交易行为，提取多个支付规则；

配置各支付规则对应的支付条件；

配置所述多个支付规则彼此之间的逻辑规则；

基于所述多个支付规则、与所述各支付规则对应的支付条件和所述多个支付规则彼此之间的逻辑规则，配置多个预设条件参数；以及

基于所述多个预设条件参数，创建所述预定支付规则解析引擎。

3.根据权利要求1所述的方法，其中，所述通过利用预定支付规则解析引擎来解析所述待交易行为的账户的属性信息，确定所述待交易行为是否符合支付条件，以获得确定结果包括：

获取所述预定支付规则解析引擎中的多个预设条件参数；

将所述待交易行为的账户的属性信息与所述多个预设条件参数进行匹配，以获得匹配结果；以及

基于所述匹配结果，确定所述待交易行为是否符合支付条件，以获得确定结果。

4.根据权利要求1所述的方法，其中，所述基于所述确定结果和所述待交易行为的交易属性信息，确定执行所述待交易行为的账户需支付的服务费用包括：

在所述确定结果指示符合所述支付条件的情况下，基于所述待交易行为的交易属性信息，获取所述待交易行为的交易金额和支付场景信息；

针对所述支付场景信息，获取预设的服务费用；以及

基于所述待交易行为的交易金额以及所述预设的服务费用，确定执行所述待交易行为的账户需支付的服务费用。

5.根据权利要求1所述的方法，其中，所述基于所述确定结果和所述待交易行为的交易属性信息，确定执行所述待交易行为的账户需支付的服务费用还包括：

在所述确定结果指示不符合所述支付条件的情况下，确定执行所述待交易行为的账户需支付的服务费用为零。

6.根据权利要求2所述的方法，其中，所述方法还包括：

检测所述支付规则是否发生变化；以及

在检测到所述支付规则发生变化的情况下，更新所述预定支付规则解析引擎，以得到更新后的预定支付规则解析引擎。

7.一种针对交易行为的支付装置，包括：

获取模块，被配置为获取待交易行为的属性信息，其中，所述属性信息包括所述待交易行为的交易属性信息和执行所述待交易行为的账户的属性信息；

第一确定模块，被配置为通过利用预定支付规则解析引擎来解析所述待交易行为的账户的属性信息，确定所述待交易行为是否符合支付条件，以获得确定结果；以及

第二确定模块，被配置为基于所述确定结果和所述待交易行为的交易属性信息，确定执行所述待交易行为的账户需支付的服务费用。

8.根据权利要求7所述的装置，其中，所述装置还包括：

提取模块，被配置为针对多个已交易行为，提取多个支付规则；

第一配置模块，被配置为配置各支付规则对应的支付条件；

第二配置模块，被配置为配置所述多个支付规则彼此之间的逻辑规则；

第三配置模块，被配置为基于所述多个支付规则、与所述各支付规则对应的支付条件和所述多个支付规则彼此之间的逻辑规则，配置多个预设条件参数；以及

创建模块，被配置为基于所述多个预设条件参数，创建所述预定支付规则解析引擎。

9.一种电子设备，包括：

一个或多个处理器；以及

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至6中任一项所述的方法。

10.一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现权利要求1至6中任一项所述的方法。