基于跨资金服务器的支付系统及其支付方法、装置和服务器与流程

本发明涉及电子商务领域，尤其涉及一种基于跨资金服务器的支付系统及其支付方法、装置和服务器。

背景技术：

电子商务已越来越广泛地应用于各种商业贸易活动中，所谓电子商务是指在商业贸易活动中，在因特网开放的网络环境下，基于浏览器及服务器应用方式，实现消费者的网上购物、商户之间的网上交易和在线电子支付以及各种商务活动、交易活动、金融活动和相关的综合服务活动的一种商业运营模式。

目前，很多银行或者企业都提供了网络支付的服务，允许客户操作计算机、手机等终端设备来实现网络支付，网络支付的方式为客户提供了很大的便利。而网络支付的过程中，多为使用借记卡内的现有资金或信用卡直接支付，或将现有资金或信用卡内的信用额度直接划拨到第三方机构作为担保进行交易，一旦商户未提供商品或服务时有或者发生客户争议时，资金安全难以得以保证。由此可见，现阶段需要新的支付系统、方法、装置和服务器，以降低用户资金风险，保障买卖双方的利益。

技术实现要素：

有鉴于此，本发明要解决的技术问题是提供一种基于跨资金服务器的支付系统及其支付方法、装置和服务器，以降低用户资金风险，保障买卖双方的利益。

本发明解决上述技术问题所采用的技术方案如下：

一种基于跨资金服务器的支付系统，包括至少一个客户端、至少一个商户端、信息中心服务器与客户端连接的第二资金管理服务器和与商户端连接的第一资金管理服务器，所述第一资金管理服务器和第二资金服务器 连接并分别与所述信息中心服务器连接，其中：

所述客户端，用于向所述第二资金管理服务器发送至少包括有支付金额的支付请求信息；

所述商户端，用于接收所述第二资金管理服务器发送的电子承诺支付凭证；

第二资金管理服务器，用于接收所述客户端发送的支付请求信息；比较客户端授信透支额度和授信贷款额度之和与支付金额，判断能否生成电子承诺支付凭证予以支付；若能，第二资金管理服务器分别冻结所述客户端账户内的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额，生成由所述第二资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，并将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支付凭证信息同步到所述信息中心服务器；

所述第一资金管理服务器，用于存储所述第二资金管理服务器发送的所述电子承诺支付凭证信息，并根据所述电子承诺支付凭证信息，将接收到的所述支付金额划拨到所述商户端的账户中；

信息中心服务器，用于存储并监管所述电子承诺支付凭证信息。

根据本发明的另一个方面，提供的一种基于跨资金服务器的网络支付方法，该方法包括以下步骤：

第二资金管理服务器接收客户端发送的支付请求信息，其中，支付请求信息至少包括支付金额；

比较所述客户端授信透支额度和授信贷款额度之和与所述支付金额，判断能否生成电子承诺支付凭证予以支付；

若能，所述分别冻结所述客户端账户内的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额；生成由第二资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支 付凭证信息同步到信息中心服务器。

一种基于跨资金服务器的支付装置，所述装置包括接收模块、判断模块和处理模块，其中。

接收模块，设置为接收客户端发送的支付请求信息，其中，所述支付请求信息包括支付金额；

判断模块，设置为比较所述客户端授信透支额度和授信贷款额度之和与所述支付金额，判断能否开出电子承诺支付凭证；

处理模块，设置为当允许支付时，分别冻结所述客户端账户内的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额；生成电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。

一种基于跨资金服务器的服务器，所述服务器包括上述任意一项权利要求所述的支付装置。

本发明提供的基于跨资金服务器的支付系统及其方法、装置和服务器，通过资金管理服务器和信息中心服务器对买卖双方的信息进行监管，将监管功能合并到银行或其他具备信用支付能力的机构；同时通过分别冻结客户端账户的授信透支额度和授信贷款额度，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益；此方案充分利用了资金管理服务器的信用中枢和信息中心服务器的风控中心功能，以更加优化的信用机制促进网络交易和保障交易资金安全，为交易双方提供了信用媒介，还通过对资金的监管能降低资金风险，保障交易双方的利益。此外，还通过增加贷款功能方便了客户，也丰富了银行或其他具备信用支付能力的机构的业务。

附图说明

图1为本发明实施例一提供的一种基于跨资金服务器的支付系统的示意图；

图2为本发明实施例二提供的一种基于跨资金服务器的支付方法的流 程图；

图3为本发明实施例三提供的一种基于跨资金服务器的支付方法的流程图；

图4为本发明实施例四提供的一种基于跨资金服务器的支付装置的模块结构图；

图5为本发明实施例五提供的一种基于跨资金服务器的支付系统的模块结构图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚、明白，以下结合附图和实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例一

如图1所示，本发明实施例提供的一种基于跨资金服务器的支付系统，该系统包括至少一个客户端10、至少一个商户端20，信息中心服务器50以及相互连接的第一资金管理服务器30和第二资金管理服务器40，其中：

客户端10，与第二资金管理服务器40相连接，用于向第二资金管理服务器40发送支付请求信息，其中支付请求信息包括支付金额。

具体地，客户端10适用于付款方(买方)，包括手机、个人电脑、PAD等智能设备，客户端10的账户信息是用户注册时填写，并存储在资金管理服务和/或信息中心服务器的数据库中的，客户端10的账户信息包括用户ID、开户银行、账户名称、银行账号、信用额度等信息，还可以包括客户的收货/服务地址信息。支付请求信息是在用户选择购买具体的商品/服务后，填写/确认收货/服务地址等信息，客户端10按预设的规则根据商品/服务的价格、商品/服务所属的商户生成的数据包，将该数据包发送给第二资金管理服务器40。支付请求信息至少包括支付金额，还可以包括商户信息和商品信息。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息(如商户ID)，由第二资金管理服务器40根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端20的账户信息相对客户端10应该是保密的，故商户信息优选为商户ID，第二资金管理服务器40利用商户ID与其收款账号存在对应的关系来查询商户的收 款账号。也就是说，客户端10只需告知第二资金管理服务器40向哪个商户的哪个商品支付多少款项，第二资金管理服务器40便能调出商户的账号实现支付。

商户端20，与第一资金管理服务器30相连接，用于接收第二资金管理服务器40发送的电子承诺支付凭证。

具体地，商户端20适用于收款方(卖方)，商户端包括但不限于服务器、POS机等设备。商户包括但不限于生产制造商、代理商、物流公司等。商户信息也是用户开户时进行注册并存储在资金管理服务器和/或信息中心服务器的数据库中的，商户信息包括但不限于商户ID、商户名称、商户开户银行、商户账户名称、商户银行账号等信息。商户端20接收第二资金管理服务器40发送的电子承诺支付凭证后，通过提取电子承诺支付凭证信息中的商品信息和收货信息，将指定商品发送目的地。

第二资金管理服务器40，用于接收客户端10发送的支付请求信息；将客户端10的授信透支额度和授信贷款额度与支付金额进行比较，判断能否开出电子承诺支付凭证；如果允许支付，则冻结客户端账户内支付金额对应的授信透支额度和授信贷款额度，生成由所述第二资金管理服务器40承诺按约定条件解付资金的电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端20，并同步到信息中心服务器50。

具体地，第二资金管理服务器40接收到支付请求信息的数据包后，按预设的规则进行解析，获取相关支付信息，相关支付信息包括但不限于商户信息、商品信息和支付金额等必要信息，即向哪个商户的哪个商品支付多少款项。第二资金管理服务器40查询客户账户的银行授信透支额度和授信贷款额度之和是否足够本次结算，如果不足，则终止本次支付，如果充足，则分别冻结支付金额相应的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额，待商户确认发货或者客户确认签收后进行划款操作完成交易。

可以理解，该处分别冻结支付金额相应的授信透支额度和授信贷款额度包括以下几种情形：

一、仅冻结授信透支额度，使得冻结总额大于或等于所述支付金额。

二、仅冻结授信贷款额度，使得冻结总额大于或等于所述支付金额。

三、分别冻结部分客户端账户内的授信透支额度和授信贷款额度，使 得冻结总额大于或等于所述支付金额。

信息中心服务器50，分别与第一资金管理服务器30和第二资金管理服务器40连接，用于存储并监管客户端10和商户端20的电子承诺支付凭证信息。

具体地，客户端10和商户端20都可以通过互联网向信息中心服务器50获取电子承诺支付凭证信息以便后继的处理，比如利用该数据进行双通道的验证信息的正确与否。第二资金管理服务器40还可以根据电子承诺支付凭证信息的状态进一步确定是否划款操作，即请求支付只是冻结授信透支额度和授信贷款额度，确认签收后再进行划款和扣减授信透支额度。

在本实施例中，第二资金管理服务器40，还可同时与多个客户端10和通过互联网连接。第一资金管理服务器30，还可同时与多个商户端20和通过互联网连接。即商户端20账户所在的服务器与客户端10所在的服务器不在同一服务器上。第二资金管理服务器40和第一资金管理服务器30，可以为物理意义上的单一服务器，也可以为物理意义上的多台服务器，如多台物理服务器并行工作，根据业务量的不同，自动分配服务器的资源，共同实现资金管理。第二资金管理服务器40和第一资金管理服务器30包括但不限于银行、企业等组织中的服务器。实际应用中，可以理解为同一银行的集群资金管理服务器，但并不局限于银行，还可以能在互联网中支持资金流动的其它机构，亦或是其他具备信用支付能力的机构，也就是通常说的第三方机构。通过资金管理服务器和信息中心服务器对买卖双方的信息进行监管，将监管功能合并到银行或其它具备信用支付能力的机构。

实施例二

如图2所示，本发明实施例提供的一种基于跨资金服务器的支付方法，应用于资金管理服务器，该方法该包括以下步骤：

S201、客户端向第二资金管理服务器发送支付请求信息，支付请求信息包括支付金额。

具体地，第二资金管理服务器接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息(如客户ID)。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息(如商户ID)，由第二资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账 号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，第二资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知第二资金管理服务器向哪个商户的哪个商品支付多少款项，第二资金管理服务器便能调出商户的账号实施相应的支付操作。

S202、第二资金管理服务器接收客户端发送支付请求信息；

S203、查询客户端账户的授信透支额度和授信贷款额度之和，将所述授信透支额度和授信贷款额度之和与支付金额比较，若大于等于，则说明充足，若小于，则说明不充足。当授信透支额度和授信贷款额度充足时，执行步骤S204，否则结束，不予支付；

S204、第二资金管理服务器分别冻结客户端账户内的支付金额对应的授信透支额度和授信贷款额度；可以理解，该处分别冻结支付金额相应的授信透支额度和授信贷款额度包括以下几种情形：

1、仅冻结授信透支额度，使得冻结总额大于或等于所述支付金额。

2、仅冻结授信贷款额度，使得冻结总额大于或等于所述支付金额。

3、分别冻结部分客户端账户内的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额。

S205、第二资金管理服务器根据支付请求信息和冻结信息生成电子承诺支付凭证，并发送给商户端；

具体地，由于支付请求信息是买方通过客户端操作发送给第二资金管理服务器的，其支付信息客观上是得到了客户确认并授权银行支付的。第二资金管理服务器冻结相应的资金，同时将生成根据支付信息生成电子承诺支付凭证，商户端根据该电子承诺支付凭证提供相应的商品/服务。

S206、第二资金服务器将电子承诺支付凭证发送给商户端，并同步到信息中心服务器和第一资金管理服务器。具体地，本步骤将生成的电子凭证信息发送给信息中心服务器，以便信息中心服务器进行后继跟踪。

S207、第二资金管理服务器接收解付信息；

S208、第二资金管理服务器将与所述冻结额度对应的资金划拨到第一资金管理服务器；

S209、第一资金管理服务器将接收到的支付金额划款到商户端的账户内。

本发明实施例提供的支付方法，通过第二资金管理服务器接收客户端的支付请求信息，根据客户端账户授信透支额度和授信贷款额度之和判断是否允许支付，同时通过分别冻结客户端账户内的授信透支额度和授信贷款额度，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。

实施例三

如图3所示，本发明优选实施例提供的一种授信透支额度和授信贷款额度的支付方法，应用于图1所示的基于跨资金服务器的支付系统，该方法包括以下步骤：

S301、客户端向第二资金管理服务器发送支付请求信息，支付请求信息至少包括支付金额。

其中，支付请求信息由多个数据包组成，至少包括商户信息、商品信息和支付金额。还可以包括客户端信息(如客户ID)。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息(如商户ID)，由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。

客户端向第二资金管理服务器发送支付请求信息的方式可以采用现有的方式进行，比如采用数字签名或者数字信封的方式发送。数字签名是指用户用自己的私钥对原始数据的哈希摘要进行加密所得的数据。信息接收者使用信息发送者的公钥对附在原始信息后的数字签名进行解密后获得哈希摘要，并通过与自己用收到的原始数据产生的哈希摘要对照，便可确信原始信息是否被篡改。这样就保证了数据传输的不可否认性。数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。数字信封中采用了单钥密码体制和公钥密码体制。信息发送者首先利用随机产生的对称密码加密信息，再利用接收方的公钥加密对称密码，被公钥加密后的对称密码被称之为数字信封。在传递信息时，信息接收方要解密信息时，必 须先用自己的私钥解密数字信封，得到对称密码，才能利用对称密码解密所得到的信息。这样就保证了数据传输的真实性和完整性。

S302、资金管理服务器接收客户端发送的支付请求信息

具体地，第二资金管理服务器接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息(如客户ID)。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息(如商户ID)，由第二资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，第二资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知第二资金管理服务器向哪个商户的哪个商品支付多少款项，第二资金管理服务器便能调出商户的账号实施相应的支付操作。

S303、查询客户端账户的授信透支额度和授信贷款额度之和，将所述授信透支额度和授信贷款额度之和与支付金额比较，若大于等于，则说明充足，若小于，则说明不充足。当授信透支额度和授信贷款额度充足时，执行步骤S305，否则，执行步骤S304；；

S304、向客户端询问是否使用资金余额；如果需要使用资金余额，则执行步骤S305，否则结束流程；

S305、判定所述资金余额是否充足；此处的充足可以理解有几种情形：

1、客户端账户内的授信透支额度和授信贷款额度以及部分使用资金余额之和大于或等于所述支付金额的额度时，则认为所述使用资金余额充足，反之，不充足；

2、使用资金余额大于或等于所述支付金额的额度时，则认为所述使用资金余额充足，反之，不充足。

具体地，使用资金余额可以是客户端指定的金额，也可以默认为本次支付欠缺的金额。例如，当客户选择的一件商品的价格是1500元(支付金额)时，假如客户账户内的授信透支额度和授信贷款额度只有900元时，则需要使用资金余额600元，才能达到允许支付标准，进行支付行为。当然，采用另外一种方式，如直接申请使用资金余额1500元，进行支付，也是可行的。

S306、第二资金管理服务器分别冻结客户端账户内的授信透支额度和 授信贷款额度和资金余额，使得冻结总额大于或等于所述支付金额，具体可分为以下几种形式：

1、仅冻结客户端账户内的资金余额，使得冻结总额大于或等于所述支付金额。

2、仅冻结授信贷款额度，使得冻结总额大于或等于所述支付金额。

3、仅冻结授信透支额度，使得冻结总额大于或等于所述支付金额。

4、分别冻结部分客户端账户内的部分资金余额与部分授信贷款额度，使得冻结总额大于或等于所述支付金额。

5、分别冻结部分客户端账户内的部分资金余额与部分授信透支额度，使得冻结总额大于或等于所述支付金额。

6、分别冻结部分客户端账户内的部分部分授信贷款额度与部分授信透支额度，使得冻结总额大于或等于所述支付金额。

7、分别冻结部分客户端账户内的授信透支额度与授信贷款额度以及资金余额，使得冻结总额大于或等于所述支付金额。

S307、第二资金管理服务器根据支付请求信息和冻结信息生成电子承诺支付凭证；

具体地，由于支付请求信息是买方通过客户端操作发送给第二资金管理服务器的，其支付信息客观上是得到了客户确认并授权银行支付的。第二资金管理服务器分别冻结相应的资金余额或授信贷款额度或授信透支额度，同时将生成根据支付信息生成电子承诺支付凭证，商户端根据该电子承诺支付凭证提供相应的商品/服务。

S308、第二资金服务器将电子承诺支付凭证发送给商户端，并同步到信息中心服务器和第一资金管理服务器。具体地，本步骤将生成的电子凭证信息发送给信息中心服务器，以便信息中心服务器进行后继跟踪。

S309、第二资金管理服务器接收解付信息；需要说明的是，本步骤S408中，商户端向资金管理服务器发送接收解付信息仅仅是一种举例，实际应用中，还可以由客户端、物流服务器或者其他能够获知交付状态的实体向资金管理服务器发送解付信息。

S310、第二资金管理服务器将与所述冻结额度对应的资金划拨到第一资金管理服务器；可以理解，根据S306步骤中不同的冻结方式，将有相应配套的资金划拨方案，将对应的资金划拨到商户端的账户内。

S311、第一资金管理服务器将接收到的支付金额划款到商户端的账户。

最后，结束流程。

本发明实施例，在实施例二的基础上，通过增加授信透支额度功能，不仅方便了买方，而且极大丰富了银行或其他具备信用支付能力的机构的业务；此外，还通过增加信息中心服务器对买卖双方的电子承诺支付凭证进行同步跟踪，将商品的流转轨迹和资金的流转轨迹有效的结合，使得买卖双方的权益均能得到有效保护。

实施例四

如图4所示，本发明实施例提供的一种支付装置，包括接收模块301、判断模块302、处理模块303，其中：

接收模块301，设置为接收客户端发送的支付请求信息，其中，支付请求信息包括支付金额。

具体地，接收模块301接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息(如客户ID)。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息(如商户ID)。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，由本装置调出商户的账号实施相应的支付操作。

判断模块302，设置为根据客户端授信透支额度和授信贷款额度和支付金额判断是否允许支付。

作为一种优选的方案，判断模块302具体设置为：查询客户端的账户授信透支额度和授信贷款额度；判断客户端账户的授信透支额度和授信贷款额度是否大于或等于支付金额时，如果是，则允许支付。如此，先判断账户授信透支额度和授信贷款额度之和的支付能力，优先采用账户授信透支额度和授信贷款额度支付的方式，可以节省付款周期，保障商家的利益。其中，客户端的银行账号或者信用卡账号可以是客户端在支付请求信息中告知本装置的，也可以是本装置根据客户端信息从数据库中查询的，获取对应账户授信透支额度和授信贷款额度。只有在客户端的授信透支额度和授信贷款额度大于或等于支付金额时，才表示客户具有进行支付行为的能力，此时才允许进行支付行为。

作为另一种优选实施例，判断模块302还设置为：当客户端账户的授信透支额度和授信贷款额度之和小于支付金额时，向客户端询问是否需要使用资金余额；如果需要使用资金余额，则向客户端账户申请使用资金余额，允许本次支付；如果不需要，则终止本次支付。这样，不仅方便了买方，也丰富了银行或者其他具备信用支付能力的机构的业务。当采用资金管理服务器根据客户信息获取银行账号或信用卡账号时，一个客户可能有多个账号，还可以采用混合支付方式。例如，当客户选择的一件商品的价格是1500元(支付金额)时，其授信透支额度和授信贷款额度之和只有900元时，则客户可用于支付的额度共有900元，则无法实施支付行为；假如客户端账户内尚有可使用资金余额600元时，通过申请使用资金余额600元，则拥有1500元的使用额度，便可实施支付行为。

处理模块303，设置为当允许支付时，分别冻结客户端账户内的授信透支额度和授信贷款额度和使用资金余额，使得冻结总额大于或等于所述支付金额；生成电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。

优选地，处理模块303进一步包括冻结单元3031、凭证生成单元3032和同步单元3033，其中：

冻结单元3031，设置为当允许支付时，分别冻结客户端账户内的授信透支额度和授信贷款额度和使用资金余额，使得冻结总额大于或等于所述支付金额；

凭证生成单元3032，设置为生成电子承诺支付凭证；

同步单元3033，设置为将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。

此外，处理模块303还可以包括划款单元，设置为接收到解付信息后，将解付信息同步到信息中心服务器，并将冻结的相应资金划拨到第一资金服务器所在的商户端账户内。

需要说明的是，上述方法实施例二和实施例三的技术特征在本装置均对应适用，这里不再重述。

此外，本发明还提供了一种资金管理服务器，该资金管理服务器包括实施例四中的支付装置，这里不再重述。

本发明实施例的支付装置和服务器，通过接收客户端的支付请求信息，根据买方的授信透支额度和授信贷款额度判断是否允许支付，同时通过分别冻结客户端账户的授信透支额度和授信贷款额度，使得冻结总额大于或等于所述支付金额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。此外，还通过增加授信贷款额度功能，不仅方便了买方，而且极大丰富了银行或其他具备信用支付能力的机构的业务。

实施例五

如图5所示，本发明优选实施例提供的一种基于跨资金服务器的支付系统，该系统包括客户端10、商户端20和与客户端10连接的第二资金管理服务器40，和与商户端20连接的第一资金管理服务器30，其中：

客户端10，包括支付请求模块101，设置为向第二资金管理服务器40发送支付请求信息，其中，支付请求信息包括：商户信息、商品信息和支付金额。

商户端20，包括凭证接收模块201和凭证更新模块202,其中，凭证接收模块201设置为接收第二资金管理服务器40发送的电子承诺支付凭证。

第二资金管理服务器40包括接收模块301、判断模块302、和处理模块303，其中：

接收模块301，设置为接收客户端发送的支付请求信息；

判断模块302，设置为比较客户端授信透支额度和授信贷款额度之和与支付金额，判断能否开出电子承诺支付凭证；

作为一种优选实施例，判断模块302设置为：判断客户端账户的授信透支额度和授信贷款额度是否大于或等于支付金额时，如果是，则允许支付；否则进一步判断客户端账户的可使用资金余额是否大于或等于支付金额，如果是，则允许支付。

处理模块303，设置为当允许支付时，冻结客户端账户内的支付金额对应的额度；生成电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。

作为一种优选实施例，第二资金管理服务器40的接收模块301还设置为接收解付信息；处理模块303还包括划款模块，设置为接收到解付信息后，将解付信息同步到信息中心服务器，并将冻结的相应资金划拨到商户端的账户内。

具体地，由于支付请求信息是买方通过客户端10操作发送给第二资金管理服务器40的，其支付信息客观上是得到了客户端10确认并授权银行支付的。第二资金管理服务器40分别冻结相应的授信透支额度和授信贷款额度，同时将生成根据支付信息生成电子承诺支付凭证，电子承诺支付凭证信息包括但不限于商品信息、支付金额(冻结资金或授信透支额度或授信贷款额度)、交货地址和有效期，其形式不限于文本、图片、图形码等。该电子凭证作为商户端20的接收资金的凭证，商户端20根据该电子承诺支付凭证提供相应的商品/服务。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来控制相关的硬件完成，所述的程序可以在存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘、光盘等。

以上参照附图说明了本发明的优选实施例，并非因此局限本发明的权利范围。本领域技术人员不脱离本发明的范围和实质内所作的任何修改、等同替换和改进，均应在本发明的权利范围之内。