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

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

背景技术：

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

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

技术实现要素：

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

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

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

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

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

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

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

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

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

若能，所述分别冻结所述客户端账户内的资金余额和授信贷款额度，使得冻结总额大于或等于所述支付金额；生成承载所述资金管理服务器所有名义的电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付。

根据本发明的又一个方面，提供的一种基于同一资金服务器的支付装置，所述装置包括接收模块、判断模块和处理模块，其中：

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

判断模块，设置为根据所述客户端资金余额和授信贷款额度和所述支付金额判断是否允许支付；

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

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

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

附图说明

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

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

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

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

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

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

具体实施方式

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

实施例一

如图1所示，本发明实施例提供的一种基于同一资金服务器的支付系 统，该系统包括至少一个客户端10、至少一个商户端20和资金管理服务器30，资金管理服务器30分别与客户端10和商户端20连接，其中：

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

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

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

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

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

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

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

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

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

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

具体地，资金管理服务器30还可以根据电子承诺支付凭证信息的状态进一步确定是否划款操作，即请求支付只是冻结资金余额和授信贷款额度，确认签收后再进行划款和扣减授信贷款额度。

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

实施例二

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

S201、资金管理服务器接收客户端发送的支付请求信息，支付请求信息至少包括支付金额。

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

S202、将客户端的资金余额和授信贷款额度之和与支付金额进行比较，判断能否生成电子承诺支付凭证予以支付，如果允许，则进入支付过程，否则终止本次支付。可以理解地，本实施例中，资金余额通常存放在借记卡内，所述授信贷款额度通常与征信匹配。。

本步骤进一步包括：资金管理服务器从数据库中查询客户端的账户资金余额和授信贷款额度；判断资金余额和授信贷款额度之和是否大于或等于支付金额，如果是，则允许本次支付；否则终止本次支付。其中，客户端的银行账号和信用卡账号可以是客户端在支付请求信息中告知资金管理服务器的，也可以资金管理服务器根据客户端ID从数据库中查询的，从而获取对应账户的资金余额和授信贷款额度。只有在客户端账户内的资金余额和授信贷款额度之和大于或等于支付金额时，才表示客户具有支付能力，此时才允许进行支付行为。如此，可以节省付款周期，保障商家的利益。

S203、资金管理服务器分别冻结客户端账户内的支付金额对应的资金余额和授信透支额度，使得冻结总额大于或等于所述支付金额；

本方案中通过分别冻结资金余额和授信贷款额度，使得冻结总额大于或等于所述支付金额；以确保后继有足够的资金完成本次交易，但不并直接划款到商户账号，这样保障了买卖双方的利益，后继可以由客户端、商 户端或者物流公司发送解付信息确认交付完成，由资金管理服务器在接收到解付信息后，扣减授信贷款额度，并将相应的资金解冻并划拨到到商户端的账户内。

S204、资金管理服务器生成电子承诺支付凭证，并发送给商户端；

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

S205、将电子承诺支付凭证发给商户端替客户端进行并同步到商户端或客户端。以便后继跟踪。

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

实施例三

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

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

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

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

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

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

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

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

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

S304、资金管理服务器生成电子承诺支付凭证；

S305、将电子承诺支付凭证信息发送给商户端；

S306、商户端向资金管理服务器发送接收解付信息；

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

S307、资金管理服务器将解付信息同步到商户端或客户端。

具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到商户端或客户端，从更新的电子承诺支付凭证信息可以即时获知商品的流转状态，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。

S308、将与所述冻结额度对应的资金划拨到商户端的账号内。可以理解，根据S303步骤中不同的冻结方法方式，将有相应配套的资金划拨方案，将对应的资金划拨到商户端的账户内。。

S309、结束流程。

本发明实施例提供的一种支付方法，通过资金管理服务器接收客户端的支付请求信息，根据买方的资金余额和授信贷款额度判断是否允许支付，同时通过分别冻结客户端账户的资金余额和授信贷款额度，使得冻结总额大于或等于所述支付金额，并生成电子承诺支付凭证进行实时监控，能降低资金风险，保障买卖双方的利益。

实施例四

如图4所示，本发明实施例提供的另一种支付方法，应用于图1所示的基于同一资金服务器的支付系统，该方法包括以下步骤：

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

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

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

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

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

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

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

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

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

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

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

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

S404、向客户端询问是否需要发放授信透支额度；如果需要授信透支额度，则执行步骤S405，否则转至步骤S411；

S405、判定所述授信透支额度是否充足；此处的充足可以理解有几种情形：

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

2、授信透支额度大于或等于所述支付金额的额度时，则认为所述授信透支额度充足，反之，不充足。

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

S406、资金管理服务器分别冻结客户端账户内的资金余额和授信贷款额度和授信透支额度，使得冻结总额大于或等于所述支付金额之后，将生成电子承诺支付凭证；

S407、将电子承诺支付凭证信息发送给商户端；

S408、商户端向资金管理服务器发送接收解付信息；

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

S409、资金管理服务器将解付信息同步到商户端或客户端。

具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到商户端或客户端，从更新的电子承诺支付凭证信息可以即时获知商品的流转状态，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。

S410、将与所述冻结额度对应的资金划拨到商户端的账号内。可以理解，根据S403步骤中不同的冻结方式，将有相应配套的资金划拨方案，将对应的资金划拨到商户端的账户内。

S411、结束流程。

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

实施例五

如图5所示，本发明实施例提供的一种支付装置，包括接收模块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还可以包括划款单元，设置为接收到解付信息后，将解付信息同步到商户端或客户端，并将冻结的相应资金划拨到商户端的账户内。

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

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

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

实施例六

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

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

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

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

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

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

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

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

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

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

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

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