网上支付系统、网上支付方法、装置、介质及服务器与流程

本发明属于支付技术领域，特别是涉及一种网上支付系统、一种网上支付方法、一种网上支付装置、一种服务器及一种计算机可读存储介质。

背景技术：

网上支付是电子支付的一种形式，它是通过第三方提供的与银行的网上支付系统之间的接口进行的即时支付方式。通过网上支付系统可以直接把资金从用户的银行卡中转账到网站账户中，极大地方便了用户的支付过程。

现有的网上支付系统虽然能够满足大部分业务的日常所需，但同时也存在不少问题。首先，现有的网上支付系统架构设计耦合严重。一个小的改动往往也会造成蝴蝶效应，使得系统其他模块产生问题，严重地，甚至会导致业务瘫痪。其次，基于现有的网上支付系统，难以进行业务的快速拓展。由于网上支付系统是围绕借记卡和信用卡两种支付方式来进行设计开发的，整条支付链路都是采用固定的模式。如果希望支持其他类型的支付方式(如积分消费等)，就需要重新进行设计和整合，新业务从开发到最终上线需要的时间较长。第三，运营维护现有的网上支付系统的成本也较高。由于设计复杂，层次不清晰，为了保证系统的正常运行，需要投入较高的人力成本去进行运营维护。

技术实现要素：

有鉴于此，本发明实施例提供了一种网上支付系统、网上支付方法、装置、介质及服务器，以解决现有技术中网上支付系统架构设计耦合严重、维护成本较高，难以快速拓展新业务的问题。

本发明实施例的第一方面提供了一种网上支付系统，包括接入层、适配层和核心层，所述接入层包括多种接口类型，任一接口类型分别对应不同的支付载体，所述适配层集合有与多种支付渠道相适配的多种业务协议，所述核心层包括多个功能模块，任一功能模块分别实现一项或多项业务功能；其中：

所述接入层，用于检测经由任一支付渠道传输的支付指令，识别生成所述支付指令的支付载体，调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至所述适配层及所述核心层；

所述适配层，用于确定传输所述支付指令的所述支付渠道，为所述核心层提供适配所述支付渠道的目标业务协议；

所述核心层，用于基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

本发明实施例的第二方面提供了一种网上支付方法，应用于网上支付系统，所述网上支付系统包括接入层、适配层和核心层，所述接入层包括多种接口类型，任一接口类型分别对应不同的支付载体，所述适配层集合有与多种支付渠道相适配的多种业务协议，所述核心层包括多个功能模块，任一功能模块分别实现一项或多项业务功能；所述方法包括：

所述接入层检测经由任一支付渠道传输的支付指令，识别生成所述支付指令的支付载体，调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至所述适配层及所述核心层；

所述适配层确定传输所述支付指令的所述支付渠道，为所述核心层提供适配所述支付渠道的目标业务协议；

所述核心层基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

本发明实施例的第三方面提供了一种网上支付装置，应用于网上支付系统，所述网上支付系统包括接入层、适配层和核心层，所述接入层包括多种接口类型，任一接口类型分别对应不同的支付载体，所述适配层集合有与多种支付渠道相适配的多种业务协议，所述核心层包括多个功能模块，任一功能模块分别实现一项或多项业务功能；所述装置包括：

支付指令检测模块，用于检测经由任一支付渠道传输的支付指令；

支付载体识别模块，用于识别生成所述支付指令的支付载体；

接口调用模块，用于调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至业务协议确定模块及支付指令执行模块；

业务协议确定模块，用于确定传输所述支付指令的所述支付渠道，为所述支付指令执行模块提供适配所述支付渠道的目标业务协议；

支付指令执行模块，用于基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

本发明实施例的第四方面提供了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如上述第二方面所述网上支付方法的步骤。

本发明实施例的第五方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上述第二方面所述网上支付方法的步骤。

与现有技术相比，本发明实施例包括以下优点：

本发明实施例，通过在接入层中整合多种接口类型，用于分别对应不同的支付载体，在适配层中集合与多种支付渠道相适配的多种业务协议，在核心层中配置多种功能模块，由各个功能模块分别实现一项或多项业务功能，然后基于上述接入层、适配层和核心层构成网上支付系统。本实施例通过将系统架构分层设计，由各层中不同的模块分别实现一项或几项特定的功能，各层各模块之间分工明确，互不影响，降低了各层各模块之间的耦合度。对于某一模块出现的故障，可以针对性地进行排查和解决，不会因为一个模块故障而导致整个系统不可用。其次，当需要在系统中增加某一功能时，可以开发出该功能对应的模块并添加至系统中，当需要执行涉及到与其他模块共同配合才能实现的功能时，可以通过各个模块之间的相互调用完成，不仅方便了业务扩展，也能够实现对业务需求的快速响应，减少了新业务的开发时间及上线等待时间，降低了系统的设计复杂度，减少了运营维护的成本。

附图说明

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

图1是本发明一个实施例的一种网上支付系统的架构图；

图2是本发明一个实施例的一种网上支付系统的核心层的示意图；

图3是本发明一个实施例的一种网上支付方法的步骤流程示意图；

图4是本发明一个实施例的一种网上支付装置的示意图；

图5是本发明一个实施例的一种服务器的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本发明。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

下面通过具体实施例来说明本发明的技术方案。

参照图1，示出了本发明一个实施例的一种网上支付系统的架构图，具体包括接入层、适配层和核心层。本系统通过采用接入层、适配层和核心层的分工设计，来降低系统内的架构耦合。其中：

接入层可以提供不同版本的统一接入方案，通过对各种业务场景的数据接口进行包装，使其统一接入该层。在扩展新业务时，可以直接将对应的数据接口通过接入层接入系统即可。

在本发明实施例中，接入层可以包括多种接口类型，如api、pc、h5及sdk等等。任一接口类型分别对应不同的支付载体，如在pc端进行的支付或手机端的支付。

在本发明实施例中，接入层可以检测检测经由任一支付渠道传输的支付指令，并识别生成上述支付指令的支付载体，通过调用该支付载体对应的接口，可以采用上述接口将支付指令传输至适配层及核心层，作进一步处理。

在具体实现中，当用户针对某项业务发起支付指令时，支付系统可以根据该指令中携带的终端设备的信息，识别出用户当前支付时所使用的设备类型，然后为其调用该设备对应的接口。

例如，当用户在电脑端进行支付时，支付系统接收到的指令可以显示用户当前使用的为pc设备，对应该设备的接口为pc接口，通过该pc接口可以将用户电脑接入支付系统，以完成后续的支付过程。

适配层可以集合有与多种支付渠道相适配的多种业务协议。即，通过在适配层集合一系列的标准协议，用于适配各种支付渠道。这些业务协议可以以代码的形式写入适配层，通过预留的协议调用接口被不同的支付渠道调用。

在具体实现中，可以针对各种支付渠道进行分析，使其按照集合的标准协议进行数据整合，从而使得系统不必局限于单一的业务类型或业务模式，有利于对外扩展业务。

例如，适配层可以包括针对理财收银、银保收银、缴费收银及商城收银等多种业务场景下的标准协议，上述多种业务场景分别对应于理财、银保、缴费及信用卡商城等不同的支付渠道。

因此，适配层在接收到由接入层传输的支付指令后，可以通过确定传输该支付指令的支付渠道，为核心层提供适配上述支付渠道的目标业务协议。

通常，适配某个支付渠道的目标业务协议可能包括多种。因此，在本发明实施例中，当新增某个支付渠道时，可以首先人为地根据该渠道所能实现的功能确定其需要应用到的协议包括哪些，通过将所涉及的协议写入至适配层，可以构建出对应于该支付渠道的目标协议集。

需要说明的是，新增支付渠道所涉及到的协议可能是已经存在于适配层中的现有协议，此时，可以直接采用该现有协议；如果适配层中不存在该项协议，则需要将该协议对应的代码重新写入适配层。

在具体实现中，在适配层中构建的目标协议集可以预留一个协议调用接口，当该协议调用接口被核心层中的某一功能模块调用时，适配层可以通过此协议调用接口为核心层中的功能模块提供多种目标业务协议，以实现相应的支付过程。

核心层包括多种功能模块，是整个支付系统最重要的组成部分。与适配层整合业务所涉及的协议，接入层提供不同业务场景下的数据接口不同，各个业务所对应的具体功能模块均在核心层中实现。这些功能模块可以以代码的形式写入核心层，任一功能模块分别实现一项或多项具体的业务功能。

在本发明实施例中，核心层在接收到接入层传输的支付指令以及适配层提供的目标业务协议后，可以基于目标业务协议，调用与当前的支付渠道相对应的目标功能模块，并采用目标功能模块执行上述支付指令。

另一方面，核心层中的多种功能模块还可以按需组合，构建出多种功能部件，由这些功能部件共同实现多个业务场景下的业务。

本系统将各种业务类型或场景所涉及到的组件进行模块化设计，通过对不同的功能模块进行组合，从而可以完成各种业务类型或场景所需实现的多种功能。并且，各个功能模块可以针对性地进行扩展。在开发新业务时，只需对涉及到的功能模块进行简单的扩展，然后按需组合就能实现新业务的快速上线。

例如，清算模块可以扩展实时清算、分时清算等功能，费用模块也可以扩展出多费项、按月结算等功能。

通过对各种业务类型或场景所涉及到的组件进行模块化设计，不仅降低了各个功能模块之间的耦合度，使得各个功能模块之间互不影响，同时也提高了业务的可扩展性。

如图2所示，是本发明一个实施例的一种网上支付系统的核心层的示意图。核心层可以包括有多种功能模块。例如，支付模块、退款模块、费用模块、清算模块、对账模块、安全模块、预警模块，以及订单模块等等。当然，

在本发明实施例中，各个业务类型或场景所实现的功能可以通过不同模块组合成的部件来完成，整个支付系统可以包括有支付、退款、费用、清算、对账等部件，这些部件可以实现图2中所示的支付、转入、转出、清算、对账等服务功能。

在本发明实施例中，对于实现某个支付渠道的目标功能模块，核心层可以识别在该目标功能模块对应的代码中写入的一个或多个待组合的功能模块的标识信息，从而建立起目标功能模块与待组合功能模块之间的通信连接，然后基于上述通信连接，实现目标功能模块与待组合功能模块之间的数据传输和业务调用，将目标功能模块与待组合的功能模块组合为功能部件，在完成对相应的功能部件的构建后，可以采用该功能部件共同执行支付指令，实现相应的支付功能。

以支付功能为例，通过对支付所涉及到的业务进行分析可知，支付部件可以由各个更小粒度的支付渠道模块来支撑。d+转账、v+消费、万里通积分、金豆、微信支付等都可以作为独立的支付组件。上述支付组件可以进行组合，形成一个完整的支付部件。若有新的支付业务扩展，可以直接将新的支付类型进行模块化开发并添加至核心层，然后再按具体的业务场景进行组合即可，能够有效地节省新业务的开发周期。

在具体实现中，以金豆支付这一组件为例，开发人员可以根据该组件对应的具体功能编写组件代码，并写入至核心层，形成对应的金豆支付模块。

需要说明的是，当任一功能模块被添加至核心层时，核心层可以确定适配当前的功能模块的业务协议，并将适配当前的功能模块的业务协议的信息发送至适配层；由适配层具体判断适配层中是否集合有适配该功能模块的业务协议；若是，则可以通过在功能模块对应的代码中写入上述业务协议的协议调用接口对应的协议接口代码，实现功能模块对业务协议的调用；若否，适配层则可以提示开发人员需要重新写入适配当前的功能模块的业务协议。

例如，当开发出金豆支付模块，并在核心层中添加该金豆支付模块时，无需对接入层进行任何变更，而只需考虑现有的适配层中包含的各个协议是否完全支持金豆支付这一业务类型，如果支持，则仅需在金豆支付模块的代码中写入协议的接口代码，以实现金豆支付模块对具体协议的调用；若金豆支付所涉及的协议并未包含在适配层的现有协议中，则需要将该协议重新写入适配层。

初始时，各个功能模块相互独立。例如，金豆支付模块与其他已经存在的支付模块独立存在于核心层中。当然，对于其他非支付模块或组件，可以通过在金豆支付模块的代码中写入各个模块或组件的标识信息，通过运行上述代码，建立金豆支付模块与其他非支付模块或组件之间的通信连接，从而在后续实际业务过程中完成相互之间的数据传输和业务调用。

作为本发明的一种示例，在构建包括金豆支付的业务场景时，可以在该业务场景对应代码中添加金豆支付按钮对应的代码段，实现对金豆支付的调用。

例如，若希望在商城中添加金豆支付，可以在该商城的网页中写入金豆支付的按钮代码段，通过加载该代码段，使得金豆支付的支付按钮或支付二维码可以展现在商城的网页中。当在进行支付时，用户若点击使用金豆支付，商城可以通过金豆支付的标识信息建立与支付系统金豆支付模块之间的通信链路以传输相应的数据，金豆支付模块在接收到上述支付请求后，可以按照预设的业务逻辑，调用对应的模块完成整个支付过程。

另一方面，在开发本实施例的网上支付系统时，还可以提炼出一些有公共价值的模块进行单独设计，分别提供对内对外的数据调用接口，供本系统的其他部件、模块以及其他系统接入使用。

在本发明实施例中，这些公共功能模块可以通过识别在实现多个业务的过程中所使用的相同的业务功能，并对上述相同的业务功能进行模块化开发得到。

当目标功能模块在执行某一支付指令时，可以首先确定执行该支付指令所需的目标公共功能模块，然后可以通过目标公共功能模块的数据调用接口，调用目标公共功能模块共同执行上述支付指令。

即，可以根据各种业务所实现的具体功能确定哪些模块可以单独进行开发。这些有公共价值的模块，通常是在多个不同的业务中均需要使用到的功能。然后，在对各个组件进行模块化设计时，可以将这些功能剥离出来单独设计成一个模块，使得在实现具体业务时，原模块仅需调用这些公共功能模块就能实现完整模块所能实现的功能，进一步降低了模块的开发难度和效率。

例如，可以设计限额限次模块，提供支持多种业务纬度、多种周期的限额限次服务组件，除了能为网上支付系统进行业务支持外，还可以为银行内其他系统提供限额限次服务，如限额限次动态设置、试算等等。

可以设计支付路由模块，提供可根据不同支付方式、通道费率、稳定性等因素动态路由，组合支付拆分串行或者并行支付的组件。在该模块张，路由支持随机、权重、人工等方式，路由因子可以包括转入转出帐号类型、通道费率、到账时效性、通道稳定性、通道成功率等等。

可以设计清算中心模块，提供和商户之间的结算服务，可受理网上支付系统及银行内其他系统的清算数据，支持文件受理、消息受理、联机受理等多种受理方式。清算可以支持工作日、自然日、实时、分时等多种结算方式，清算对象也可以支持包括行内行外，对公对私帐号等等。

在本发明实施例中，通过在接入层中整合多种接口类型，用于分别对应不同的支付载体，在适配层中集合与多种支付渠道相适配的多种业务协议，在核心层中配置多种功能模块，由各个功能模块分别实现一项或多项业务功能，然后基于上述接入层、适配层和核心层构成网上支付系统。本实施例通过将系统架构分层设计，由各层中不同的模块分别实现一项或几项特定的功能，各层各模块之间分工明确，互不影响，降低了各层各模块之间的耦合度。对于某一模块出现的故障，可以针对性地进行排查和解决，不会因为一个模块故障而导致整个系统不可用。其次，当需要在系统中增加某一功能时，可以开发出该功能对应的模块并添加至系统中，当需要执行涉及到与其他模块共同配合才能实现的功能时，可以通过各个模块之间的相互调用完成，不仅方便了业务扩展，也能够实现对业务需求的快速响应，减少了新业务的开发时间及上线等待时间，降低了系统的设计复杂度，减少了运营维护的成本。

参照图3，示出了本发明一个实施例的一种网上支付方法的步骤流程示意图，该方法可以应用于网上支付系统，上述网上支付系统可以包括接入层、适配层和核心层。其中，接入层可以包括多种接口类型，任一接口类型可以分别对应不同的支付载体，适配层可以集合有与多种支付渠道相适配的多种业务协议，核心层可以包括多个功能模块，任一功能模块可以分别实现一项或多项业务功能；上述方法具体可以包括如下步骤：

s301、所述接入层检测经由任一支付渠道传输的支付指令，识别生成所述支付指令的支付载体，调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至所述适配层及所述核心层；

需要说明的是，本方法可以应用于前述实施例中的网上支付系统中，关于该网上支付系统的详细介绍可以参见前述实施例中的描述，本实施例对此不再赘述。

在本发明实施例中，支付渠道可以是在当前业务场景中的一种具体的支付方式，例如，可以是积分支付、储蓄卡支付、信用卡支付等等，本实施例对此不作限定。

支付渠道可以是与网上支付系统核心层中某一具体的功能模块相对应的。即，该功能模块所实现的功能可以认为即是通过该支付渠道完成支付。

在具体实现中，可以在当前业务场景中配置相应功能模块的数据调用接口代码生成支付渠道。

例如，若希望在网上商城中添加金豆支付，可以在该商城的网页中写入金豆支付的按钮代码段，通过加载该代码段，可以使得金豆支付的支付按钮或支付二维码可以展现在商城的网页中。

用户在使用某一支付渠道时，可以点击该支付渠道的支付按钮，触发生成相应的支付指令，该支付指令将被传输至网上支付系统。

在本发明实施例中，网上支付系统在接收到支付指令后，可以首先由接入层识别该识别支付指令中携带的支付载体的信息，调用接入层中与该支付载体对应的接口，并采用该接口将支付指令传输至适配层和核心层。

s302、所述适配层确定传输所述支付指令的所述支付渠道，为所述核心层提供适配所述支付渠道的目标业务协议；

对于适配层，其在接收到接入层传输的支付指令后，可以通过确定传输该支付指令的支付渠道，为核心层提供适配该支付渠道的目标业务协议。

通常，适配某个支付渠道的目标业务协议可能包括多种。因此，在该支付渠道接入支付系统时，适配层可以根据该渠道所要应用到的多种目标业务协议，预先构建出目标协议集，供后续业务过程中使用。

s303、所述核心层基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

在本发明实施例中，核心层中对应上述支付渠道的目标功能模块可以是具体执行当前的支付指令的模块。

因此，核心层在接收到接入层传输的支付指令时，需要首先确定实现当前的支付渠道的功能模块是哪一个，然后基于适配层所提供的业务协议，调用该模块去执行上述支付指令。

通常，支付指令中应当包括相应的支付金额信息，该金额信息即是本次支付应当付款的具体数额。

需要说明的是，在用户选定使用某一支付渠道进行支付时，可能存在该支付渠道的余额不足的情况，此时，可能需要调用其他支付渠道进行支付。

例如，在目标支付渠道余额不足时，可能需要调用第二支付渠道进行支付，该第二支付渠道与也可以是通过在当前业务场景中配置第二功能模块的数据调用接口代码生成的。

需要说明的是，目标功能模块对应的代码中可以包含有第二功能模块的标识信息，通过运行目标功能模块对应的代码可以建立目标功能模块与第二功能模块之间的通信连接，由目标功能模块与第二功能模块共同构成当前业务场景下的支付部件。

因此，在本发明实施例中，在通过目标功能模块执行支付指令时，可以首先判断该目标支付渠道对应的当前用户的支付账户中的余额信息是否不小于支付指令中的支付金额信息。

若是，则可以直接通过目标功能模块从相应的支付账户中扣减该支付金额信息对应的金额。

若否，则需要确定第二支付账户，该第二支付账户即是与第二支付渠道对应的用户账户。然后，将支付指令传输至与第二支付账户对应的第二功能模块，通过第二功能模块执行上述支付指令。即，通过第二支付账户完成本次支付。

或者，也可以在确定第二支付账户，计算出支付金额信息与目标支付渠道对应的当前用户的支付账户中的余额信息之间的差值，并通过目标功能模块从该支付账户中扣减余额信息对应的金额后，基于上述差值生成第二支付指令，并将第二支付指令传输至与第二支付账户对应的第二功能模块，通过第二功能模块执行第二支付指令。即，由目标支付账户和第二支付账户共同完成本次支付。

为了便于理解，下面结合一个完整的示例，对在前述网上支付系统中开发并上线一种新业务类型并进行支付作一具体的介绍。

以新增金豆支付为例，开发人员只需在现有的支付模式下，开发出支持金豆支付的业务组件，并将该组件与其他现有支付方式进行组合，便可以在多种支付场景中支持金豆支付。

在本发明实施例中，在完成金豆支付组件的开发后，可以首先确定在哪些支付场景中需要增加金豆支付，然后在这些支付场景中添加金豆支付。

具体地，以当前需要支持金豆支付的场景为某一网上商城，即，需要在该网上商城的支付手段中增加金豆支付供用户选择。由于该网上商城可以通过一个统一的数据接口接入网上支付系统，实现与网上支付系统之间的数据调用，因此，在开发出金豆支付组件后，也可以将金豆支付对外的数据接口接入接入层，并通过接入层实现网上商城与金豆支付组件之间的数据对接。

与此同时，在完成网上商城与金豆支付组件之间的数据对接后，网上商城对应结算页的页面中便会出现金豆支付的选项。即，用户在选购商品点击结算按钮进入支付页面后，可以看到金豆支付选项，并能够通过选择金豆支付进行购物结算。

若用户选择金豆支付，支付系统可以首先通过查询当前用户的金豆账户，确认用户可用于支付的金豆数量。此时，支付系统分两种情况对支付过程进行处理。

一种是用户可用于支付的金豆数量完全满足当前所选购的商品的价格。例如，若当前用户选购的商品价格为100元，用户可用金豆数量为3000个，按照20金豆兑换1元的比例，该商品需要支付金豆2000个。支付系统可以直接将需要结算的金豆数量利用消息推送至清算组件，清算组件在接收到消息后，可以从当前用户的金豆账户中扣减金豆2000个，完成支付过程。

另一种是用户可用于支付的金豆数量不能完全满足当前所选购的商品的价格。例如，在完成上述支付后，用户可用金豆数量剩余1000个，若用户再次选购一件价格为80元的商品并选用金豆支付，由于剩余的1000个金豆无法完全满足商品的价格(需80元*20金豆/元＝1600金豆)，支付系统首先可以将支付消息推送至费用组件，费用组件在接收到消息后，可以首先根据业务规则进行分配，确定在当前支付过程中需使用金豆支付1000个(50元)，除此之外，还需使用其他支付手段支付剩余的30元。支付系统可以将费用组件确定的支付方式展示给用户选择，若用户同意按此进行支付，一方面，支付系统可以将支付1000个金豆的消息推送至金豆支付组件完成金豆支付，另一方面，还需要将支付剩余30元的消息推送至其他支付组件进行支付，从而完成整个支付过程。

在本发明实施例中，由于支付组件和清算组件不耦合，新增金豆支付业务，只需要将需要参与结算的金豆数据利用消息推送到相应的清算组件，便可以轻松解决清算问题。至于费用，在支付时若有分账需求，可预先将涉及的费用数据通过消息推送至费用组件，统一由费用组件按业务规则进行处理，不与其他模块耦合。

本实施例通过对支付系统的架构进行分层分模块设计，可以降低各业务各模块之间的耦合度，对于新扩展业务，可以通过模块化设计直接添加至系统中，实现新业务的快速上线。当某一模块出现故障时，运维人员可以直接对该模块进行修复，不会出现因为一个模块的故障影响整个支付系统运行的事件。

需要说明的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

参照图4，示出了本发明一个实施例的一种网上支付装置的示意图，应用于网上支付系统，所述网上支付系统包括接入层、适配层和核心层，所述接入层包括多种接口类型，任一接口类型分别对应不同的支付载体，所述适配层集合有与多种支付渠道相适配的多种业务协议，所述核心层包括多个功能模块，任一功能模块分别实现一项或多项业务功能；所述装置具体可以包括如下模块：

支付指令检测模块401，用于检测经由任一支付渠道传输的支付指令；

支付载体识别模块402，用于识别生成所述支付指令的支付载体；

接口调用模块403，用于调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至业务协议确定模块及支付指令执行模块；

业务协议确定模块404，用于确定传输所述支付指令的所述支付渠道，为所述支付指令执行模块提供适配所述支付渠道的目标业务协议；

支付指令执行模块405，用于基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

参照图5，示出了本发明一个实施例的一种服务器的示意图。如图5所示，本实施例的服务器500包括：处理器510、存储器520以及存储在所述存储器520中并可在所述处理器510上运行的计算机程序521。所述处理器510执行所述计算机程序521时实现上述网上支付方法各个实施例中的步骤，例如图3所示的步骤s301至s303。或者，所述处理器510执行所述计算机程序521时实现上述各装置实施例中各模块/单元的功能，例如图4所示模块401至405的功能。

示例性的，所述计算机程序521可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器520中，并由所述处理器510执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段可以用于描述所述计算机程序521在所述服务器500中的执行过程。例如，所述计算机程序521可以被分割成支付指令检测模块、支付载体识别模块、接口调用模块、业务协议确定模块、支付指令执行模块，各模块具体功能如下：

支付指令检测模块，用于检测经由任一支付渠道传输的支付指令；

支付载体识别模块，用于识别生成所述支付指令的支付载体；

接口调用模块，用于调用所述支付载体对应的接口，通过所述接口将所述支付指令传输至业务协议确定模块及支付指令执行模块；

业务协议确定模块，用于确定传输所述支付指令的所述支付渠道，为所述支付指令执行模块提供适配所述支付渠道的目标业务协议；

支付指令执行模块，用于基于所述目标业务协议，调用与所述支付渠道相对应的目标功能模块，采用所述目标功能模块执行所述支付指令。

所述服务器500可以是云端服务器等计算设备。所述服务器500可包括，但不仅限于，处理器510、存储器520。本领域技术人员可以理解，图5仅仅是服务器500的一种示例，并不构成对服务器500的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器500还可以包括输入输出设备、网络接入设备、总线等。

所述处理器510可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器520可以是所述服务器500的内部存储单元，例如服务器500的硬盘或内存。所述存储器520也可以是所述服务器500的外部存储设备，例如所述服务器500上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等等。进一步地，所述存储器520还可以既包括所述服务器500的内部存储单元也包括外部存储设备。所述存储器520用于存储所述计算机程序521以及所述服务器500所需的其他程序和数据。所述存储器520还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制。尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。