电子支付方法及应用服务器与流程

本发明涉及通信
技术领域：
，尤其涉及一种电子支付方法及应用服务器。
背景技术：
：目前越来越多的第三方支付平台都支持很多的支付渠道，比如美团支付、12306支付等等，当在这些第三方支付平台关联的消费平台或者纯粹的第三方支付平台进行支付请求时，由于这些第三方支付平台关联着很多支付渠道，比如各大银行，甚至是支付宝或者微信支付，第三方支付界面一般会以列表的形式将所有的支付渠道进行列表呈现，然后供用户选择，但目前这种做法仅仅只是呈现给用户各个支付渠道的名单列表，用户并不能人为的很快的从诸多支付渠道中选择出最佳的支付渠道，即影响了用户体验。技术实现要素：有鉴于此，本发明提出一种电子支付方法及应用服务器，可以在为用户提供多种不同的支付渠道的同时，还能根据用户选择的支付信息自动的为用户规划或选择出一条最优的支付渠道，进而提升用户体验。首先，为实现上述目的，本发明提出一种应用服务器，所述应用服务器包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的电子支付程序，所述电子支付程序被所述处理器执行时实现如下步骤：向各个支付渠道发送注册请求消息；接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；将所述用户支付信息与所述渠道属性表进行匹配；及选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。可选地，所述属性信息包括第一属性信息，所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间；所述用户支付信息包括：用户选择的支付业务级别、支付业务类型、支付金额、支付时间。可选地，所述属性信息还包括第二属性信息，所述第二属性信息包括：渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率。可选地，所述选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付的步骤，具体包括：当渠道属性表中存在预设数量的渠道的属性信息中第一属性信息与所述用户支付信息匹配时，根据所述预设数量的渠道的属性信息中的第二属性信息确定与所述用户支付信息匹配的属性信息对应的支付渠道。此外，为实现上述目的，本发明还提供一种电子支付方法，该方法应用于应用服务器，所述方法包括：向各个支付渠道发送注册请求消息；接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；将所述用户支付信息与所述渠道属性表进行匹配；及选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。可选地，所述属性信息包括第一属性信息，所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间；所述用户支付信息包括：用户选择的支付业务级别、支付业务类型、支付金额、支付时间。可选地，所述将所述用户支付信息与所述渠道属性表进行匹配的步骤，具体包括：判断用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型是否相同；当用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型相同时，则进一步判断用户选择的支付金额是否低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额，且同时判断用户选择的支付时间是否在所述第一属性信息中的渠道的服务时间内；及当用户选择的支付金额低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额，同时，用户选择的支付时间在所述第一属性信息中的渠道的服务时间内时，则判断所述第一属性信息与所述用户支付信息匹配。可选地，所述属性信息还包括第二属性信息，所述第二属性信息包括：渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率。可选地，所述选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付的步骤，具体包括：当渠道属性表中存在预设数量的渠道的属性信息中第一属性信息与所述用户支付信息匹配时，根据所述预设数量的渠道的属性信息中的第二属性信息确定与所述用户支付信息匹配的属性信息对应的支付渠道。进一步地，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有电子支付程序，所述电子支付程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的电子支付方法的步骤。相较于现有技术，本发明所提出的应用服务器、电子支付方法及计算机可读存储介质，首先，向各个支付渠道发送注册请求消息；其次，接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；再次，对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；然后，接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；接着，将所述用户支付信息与所述渠道属性表进行匹配；最后，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。这样，可以避免现有技术中只是呈现给用户各个支付渠道的名单列表，用户并不能人为的很快的从诸多支付渠道中选择出最佳的支付渠道的弊端，可以在为用户提供多种不同的支付渠道的同时，还能根据用户选择的支付信息自动的为用户规划或选择出一条最优的支付渠道，进而提升用户体验。附图说明图1是应用服务器一可选的硬件架构的示意图；图2是本发明电子支付程序第一实施例的程序模块图；图3为本发明电子支付方法第一实施例的流程图；图4为本发明电子支付方法第二实施例的流程图。附图标记：应用服务器1存储器11处理器12网络接口13电子支付程序200请求模块201接收模块202整理模块203解析模块204匹配模块205支付模块206本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。具体实施方式为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。参阅图1所示，是应用服务器1一可选的硬件架构的示意图。所述应用服务器1可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，该应用服务器1可以是独立的服务器，也可以是多个服务器所组成的服务器集群。本实施例中，所述应用服务器1可包括，但不仅限于，可通过系统总线相互通信连接存储器11、处理器12、网络接口13。所述应用服务器1通过网络接口13连接网络，获取资讯。所述网络可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(globalsystemofmobilecommunication，gsm)、宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi-fi、通话网络等无线或有线网络。需要指出的是，图1仅示出了具有组件11-13的应用服务器1，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，所述存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器11可以是所述应用服务器1的内部存储单元，例如该应用服务器1的硬盘或内存。在另一些实施例中，所述存储器11也可以是所述应用服务器1的外部存储设备，例如该应用服务器1配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。当然，所述存储器11还可以既包括所述应用服务器1的内部存储单元也包括其外部存储设备。本实施例中，所述存储器11通常用于存储安装于所述应用服务器1的操作系统和各类应用软件，例如所述电子支付程序200的程序代码等。此外，所述存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。所述处理器12在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述应用服务器1的总体操作，例如执行数据交互或者通信相关的控制和处理等。本实施例中，所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据，例如运行所述的电子支付程序200等。所述网络接口13可包括无线网络接口或有线网络接口，该网络接口13通常用于在所述应用服务器1与其他电子设备之间建立通信连接。本实施例中，所述应用服务器1内安装并运行有电子支付程序200，当所述电子支付程序200运行时，所述应用服务器1向各个支付渠道发送注册请求消息；接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；将所述用户支付信息与所述渠道属性表进行匹配；及选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。这样，可以避免现有技术中只是呈现给用户各个支付渠道的名单列表，用户并不能人为的很快的从诸多支付渠道中选择出最佳的支付渠道的弊端，可以在为用户提供多种不同的支付渠道的同时，还能根据用户选择的支付信息自动的为用户规划或选择出一条最优的支付渠道，进而提升用户体验。至此，己经详细介绍了本发明各个实施例的相关设备的硬件结构和功能。下面，将基于上述应用环境和相关设备，提出本发明的各个实施例。首先，本发明提出一种电子支付程序200。本实施例中，所述的电子支付程序200包括一系列的存储于存储器11上的计算机程序指令，当该计算机程序指令被处理器12执行时，可以实现本发明各实施例的电子支付操作。在一些实施例中，基于该计算机程序指令各部分所实现的特定的操作，所述电子支付程序200可以被划分为一个或多个模块。例如，在图2中，所述的电子支付程序200可以被分割成请求模块201、接收模块202、整理模块203、解析模块204、匹配模块205以及支付模块206。其中：所述请求模块201，用于向各个支付渠道发送注册请求消息。在本实施例中，支付渠道可以包括各大银行，比如民生银行渠道、北京银行渠道、平安银行渠道等各种银行渠道，当然也可以包括向支付宝或者微信这种第三方渠道。由于涉及电子支付，所以必须事先需要向这些支付渠道进行注册，进而获得支付渠道的支付授权，进而正常实施支付功能。所述接收模块202，用于接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息。具体地，所述属性信息包括第一属性信息，所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间。在本实施例中，支付业务级别指的是用户发起支付交易，可选择实时到账，2小时内到账，次日提出等；支付业务类型指的是很多业务类型，比如联机单笔代收，联机单笔代付，退款，批量代付，信用卡还款，银行卡转账等，具体地，不同的渠道支持的业务类型也不一样。渠道的单笔限额是指通过该渠道每笔交易的额度。渠道的单日限额指的是通过该渠道每天交易的额度。例如，银行卡普通用户每日交易额度不能高于5万元。渠道的服务时间指的是渠道支持交易的服务时间，比如每天早上点至晚上八点。所述整理模块203，用于对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表。所述解析模块204，用于接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息。具体地，所述用户支付信息包括：用户选择的支付业务级别、支付业务类型、支付金额、支付时间。所述匹配模块205，用于在所述解析模块204解析出用户支付信息后，将所述用户支付信息与所述渠道属性表进行匹配。具体地，所述匹配模块204通过以下步骤将所述用户支付信息与所述渠道属性表进行匹配：所述匹配模块205，首先判断用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型是否相同。当用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型相同时，则所述匹配模块205进一步判断用户选择的支付金额是否低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额，且同时判断用户选择的支付时间是否在所述第一属性信息中的渠道的服务时间内。只有，当用户选择的支付金额低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额，同时，用户选择的支付时间在所述第一属性信息中的渠道的服务时间内时，则所述匹配模块205判断所述第一属性信息与所述用户支付信息匹配。所述支付模块206，用于根据所述匹配模块205得出的匹配结果，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。本实施例中，所述属性信息还包括第二属性信息，所述第二属性信息包括：渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率。下面对第二属性信息进行具体的说明。在本实施例中，渠道的稳定性是指通过对历史交易的计算，可得出过去的一段时间内，每个渠道的稳定性，同等情况下，智能路由选择稳定性强的渠道。渠道的并发性是指经过动态存量的计算，可计算过去的一段时间内，每个渠道的并发性能，同等情况下，智能路由会根据并发性强的渠道。渠道的支付成功率是指通过对历史交易的计算得到每个渠道的支付成功率，同等情况下，智能路由选择支付成功率高的渠道。渠道的状态：渠道有不同的状态，比如正常，暂停，或者突发不可用等状态，智能路由需根据渠道的状态来选择渠道。渠道到账时效：通过对历史存量的交易的统计计算，可得出不同渠道的到账失效，同等条件下，智能路由可帮助客户选择到账时效最短的渠道。渠道支付费率：通过相应渠道进行支付时，需要支付的相应费率。本实施例中，当渠道属性表中存在预设数量(例如至少两个)的渠道的属性信息中第一属性信息(支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间)与所述用户支付信息匹配时，所述支付模块206根据所述预设数量(例如至少两个)的渠道的属性信息中的第二属性信息(渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率)确定与所述用户支付信息匹配的属性信息对应的支付渠道。所述预设数量由管理人员根据实际需要进行设置，所述预设数量越大，支付渠道越优。在本实施方式中，当与用户的支付信息匹配的第一属性信息存在多个时，即存在多个渠道匹配用户的支付信息，那么则需要根据这些渠道属性信息中的第二属性信息，选择一个最优的渠道进行支付，比如渠道稳定性最高的、渠道并发性最强的、渠道支付成功率最高的、渠道状态为正常的，渠道到账时效最短的等等。下面以一个具体的实施例进行描述:当目标商户发起一笔代收交易(支付业务类型)，所述目标商户为等级为一般的客户，在上午10点发起一笔对中国银行的转账10万，选择的是实时到账。即所述接收模块202接收到该目标商户的交易请求时，所述解析模块204解析出所述目标商户选择的支付业务级别为实时到账，支付业务类型为银行卡转账，支付金额为10万、支付时间为上午10点。所述匹配模块205，将所述目标商户的支付信息与渠道属性表进行匹配，以得到合适的渠道。所述匹配模块205通过渠道属性表匹配出：民生渠道和平安银行都支持该交易业务类型(转账)，和业务等级(实时)，民生渠道和平安银行的服务时间也与目标商户的时间匹配(服务时间为上午10点)，对于判断单日额度和单笔额度，民生渠道和平安银行均支持单笔转账额度10万。最后判断费率，因为渠道属性表中民生渠道相比平安银行的费率更低，且该通道可用，成功率为99％，所以最终所述匹配模块205选择了民生渠道。因此，所述支付模块206，根据所述匹配模块205得出的匹配结果为目标商户推荐民生渠道进行支付。通过上述程序模块201-206，本发明所提出的电子支付程序200，首先，向各个支付渠道发送注册请求消息；其次，接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；再次，对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；然后，接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；接着，将所述用户支付信息与所述渠道属性表进行匹配；最后，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。这样，可以避免现有技术中只是呈现给用户各个支付渠道的名单列表，用户并不能人为的很快的从诸多支付渠道中选择出最佳的支付渠道的弊端，可以在为用户提供多种不同的支付渠道的同时，还能根据用户选择的支付信息自动的为用户规划或选择出一条最优的支付渠道，进而提升用户体验。此外，本发明还提出一种电子支付方法。参阅图3所示，是本发明电子支付方法第一实施例的流程图。在本实施例中，根据不同的需求，图3所示的流程图中的步骤的执行顺序可以改变，某些步骤可以省略。步骤s301，向各个支付渠道发送注册请求消息。在本实施例中，支付渠道可以包括各大银行，比如民生银行渠道、北京银行渠道、平安银行渠道等各种银行渠道，当然也可以包括向支付宝或者微信这种第三方渠道。由于涉及电子支付，所以必须事先需要向这些支付渠道进行注册，进而获得支付渠道的支付授权，进而正常实施支付功能。步骤s302，接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息。具体地，所述属性信息包括第一属性信息，所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间。在本实施例中，支付业务级别指的是用户发起支付交易，可选择实时到账，2小时内到账，次日提出等；支付业务类型指的是很多业务类型，比如联机单笔代收，联机单笔代付，退款，批量代付，信用卡还款，银行卡转账等，具体地，不同的渠道支持的业务类型也不一样。渠道的单笔限额是指通过该渠道每笔交易的额度。渠道的单日限额指的是通过该渠道每天交易的额度。例如，银行卡普通用户每日交易额度不能高于5万元。渠道的服务时间指的是渠道支持交易的服务时间，比如每天早上点至晚上八点。步骤s303，对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表。步骤s304，接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息。具体地，所述用户支付信息包括：用户选择的支付业务级别、支付业务类型、支付金额、支付时间。步骤s305，将所述用户支付信息与所述渠道属性表进行匹配。具体地，所述将所述用户支付信息与所述渠道属性表进行匹配的具体步骤，将在本发明电子支付方法的第二实施例(参阅图4)进行详述。步骤s306，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。具体地，所述应用服务器1根据步骤s305得出的匹配结果，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。本实施例中，所述属性信息还包括第二属性信息，所述第二属性信息包括：渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率。下面对第二属性信息进行具体的说明。在本实施例中，渠道的稳定性是指通过对历史交易的计算，可得出过去的一段时间内，每个渠道的稳定性，同等情况下，智能路由选择稳定性强的渠道。渠道的并发性是指经过动态存量的计算，可计算过去的一段时间内，每个渠道的并发性能，同等情况下，智能路由会根据并发性强的渠道。渠道的支付成功率是指通过对历史交易的计算得到每个渠道的支付成功率，同等情况下，智能路由选择支付成功率高的渠道。渠道的状态：渠道有不同的状态，比如正常，暂停，或者突发不可用等状态，智能路由需根据渠道的状态来选择渠道。渠道到账时效：通过对历史存量的交易的统计计算，可得出不同渠道的到账失效，同等条件下，智能路由可帮助客户选择到账时效最短的渠道。渠道支付费率：通过相应渠道进行支付时，需要支付的相应费率。本实施例中，当渠道属性表中存在预设数量(例如至少两个)的渠道的属性信息中第一属性信息(支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间)与所述用户支付信息匹配时，所述应用服务器1根据所述预设数量(例如至少两个)的渠道的属性信息中的第二属性信息(渠道的稳定性、渠道的并发性、渠道的支付成功率、渠道的状态、渠道到账时效及渠道支付费率)确定与所述用户支付信息匹配的属性信息对应的支付渠道。所述预设数量由管理人员根据实际需要进行设置，所述预设数量越大，支付渠道越优。在本实施方式中，当与用户的支付信息匹配的第一属性信息存在多个时，即存在多个渠道匹配用户的支付信息，那么则需要根据这些渠道属性信息中的第二属性信息，选择一个最优的渠道进行支付，比如渠道稳定性最高的、渠道并发性最强的、渠道支付成功率最高的、渠道状态为正常的，渠道到账时效最短的等等。下面以一个具体的实施例进行描述:当目标商户发起一笔代收交易(支付业务类型)，所述目标商户为等级为一般的客户，在上午10点发起一笔对中国银行的转账10万，选择的是实时到账。即所述应用服务器1接收到该目标商户的交易请求时，解析出所述目标商户选择的支付业务级别为实时到账，支付业务类型为银行卡转账，支付金额为10万、支付时间为上午10点。所述应用服务器1，将所述目标商户的支付信息与渠道属性表进行匹配，以得到合适的渠道。所述应用服务器1通过渠道属性表匹配出：民生渠道和平安银行都支持该交易业务类型(转账)，和业务等级(实时)，民生渠道和平安银行的服务时间也与目标商户的时间匹配(服务时间为上午10点)，对于判断单日额度和单笔额度，民生渠道和平安银行均支持单笔转账额度10万。最后判断费率，因为渠道属性表中民生渠道相比平安银行的费率更低，且该通道可用，成功率为99％，所以最终所述应用服务器1选择了民生渠道。因此，所述应用服务器1根据得出的匹配结果为目标商户推荐民生渠道进行支付。通过上述步骤s301-306，本发明所提出的电子支付方法，首先，向各个支付渠道发送注册请求消息；其次，接收所述各个支付渠道返回的注册响应消息，所述注册响应消息包括所述各个支付渠道的属性信息；再次，对所述各个支付渠道的属性信息以支付渠道的标识为单位进行归类整理并形成渠道属性表；然后，接收用户发起的支付请求，并从所述支付请求中解析出用户支付信息；接着，将所述用户支付信息与所述渠道属性表进行匹配；最后，选择所述渠道属性表中与所述用户支付信息匹配的属性信息对应的支付渠道进行支付。这样，可以避免现有技术中只是呈现给用户各个支付渠道的名单列表，用户并不能人为的很快的从诸多支付渠道中选择出最佳的支付渠道的弊端，可以在为用户提供多种不同的支付渠道的同时，还能根据用户选择的支付信息自动的为用户规划或选择出一条最优的支付渠道，进而提升用户体验。进一步地，基于本发明电子支付方法的第一实施例，提出本发明电子支付方法的第二实施例。如图4所示，是本发明电子支付方法的第二实施例的流程图。本实施例中，所述将所述用户支付信息与所述渠道属性表进行匹配的步骤，具体包括：步骤s401，判断用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型是否相同。当用户选择的支付业务级别、支付业务类型与所述渠道属性表中第一属性信息中的支付业务级别、支付业务类型相同时，执行步骤s402，否则，结束流程。具体地，所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间。步骤s402，判断用户选择的支付金额是否低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额。当用户选择的支付金额低于所述第一属性信息中的渠道的单笔限额和渠道的单日限额时，执行步骤s403，否则，结束流程。所述第一属性信息包括：支付业务级别、支付业务类型、渠道的单笔限额、渠道的单日限额、渠道的服务时间。步骤s403，判断用户选择的支付时间是否在所述第一属性信息中的渠道的服务时间内。当用户选择的支付时间在所述第一属性信息中的渠道的服务时间内时，执行步骤s404，否则，结束流程。步骤s404，判断所述第一属性信息与所述用户支付信息匹配。具体地，所述用户支付信息包括：用户选择的支付业务级别、支付业务类型、支付金额、支付时间。通过上述步骤s401-s404，本发明所提出的电子支付方法，可以通过用户的支付信息与渠道属性表进行匹配，以选择最优的支付渠道。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
，均同理包括在本发明的专利保护范围内。当前第1页12