CN101937538A - 一种支付方法、系统及设备 - Google Patents
一种支付方法、系统及设备 Download PDFInfo
- Publication number
- CN101937538A CN101937538A CN2009100867862A CN200910086786A CN101937538A CN 101937538 A CN101937538 A CN 101937538A CN 2009100867862 A CN2009100867862 A CN 2009100867862A CN 200910086786 A CN200910086786 A CN 200910086786A CN 101937538 A CN101937538 A CN 101937538A
- Authority
- CN
- China
- Prior art keywords
- client
- payment
- bank server
- transaction information
- goods
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
本发明公开了一种支付方法、系统及设备,该方法包括:银行服务器分别与第一客户端和第二客户端签约;所述银行服务器获取所述第一客户端与所述第二客户端之间的交易信息;所述银行服务器判断所述第一客户端履行所述交易信息完毕时,根据所述签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款;所述银行服务器向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数。本发明实施例通过银行服务器作为中介,完成商品的交付和货款的支付,提高了商品交易的成功率,减小了商品交易的风险,降低了商品交易的成本。
Description
技术领域
本发明涉及信息技术领域,特别是涉及一种支付方法、系统及设备。
背景技术
支付方式按使用的技术不同,可以分为传统支付方式和电子支付方式两种;按流通形态的不同,可以分为开放式支付和封闭式支付两种。传统支付是指通过现金流转、票据转让以及银行转账等物理实体的流转来实现款项支付的方式,电子支付是指通过先进的通信技术和可靠的安全技术实现的款项支付结转方式;开放式支付是指支付方式所代表的价值信息可以在主体之间无限传递下去,封闭式支付是指价值信息只能在有限的主体间进行传递。
随着互联网和计算机网络技术的发展,基于信息技术的交易方式突破了时间和空间的限制,改变了传统的商业活动模式,但同时也带来了商业活动的信任危机和电子交易安全性问题的巨大风险。在电子支付模式中,单位或个人通过电子终端,直接或间接向银行业金融机构发出支付指令,实现货币支付与资金转移。目前,国内存在的电子支付模式大致包括以下四种:
(1)支付网关模式,该模式为电子支付产业中发展最成熟的一种模式,包括银行和第三方支付公司提供的在线支付。支付网关是银行金融网络系统和Internet(因特网)网络之间的接口,是由银行操作的将Internet上传输的数据转换为金融机构内部数据的一组服务器设备。支付网关可确保交易在Internet用户和交易处理商之间安全、无缝的传递,并且无需对原有主机系统进行修改,可以处理所有Internet支付协议、Internet安全协议、交易交换、信息及协议的转换以及本地授权和结算处理。另外,支付网关还可以通过设置来满足特定交易处理系统的要求。
在支付网关模式中,支付网关将Internet传来的数据包解密,并按照银行系统内部的通信协议将数据重新打包;接收银行系统内部的传回来的响应消息,将数据转换为Internet传送的数据格式,并对其进行加密,完成通信、协议转换和数据加解密功能,以保护银行内部网络的安全。
(2)电话支付模式,该模式为电子支付的一种线下实现形式,是指消费者使用电话(固定电话、手机或小灵通)或其他类似电话的终端设备,通过银行系统从个人银行账户里直接完成付款的方式。
(3)移动支付模式,该模式为使用移动设备通过无线方式完成支付行为的一种新型的支付方式,可以使用户随时随地完成付款。移动支付所使用的移动终端可以是手机、PDA(Personal Digital Assistant,个人数码助理)、移动PC(Personal Computer,个人计算机)等设备。
(4)账户支付模式,该模式包括淘宝的支付宝、拍拍网的财付通以及易趣的贝宝等支付方式。
除以上列举的电子交易模式外,为了规避互联网通信的安全风险,交易双方还可以采用传统的货到付款交易模式。交易双方可以事先签订合同,通过合同约束交易双方的行为。卖方在合同规定的商品交付期限内,将商品交付给买方,并在合同规定的付款期限内向买方收取货款。
发明人在实现本发明的过程中,发现现有技术至少存在如下问题:
传统的货到付款交易模式中,存在着交易成本高和卖方无法按时收到货款的问题;现有的电子支付模式实际应用价值相对有限,可用性较低,并且未能解决电子交易风险的问题,在一定程度上存在着安全风险和安全隐患。
发明内容
本发明实施例提供一种支付方法、系统及设备,减小了商品交易的风险,降低了商品交易的成本。
本发明实施例提出一种支付方法,包括:
银行服务器分别与第一客户端和第二客户端签约;
所述银行服务器获取所述第一客户端与所述第二客户端之间的交易信息;
所述银行服务器判断所述第一客户端履行所述交易信息完毕时,根据所述签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款;
所述银行服务器向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数。
其中,所述银行服务器获取第一客户端与第二客户端之间的交易信息之后,还包括:
所述银行服务器根据所述第一客户端和所述第二客户端的信用参数,确定参与所述交易信息对应的支付流程;所述银行服务器向所述第一客户端和所述第二客户端发送商品交付请求。
其中,所述银行服务器判断第一客户端履行交易信息完毕,包括:
所述银行服务器指定第四方认证中心验收所述第一客户端履行所述交易信息的情况;
所述银行服务器接收所述第四方认证中心对所述第一客户端履行所述交易信息的情况的验收报告,根据所述验收报告判断所述第一客户端履行所述交易信息完毕,更新所述第一客户端的信用参数。
其中,所述银行服务器向第二客户端发送货款的支付请求之后,还包括:
所述银行服务器接收所述第二客户端支付的货款;或
所述银行服务器接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
本发明还提供一种支付系统,包括:
银行服务器,用于分别与第一客户端和第二客户端签约,获取所述第一客户端与所述第二客户端之间的交易信息,判断所述第一客户端履行所述交易信息完毕时,根据所述签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款,向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数;
第一客户端,用于与所述第二客户端约定所述交易信息,履行所述交易信息,接收所述银行服务器代替所述第二客户端垫付的所述交易信息中规定的货款;
第二客户端,用于与所述第一客户端约定所述交易信息,接收所述银行服务器发送的所述货款的支付请求,响应所述支付请求。
其中,所述银行服务器,还用于根据所述第一客户端和所述第二客户端的信用参数,确定参与所述交易信息对应的支付流程。
其中,所述银行服务器,还用于向所述第一客户端和所述第二客户端发送商品交付请求。
其中,还包括:
第四方认证中心,用于获取所述银行服务器的授权,验收所述第一客户端履行所述交易信息的情况,根据验收结果生成验收报告,将所述验收报告发送到所述银行服务器;
所述银行服务器,还用于指定所述第四方认证中心验收所述第一客户端履行所述交易信息的情况,接收所述第四方认证中心发送的验收报告,根据所述验收报告更新所述第一客户端的信用参数。
其中,所述银行服务器,还用于接收所述第二客户端支付的货款;或接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
本发明还提供一种银行服务器,包括:
签约模块,用于分别与第一客户端和第二客户端签约;
获取模块,用于获取第一客户端与第二客户端之间的交易信息;
支付模块,用于判断所述第一客户端履行所述交易信息完毕时,根据所述签约模块实现的签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款;
发送模块,用于向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数。
其中,还包括:判断模块,用于根据所述第一客户端和所述第二客户端的信用参数,判断是否参与所述获取模块获取的所述交易信息对应的支付流程。
其中,还包括:授权模块,用于指定第四方认证中心验收所述第一客户端履行所述交易信息的情况,接收所述第四方认证中心对所述第一客户端履行所述交易信息的情况的验收报告,根据所述验收报告更新所述第一客户端的信用参数。
其中,还包括:接收模块,用于接收所述第二客户端支付的货款;或接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
其中,所述发送模块,还用于在所述判断模块判断参与所述交易信息对应的支付流程后,向所述第一客户端和所述第二客户端发送商品交付请求。
本发明实施例的技术方案具有以下优点,因为通过银行服务器作为中介,完成商品的交付和货款的支付,提高了商品交易的成功率,减小了商品交易的风险,降低了商品交易的成本。
附图说明
图1为本发明实施例中的一种支付方法流程图;
图2为本发明实施例中的另一种支付方法流程图;
图3为本发明实施例中的一种第二客户端与银行服务器之间建立连接的方法流程图;
图4为本发明实施例中的一种银行服务器与第一客户端之间建立连接的方法流程图;
图5为本发明实施例中的一种第一客户端与第二客户端之间建立连接的方法流程图;
图6为本发明实施例中的另一种第一客户端与银行服务器之间建立连接的方法流程图;
图7为本发明实施例中的另一种银行服务器与第二客户端之间建立连接的方法流程图;
图8为本发明实施例中的另一种第一客户端与第二客户端之间建立连接的方法流程图;
图9为本发明实施例中的一种支付系统结构图;
图10为本发明实施例中的一种银行服务器结构图;
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述。
如图1所示,为本发明实施例中的一种支付方法流程图,包括以下步骤:
步骤101,银行服务器分别与第一客户端和第二客户端签约。
本发明实施例中的第一客户端对应交易中的卖方,第二客户端对应交易中的买方。第一客户端和第二客户端进行交易前,可以分别与银行服务器签约,约定在后续的交易流程中以银行服务器作为第三方进行商品的交付和货款的支付。
银行服务器与第一客户端和第二客户端签约前,可以分别获取第一客户端和第二客户端的相关信息,包括:企业规模、企业成立时间、企业类型、资产负债、现金流量、损益情况、交易记录等。银行服务器综合分析上述信息,确定是否与第一客户端和第二客户端签约,并确定签约内容。银行服务器与第一客户端和第二客户端签约后,可以分别设置第一客户端和第二客户端的信用参数。在后续的交易流程中,银行服务器可以根据交易情况,动态更新第一客户端和第二客户端的信用参数。通过上述对第一客户端和第二客户端的信用参数的调整,银行服务器分别对第一客户端和第二客户端建立信用机制。第一客户端和第二客户端在各自的信用参数满足预设的条件时,才能通过银行服务器进行商品交易,并从银行服务器获得贷款。
步骤102,银行服务器获取第一客户端与第二客户端之间的交易信息。
第一客户端与第二客户端之间的交易信息可以是合同的形式,可以包括:第一客户端交付商品数量、第一客户端交付期限、第四方验收标准、银行垫付款金额、第二客户端付款金额、第二客户端付款期限、第一客户端和第二客户端的标识,还可以包括第三方在支付流程中获得的佣金金额或佣金比率。其中,第三方收取的佣金金额可以为第二客户端付款金额与第三方垫付款金额之间的差值,也可以为第二客户端付款金额与佣金比率的乘积。
第一客户端与第二客户端就交易信息达成一致后,银行服务器可以通过远程接收或者本地获取的方式,获取第一客户端和第二客户端之间的交易信息,并分别根据第一客户端和第二客户端的标识,对第一客户端和第二客户端的身份进行验证。验证通过后,银行服务器对交易信息进行解密,并将解密后的交易信息存储到数据库中。
步骤103,银行服务器判断第一客户端履行交易信息完毕时,根据签约内容,代替第二客户端向第一客户端垫付该交易信息中规定的货款。
第一客户端履行交易信息完毕后,银行服务器可以根据与第一客户端和第二客户端的签约内容,代替第二客户端向第一客户端垫付该交易信息中规定的货款,向第一客户端进行支付。向第一客户端垫付交易信息中规定的货款的方式,可以是根据交易信息中的第一客户端的标识,获取第一客户端的账户信息,将相应的货款从自身的系统账户转到第一客户端的账户。第一客户端的账户信息也可以直接包含在交易信息中,银行服务器直接根据交易信息中的第一客户端的账户信息,将相应的货款从自身的系统账户转到第一客户端的账户。
在第一客户端履行交易信息的过程中,银行服务器可以指定第四方认证中心验收第一客户端履行交易信息的情况。第四方认证中心获取银行服务器的授权后,根据交易信息中的第四方验收标准对第一客户端履行交易信息的情况进行验收,根据验收结果生成验收报告,并在验收报告中签字,将验收报告发送给银行服务器。第四方认证中心独立于第一客户端和第二客户端,与第一客户端和第二客户端均无直接联系。
如果第一客户端履行交易信息的情况符合第四方验收标准,则第四方认证中心生成的验收报告的内容为验收合格,银行服务器根据接收到的验收报告的内容判断第一客户端履行交易信息完毕,提高第一客户端的信用参数;如果第一客户端履行交易信息的情况不符合第四方验收标准,则第四方认证中心生成的验收报告的内容为验收不合格,银行服务器根据接收到的验收报告的内容判断第一客户端未履行交易信息完毕,降低第一客户端的信用参数。第一客户端的信用参数的更新,将决定第一客户端是否能够通过银行服务器进行商品交易,以及是否能够从银行服务器获得贷款。
步骤104,银行服务器向第二客户端发送货款的支付请求,根据第二客户端对支付请求的响应,更新第二客户端的信用参数。
银行服务器代替第二客户端向第一客户端垫付货款后,可以向第二客户端发送该货款的支付请求,要求第二客户端按照交易信息支付相应的货款。银行服务器向第二客户端发送支付请求后,可以根据交易信息中的第二客户端的标识,获取第二客户端的账户信息,并按照交易信息中的付款期限和商品金额从第二客户端的账户中扣除相应的货款。第二客户端的账户信息也可以直接包含在交易信息中,银行服务器直接根据交易信息中的第二客户端的账户信息,从第二客户端的账户中扣除相应的货款。如果从第二客户端的账户扣款成功或在预设的期限内接收到第二客户端支付的货款,银行服务器提高第二客户端的信用参数;如果从第二客户端的账户扣款失败、或在预设的期限内未接收到第二客户端支付的货款、或在预设的期限内未接收到第二客户端返回的扣款请求,银行服务器降低第二客户端的信用参数,并要求第二客户端支付滞纳金。第二客户端的信用参数的更新,将决定第二客户端是否能够通过银行服务器进行商品交易,以及是否能够从银行服务器获得贷款。
如图2所示,为本发明实施例中的另一种支付方法流程图,包括以下步骤:
步骤201,银行服务器分别与第一客户端和第二客户端签约。
第一客户端和第二客户端进行交易前,可以分别与银行服务器签约,约定在后续的交易流程中以银行服务器作为第三方进行商品的交付和货款的支付。签约内容可以包括:第一客户端向第二客户端进行商品交付;银行服务器在第一客户端完成商品交付后,代替第二客户端向第一客户端垫付相应的货款;银行服务器向第二客户端发送货款的支付请求,根据第二客户端对支付请求的响应,更新第二客户端的信用参数。
银行服务器与第一客户端和第二客户端签约前,可以分别获取第一客户端和第二客户端的相关信息。银行服务器综合分析这些信息,确定是否与第一客户端和第二客户端签约,并确定签约内容。银行服务器与第一客户端和第二客户端签约后,可以分别设置第一客户端和第二客户端的信用参数。
步骤202,银行服务器获取第一客户端与第二客户端之间的交易信息。
第一客户端与第二客户端约定交易信息后,可以通过网络将交易信息发送到银行服务器。银行服务器也可以在本地接收运营人员上传的交易信息,该交易信息可以包括:第一客户端交付商品数量、第一客户端交付商品质量、第一客户端交付期限、第四方验收标准、第三方垫付款金额、第二客户端付款金额、第二客户端付款期限、第一客户端和第二客户端的标识,还可以包括第三方在支付流程中获得的佣金金额或佣金比率。
步骤203,银行服务器根据第一客户端和第二客户端的信用参数,判断是否参与交易信息对应的支付流程。
如果银行服务器参与交易信息对应的支付流程,则执行步骤205;如果银行服务器不参与交易信息对应的支付流程,则执行步骤204。
银行服务器与第一客户端和第二客户端签约后,可以根据第一客户端和第二客户端的相关信息,分别设置第一客户端和第二客户端的信用参数。银行服务器获取第一客户端与第二客户端之间的交易信息后,根据交易信息中第一客户端和第二客户端的标识查询第一客户端和第二客户端的信用参数,判断是否参与交易信息对应的支付流程。银行服务器判断的标准可以是第二客户端的信用参数对应的信用额度与交易信息中第三方垫付款金额之间的大小关系,如果第二客户端的信用参数对应的信用额度不小于第三方垫付款金额,则参与交易信息对应的支付流程;如果第二客户端的信用参数对应的信用额度小于第三方垫付款金额,则不参与交易信息对应的支付流程。银行服务器判断的标准也可以是第一客户端与第二客户端的信用参数对应的信用额度分别与交易信息中第三方垫付款金额之间的大小关系,如果第一客户端与第二客户端的信用参数对应的信用额度均不小于第三方垫付款金额,则参与交易信息对应的支付流程;如果第一客户端与第二客户端的信用参数对应的信用额度中的至少一个小于第三方垫付款金额,则不参与交易信息对应的支付流程。
步骤204,银行服务器向第一客户端和第二客户端发送交易失败信息。
银行服务器确定不参与交易信息对应的支付流程后,向第一客户端和第二客户端发送交易失败信息。
步骤205,银行服务器向第一客户端和第二客户端发送商品交付请求。
银行服务器确定参与交易信息对应的支付流程后,向第一客户端和第二客户端发送商品交付请求,要求第一客户端与第二客户端依照交易信息进行商品交付。
步骤206,第一客户端与第二客户端进行商品交付。
第一客户端接收到银行服务器发送的商品交付请求后,将交易信息中规定的商品运送到指定地点,与第二客户端进行商品交付。
步骤207,银行服务器指定第四方认证中心验收第一客户端履行交易信息的情况。
为保证商品的交付符合交易信息,银行服务器可以指定第四方认证中心验收第一客户端履行交易信息的情况。第四方认证中心获取银行服务器的授权后,根据交易信息中的第四方验收标准对第一客户端履行交易信息的情况进行验收,根据验收结果生成验收报告,并在验收报告中签字。第四方认证中心独立于第一客户端和第二客户端,与第一客户端和第二客户端均无直接联系。
第四方验收标准可以包括:交付时间、交付地点、商品数量、商品质量、商品类型、生产厂家、保质期等信息。
步骤208,银行服务器接收第四方认证中心对第一客户端履行交易信息的情况的验收报告,根据该验收报告判断第一客户端是否履行交易信息完毕。
如果判断第一客户端履行交易信息完毕,则执行步骤210;如果判断第一客户端没有履行完交易信息,则执行步骤209。
第四方认证中心根据验收结果生成验收报告,将验收报告发送给银行服务器。如果第一客户端履行交易信息的情况符合第一客户端与第二客户端之间的交易信息,则第一客户端履行交易信息完毕;如果第一客户端履行交易信息的情况不符合第一客户端与第二客户端之间的交易信息,则第一客户端没有履行完交易信息。
步骤209,银行服务器通知第一客户端和第二客户端中止交易。
如果判断第一客户端没有履行完交易信息,银行服务器可以将验收报告转发给第一客户端和第二客户端,通知第一客户端和第二客户端中止交易。银行服务器还可以依据交易信息向第一客户端收取一定金额的违约金,也可以依据交易信息向第二客户端垫付一定金额的违约金,并降低第一客户端的信用参数。
银行服务器还可以要求第一客户端和第二客户端在规定期限内再次进行商品交付,并再次指定第四方认证中心对第一客户端和第二客户端交付的商品进行验收,接收第四方认证中心返回的验收报告。
步骤210,银行服务器代替第二客户端向第一客户端垫付交易信息中规定的货款。
如果判断第一客户端履行交易信息完毕,银行服务器可以代替第二客户端向第一客户端垫付交易信息中规定的货款,并提高第一客户端的信用参数。
步骤211,银行服务器向第二客户端发送货款的支付请求。
银行服务器向第一客户端垫付货款后,可以向第二客户端发送货款的支付请求,要求第二客户端按照交易信息支付相应的货款。支付请求的发送方式可以是通过电话、信函、传真或E-mail通知第二客户端付款期限和付款金额。
步骤212,银行服务器接收第二客户端返回的扣款请求。
第二客户端接收银行服务器发送的支付请求后,向银行服务器返回扣款请求,请求银行服务器从第二客户端的账户中扣除相应的货款。
本步骤为优选步骤,第二客户端也可以不向银行服务器返回扣款请求,而是直接向银行服务器支付货款。
步骤213,银行服务器从第二客户端的账户中扣除相应的货款。
如果银行服务器扣款成功,则执行步骤214;如果银行服务器扣款失败,则执行步骤215。
银行服务器接收第二客户端返回的扣款请求后,从第二客户端的账户中扣除交易信息中规定的付款金额。如果在付款期限内第二客户端的账户的金额小于交易信息中规定的付款金额,银行服务器无法在付款期限内从第二客户端的账户扣除足额的货款,则银行服务器扣款失败;如果在付款期限内第二客户端的账户的金额不小于交易信息中规定的付款金额,银行服务器能够在付款期限内从第二客户端的账户扣除足额的货款,则银行服务器扣款成功。
步骤214,银行服务器提高第二客户端的信用参数。
银行服务器在付款期限内从第二客户端的账户扣款成功或在预设的期限内接收到第二客户端支付的货款后,可以提高第二客户端的信用参数。第二客户端的信用参数提高后,第二客户端在下次通过银行服务器作为中介的支付流程中,可以提高垫付款金额。
步骤215,银行服务器降低第二客户端的信用参数,并要求第二客户端支付滞纳金。
银行服务器在付款期限内从第二客户端的账户扣款失败、或在预设的期限内未接收到第二客户端支付的货款、或在预设的期限内未接收到第二客户端返回的扣款请求后,可以降低第二客户端的信用参数,并根据付款期限要求第二客户端支付一定金额的滞纳金。
如图3所示,为本发明实施例中的一种第二客户端与银行服务器之间建立连接的方法流程图,包括以下步骤:
步骤301,银行服务器接收第二客户端发送的第一交易请求消息。
第二客户端在进行交易时,需要建立三方协议,确定进行三方交易的主体。第二客户端通过网络查询,获取第三方的信息,并向第三方对应的银行服务器发送第一交易请求消息,请求与银行服务器建立连接。第一交易请求消息包括第二客户端的基本信息、交易意向信息和交易历史记录信息等。
第二客户端发送的第一交易请求消息根据第二客户端的身份不同而有所不同。如果第二客户端为普通的用户,第二客户端的基本信息可以包括第二客户端的支付或偿还能力、第二客户端的交易金额是否充足、第二客户端的交易金额不充足时是否需要借贷、第二客户端如果进行借贷是否具备借贷的条件,以及是否具有抵押物等。对于第二客户端的支付能力,银行服务器需要对第二客户端的交易金额、支票等支付方式进行鉴别,以保障自身的利益。
如果第二客户端为企业或公司,第一交易请求消息中的第二客户端的基本信息就较为复杂,除了包括第二客户端的支付或偿还能力、第二客户端的交易金额不充足时是否需要借贷、第二客户端如果进行借贷是否具备借贷的条件,以及是否具有抵押物等外,还包括公司规模、资产等附加信息。
交易意向信息是指第二客户端想要通过交易得到的商品,该商品可以是有形商品,如汽车,房子,家具等,也可以是无形商品,如商标权,专利权,加盟权,著作权等。交易意向信息中还可以包括商品的交易方式和商品的使用信息,如使用方式可以为购买商品、租借商品、提供商品的制造方法、与第一客户端共同制造,或对商品进行代理销售等。另外,对于第二客户端采购的商品,又可以分为单件采购和批量采购,如果是批量采购的货物,还可以让第二客户端提供货物的运送方式等。目前网络较为流行的送货方式,大多采用单件邮寄需要额外支付邮寄费用,而较为大宗的货物则免去了邮寄费用或送货费用。
交易历史记录信息是指第二客户端在以前交易的过程中,第一客户端和第三方对第二客户端的评估信息。
步骤302,银行服务器向第二客户端回复确认信息。
银行服务器接收到第二客户端发送的第一交易请求消息后,向第二客户端回复确认信息,表示收到第二客户端发送的第一交易请求消息。
步骤303,银行服务器对第一交易请求消息进行评估,判断是否与第二客户端建立连接。
如果银行服务器判断与第二客户端建立连接,则执行步骤305;如果银行服务器判断不与第二客户端建立连接,则执行步骤304。
银行服务器收到第一交易请求消息后,利用预先设置的交易建立评估系统,对第一交易请求消息进行评估。评估的具体过程可以包括:根据第二客户端发送的第一交易请求消息中的第二客户端的基本信息、交易意向信息和交易历史记录信息,获取第二客户端的交易风险评估值,如果交易风险评估值在交易建立评估系统规定的范围内,则判断与第二客户端建立连接;如果交易风险评估值不在交易建立评估系统规定的范围内,则判断不与第二客户端建立连接。
步骤304,银行服务器向第二客户端发送交易反馈信息,通知第二客户端建立连接失败。
银行服务器对第一交易请求消息进行评估,将评估结果打包成交易反馈信息,并将交易反馈信息发送到第二客户端。当银行服务器判断不与第二客户端建立连接时,交易反馈信息中包括建立连接失败信息。
步骤305,银行服务器向第二客户端发送交易反馈信息,通知第二客户端建立连接。
当银行服务器判断与第二客户端建立连接时,银行服务器向第二客户端发送的交易反馈信息中包括第三方的基本信息、交易历史记录信息等。
步骤306,银行服务器与第二客户端建立连接。
如图4所示,为本发明实施例中的一种银行服务器与第一客户端之间建立连接的方法流程图,包括以下步骤:
步骤401,银行服务器根据第二客户端的交易意向,查询满足第二客户端交易意向的第一客户端。
步骤402,银行服务器向第一客户端发送第二交易请求消息。
银行服务器查询到满足第二客户端的交易意向的第一客户端后,向第一客户端发送第二交易请求消息,请求与第一客户端建立连接。
步骤403,第一客户端向银行服务器回复确认信息。
第一客户端接收到银行服务器发送的第二交易请求消息后,向银行服务器回复确认信息,表示收到银行服务器发送的第二交易请求消息。
步骤404,第一客户端对第二交易请求消息进行评估,判断是否与银行服务器建立连接。
如果第一客户端判断与银行服务器建立连接,则执行步骤406;如果第一客户端判断不与银行服务器建立连接,则执行步骤405。
第一客户端收到第二交易请求消息后,利用预先设置的交易建立评估系统,对第二交易请求消息进行评估。评估的具体过程可以包括:根据银行服务器发送的第二交易请求消息中的第二客户端的基本信息、交易意向信息和交易历史记录信息,获取第二客户端的交易风险评估值,如果交易风险评估值在交易建立评估系统规定的范围内,则判断与银行服务器建立连接;如果交易风险评估值不在交易建立评估系统规定的范围内,则判断不与银行服务器建立连接。
步骤405,第一客户端向银行服务器发送交易反馈信息,通知银行服务器建立连接失败。
第一客户端对第二交易请求消息进行评估,将评估结果打包成交易反馈信息,并将交易反馈信息发送到银行服务器。当第一客户端判断不与银行服务器建立连接时,交易反馈信息中包括建立连接失败信息。
步骤406,第一客户端向银行服务器发送交易反馈信息,通知银行服务器建立连接。
步骤407,银行服务器与第一客户端建立连接。
如图5所示,为本发明实施例中的一种第二客户端与第一客户端之间建立连接的方法流程图,包括以下步骤:
步骤501,第二客户端获取第一客户端的交易产品信息。
第二客户端获取第一客户端的交易产品信息的方式,可以是通过查询银行服务器的数据库,也可以是通过接收银行服务器转发的交易产品信息。
步骤502,第二客户端对第一客户端的交易产品信息进行分析,判断是否与第一客户端建立连接。
如果第二客户端判断与第一客户端建立连接,则转步骤504;如果第二客户端判断不与第一客户端建立连接,则转步骤503。
步骤503,第二客户端向第一客户端发送取消建立连接信息。
如果第二客户端判断不与第一客户端建立连接,则向第一客户端发送取消建立连接信息,拒绝与第一客户端建立连接。
步骤504,第二客户端向第一客户端发送第三交易请求消息。
如果第二客户端判断与第一客户端建立连接,则向第一客户端发送第三交易请求消息,请求与第一客户端建立连接。
步骤505,第一客户端向第二客户端回复接受请求信息。
第一客户端接收到来自第二客户端的第三交易请求消息后,向第二客户端回复接受请求信息,表示接受第二客户端的交易请求。
步骤506,第一客户端与第二客户端建立连接。
第一客户端与第二客户端建立连接后,可以约定交易信息。交易信息的约定可以独立于第三方,也可以由第三方参与,当交易信息的约定独立于第三方时,需要将交易信息上传到第三方对应的银行服务器。
如图6所示,为本发明实施例中的另一种第一客户端与银行服务器之间建立连接的方法流程图,包括以下步骤:
步骤601,第一客户端向银行服务器发送第四交易请求消息。
第一客户端在进行交易时,需要建立三方协议,确定进行三方交易的主体。第一客户端在进行网络查询,获取第三方的信息,并向第三方对应的银行服务器发送第四交易请求消息,请求与银行服务器建立连接。第四交易请求消息包括第一客户端的基本信息、交易产品信息、交易历史记录信息等。
第四交易请求消息中的第一客户端的基本信息,包括生产能力信息,用以表征第一客户端的生产运作模式。
第四交易请求消息中的交易产品信息,包括产品名称、最少交易量或最少交易金额、送货要求等信息。
步骤602,银行服务器向第一客户端回复确认信息。
银行服务器接收到第一客户端发送的第四交易请求消息后,向第一客户端回复确认信息,表示收到第一客户端发送的第四交易请求消息。
步骤603,银行服务器对第四交易请求消息进行评估,判断是否与第一客户端建立连接。
如果银行服务器判断与第一客户端建立连接,则执行步骤605;如果银行服务器判断不与第一客户端建立连接,则执行步骤604。
银行服务器收到第四交易请求消息后,利用预先设置的交易建立评估系统,对第四交易请求消息进行评估。评估的具体过程可以包括:根据第一客户端发送的第四交易请求消息中的第一客户端的基本信息、交易产品信息和交易历史记录信息,获取第一客户端的交易风险评估值,如果交易风险评估值在交易建立评估系统规定的范围内,则判断与第一客户端建立连接;如果交易风险评估值不在交易建立评估系统规定的范围内,则判断不与第一客户端建立连接。
步骤604,银行服务器向第一客户端发送交易反馈信息,通知第一客户端建立连接失败。
银行服务器对第四交易请求消息进行评估,将评估结果打包成交易反馈信息,并将交易反馈信息发送到第一客户端。当银行服务器判断不与第二客户端建立连接时,交易反馈信息中包括建立连接失败信息。
步骤605,银行服务器向第一客户端发送交易反馈信息,通知第二客户端建立连接。
当银行服务器判断与第一客户端建立连接时,交易反馈信息中包括第三方的基本信息、交易历史记录信息等。
步骤606,银行服务器与第一客户端建立连接。
第一客户端可以向银行服务器提供交易产品信息和交易账户信息,用于后续的交易流程。
如图7所示,为本发明实施例中的另一种银行服务器与第二客户端之间建立连接的方法流程图,包括以下步骤:
步骤701,银行服务器根据第一客户端的交易产品信息,查询与第一客户端的交易产品信息适配的第二客户端。
步骤702,银行服务器向第二客户端发送第五交易请求消息。
银行服务器查询到与第一客户端的交易产品信息适配的第二客户端后,向第二客户端发送第五交易请求消息,请求与第二客户端建立连接。
步骤703,第二客户端向银行服务器回复确认信息。
第二客户端接收到银行服务器发送的第五交易请求消息后,向银行服务器回复确认信息,表示收到银行服务器发送的第五交易请求消息。
步骤704,第二客户端对第五交易请求消息进行评估,判断是否与银行服务器建立连接。
如果第二客户端判断与银行服务器建立连接,则执行步骤706;如果第二客户端判断不与银行服务器建立连接,则执行步骤705。
第二客户端收到第五交易请求消息后,利用预先设置的交易建立评估系统,对第五交易请求消息进行评估。评估的具体过程可以包括:根据银行服务器发送的第五交易请求消息中的第一客户端的基本信息、交易产品信息和交易历史记录信息,获取第一客户端的交易风险评估值,如果交易风险评估值在交易建立评估系统规定的范围内,则判断与银行服务器建立连接;如果交易风险评估值不在交易建立评估系统规定的范围内,则判断不与银行服务器建立连接。
步骤705,第二客户端向银行服务器发送交易反馈信息,通知银行服务器建立连接失败。
第二客户端对第五交易请求消息进行评估,将评估结果打包成交易反馈信息,并将交易反馈信息发送到银行服务器。当第二客户端判断不与银行服务器建立连接时,交易反馈信息中包括建立连接失败信息。
步骤706,第二客户端向银行服务器发送交易反馈信息,通知银行服务器建立连接。
第二客户端判断与银行服务器建立连接时,交易反馈信息中包括交易意向信息等。银行服务器将交易意向信息另存后,可以向第一客户端转发该交易意向信息。
步骤707,银行服务器与第二客户端建立连接。
第二客户端可以向银行服务器提供自身的交易账户,还可以提供担保金额或其他用于后续交易的资金或抵押物。
如图8所示,为本发明实施例中的另一种第一客户端与第二客户端之间建立连接的方法流程图,包括以下步骤:
步骤801,第一客户端获取第二客户端的交易意向信息。
第一客户端获取第二客户端的交易意向信息的方式,可以是通过查询银行服务器的数据库,也可以是通过接收银行服务器转发的交易意向信息。
步骤802,第一客户端对第二客户端的交易意向信息进行分析,判断是否与第二客户端建立连接。
如果第一客户端判断与第二客户端建立连接,则转步骤804;如果第一客户端判断不与第二客户端建立连接,则转步骤803。
步骤803,第一客户端向第二客户端发送取消建立连接信息。
如果第一客户端判断不与第二客户端建立连接,则向第二客户端发送取消建立连接信息,拒绝与第二客户端建立连接。
步骤804,第一客户端向第二客户端发送第六交易请求消息。
如果第一客户端判断与第二客户端建立连接,则向第二客户端发送第六交易请求消息,请求与第二客户端建立连接。第一客户端向第二客户端发送第六交易请求消息的方式,可以是由银行服务器向第二客户端转发接收到的第六交易请求消息,也可以是将第六交易请求消息直接发送到第二客户端。
步骤805,第二客户端向第一客户端回复接受请求信息。
第二客户端接收到来自第一客户端的第六交易请求消息后,向第一客户端回复接受请求信息,表示接受第一客户端的交易请求。第二客户端向第一客户端回复接受请求信息的方式,可以是由银行服务器向第一客户端转发接收到的接受请求信息,也可以是将接受请求信息直接发送到第一客户端。
步骤806,第一客户端与第二客户端建立连接。
第一客户端与第二客户端建立连接后,可以约定交易信息。交易信息的约定可以独立于第三方,也可以由第三方参与,当交易信息的约定独立于第三方时,需要将交易信息上传到第三方对应的银行服务器。
如图9所示,为本发明实施例中的一种支付系统结构图,包括:
银行服务器910,用于分别与第一客户端920和第二客户端930签约,获取第一客户端920与第二客户端930之间的交易信息,判断第一客户端920履行该交易信息完毕时,根据上述签约内容,代替第二客户端930向第一客户端920垫付交易信息中规定的货款,向第二客户端930发送该货款的支付请求,根据第二客户端930对该支付请求的响应,更新第二客户端930的信用参数。
本发明实施例中的第一客户端920对应交易中的卖方,第二客户端930对应交易中的买方。银行服务器910与第一客户端920和第二客户端930签约前,可以分别获取第一客户端920和第二客户端930的相关信息。银行服务器910综合分析上述信息,确定是否与第一客户端920和第二客户端930签约,并确定签约内容。银行服务器910与第一客户端920和第二客户端签约930后,可以分别设置第一客户端920和第二客户端930的信用参数。在后续的交易流程中,银行服务器910可以根据交易情况,动态更新第一客户端920和第二客户端930的信用参数。
第一客户端920与第二客户端930约定交易信息后,将交易信息上传到银行服务器910。第一客户端920与第二客户端930之间的交易信息可以是合同的形式,可以包括:第一客户端920交付商品数量、第一客户端920交付商品质量、第一客户端920交付期限、第四方验收标准、第三方垫付款金额、第二客户端930付款金额、第二客户端930付款期限、第一客户端920和第二客户端930的标识,还可以包括第三方在支付流程中获得的佣金金额或佣金比率。
第一客户端920与第二客户端930就交易信息达成一致后,银行服务器910可以通过远程接收或者本地获取的方式,获取第一客户端920和第二客户端930之间的交易信息,并分别根据第一客户端920和第二客户端930的标识,对第一客户端920和第二客户端930的身份进行验证。验证通过后,银行服务器910对交易信息进行解密,并将解密后的交易信息存储到数据库中。
第一客户端920,用于与第二客户端930约定交易信息,履行该交易信息,接收银行服务器910代替第二客户端930垫付的交易信息中规定的货款。
第一客户端920履行交易信息完毕后,银行服务器910可以根据与第一客户端920和第二客户端930的签约内容,代替第二客户端930向第一客户端920垫付该交易信息中规定的货款。向第一客户端920垫付货款的方式可以是根据交易信息中的第一客户端920的标识,获取第一客户端920的账户信息,将相应的货款从自身的系统账户转到第一客户端920的账户。第一客户端920的账户信息也可以直接包含在交易信息中,银行服务器910直接根据交易信息中的第一客户端920的账户信息,将相应的货款从自身的系统账户转到第一客户端920的账户。
银行服务器910向第一客户端920垫付货款后,向第二客户端930发送货款的支付请求,要求第二客户端930按照交易信息支付相应的货款。银行服务器910向第二客户端930发送支付请求后,可以按照交易信息中的付款期限和商品金额从第二客户端930的账户中扣除相应的货款。如果从第二客户端930的账户扣款成功,银行服务器910提高第二客户端930的信用参数;如果从第二客户端930的账户扣款失败,银行服务器910降低第二客户端930的信用参数,并根据付款期限要求第二客户端930支付相应的滞纳金。
上述银行服务器910,还用于根据第一客户端920和第二客户端930的信用参数,确定参与交易信息对应的支付流程。
银行服务器910与第一客户端920和第二客户端930签约后,可以根据第一客户端920和第二客户端930的相关信息,分别设置第一客户端920和第二客户端930的信用参数。银行服务器910获取第一客户端920与第二客户端930之间的交易信息后,根据交易信息中第一客户端920和第二客户端930的标识查询第一客户端920和第二客户端930的信用参数,判断是否参与交易信息对应的支付流程。
上述银行服务器910,还用于向第一客户端920和第二客户端930发送商品交付请求。银行服务器910确定参与交易信息对应的支付流程后,向第一客户端920和第二客户端930发送商品交付请求,要求第一客户端920与第二客户端930依照交易信息进行商品交付。上述银行服务器910,还用于向第一客户端920和第二客户端930发送交易失败信息。银行服务器910确定不参与交易信息对应的支付流程后,向第一客户端920和第二客户端930发送交易失败信息,通知第一客户端920与第二客户端930不参与交易信息对应的支付流程。
本发明实施例中的支付系统,还包括:
第四方认证中心940,用于获取银行服务器910的授权,验收第一客户端920履行交易信息的情况,根据验收结果生成验收报告,将验收报告发送到银行服务器910。
为保证商品的交付符合交易信息,银行服务器910可以指定第四方认证中心940验收第一客户端920履行交易信息的情况。第四方认证中心940获取银行服务器910的授权后,根据交易信息中的第四方验收标准对第一客户端920履行交易信息的情况进行验收,根据验收结果生成验收报告,并在验收报告中签字。
第四方验收标准可以包括:交付时间、交付地点、商品数量、商品质量、商品类型、生产厂家、保质期等信息。如果第一客户端920履行交易信息的情况符合第四方验收标准,则第四方认证中心940生成的验收报告的内容为验收合格;如果第一客户端920履行交易信息的情况不符合第四方验收标准,则第四方认证中心940生成的验收报告的内容为验收不合格。
上述银行服务器910,还用于指定第四方认证中心940验收第一客户端920履行交易信息的情况,接收第四方认证中心940发送的验收报告,根据该验收报告更新第一客户端920的信用参数。
第四方认证中心940根据验收结果生成验收报告,将验收报告发送给银行服务器910。如果第一客户端920履行交易信息的情况符合第一客户端920与第二客户端930之间的交易信息,则第四方认证中心940发送的验收报告的内容为验收合格;如果第一客户端920履行交易信息的情况不符合第一客户端920与第二客户端930之间的交易信息,则第四方认证中心940发送的验收报告的内容为验收不合格。
如果第四方认证中心940对第一客户端920履行交易信息的情况的验收报告的内容为验收不合格,银行服务器910将验收报告转发给第一客户端920和第二客户端930,通知第一客户端920和第二客户端930中止交易。银行服务器910可以依据交易信息向第一客户端920收取一定金额的违约金,也可以依据交易信息向第二客户端930垫付一定金额的违约金,并降低第一客户端920的信用参数。
银行服务器910还可以要求第一客户端920和第二客户端930在规定期限内再次进行商品交付,并再次指定第四方认证中心940对第一客户端履行交易信息的情况进行验收,接收第四方认证中心940返回的验收报告。
如果第四方认证中心940对第一客户端920履行交易信息的情况的验收报告的内容为验收合格,银行服务器910可以提高第一客户端920的信用参数。第一客户端920的信用参数的更新,将决定第一客户端920是否能够通过银行服务器910进行商品交易,以及是否能够从银行服务器910获得贷款。
上述银行服务器910,还用于接收第二客户端930支付的货款;或
接收第二客户端930返回的扣款请求,从第二客户端930的账户中扣除相应的货款。
银行服务器910向第一客户端920垫付货款后,向第二客户端930发送货款的支付请求,要求第二客户端930按照交易信息支付相应的货款。支付请求的发送方式可以是通过电话、信函、传真或E-mail通知第二客户端930付款期限和付款金额。
第二客户端930接收银行服务器910发送的支付请求后,向银行服务器910返回扣款请求,请求银行服务器910从第二客户端930的账户中扣除相应的货款。第二客户端930也可以不向银行服务器910返回扣款请求,而是直接向银行服务器910支付货款。
上述银行服务器910,还用于在扣款成功或在预设的期限内接收到第二客户端930支付的货款后,提高第二客户端930的信用参数;或在扣款失败、或在预设的期限内未接收到第二客户端930支付的货款、或在预设的期限内未接收到第二客户端930返回的扣款请求后,降低第二客户端930的信用参数,要求第二客户端930支付滞纳金。
银行服务器910接收第二客户端930返回的扣款请求后,从第二客户端930的账户中扣除交易信息中规定的付款金额。如果在付款期限内第二客户端930的账户的金额小于交易信息中规定的付款金额,银行服务器910无法在付款期限内从第二客户端930的账户扣除足额的货款,则银行服务器910扣款失败;如果在付款期限内第二客户端930的账户的金额不小于交易信息中规定的付款金额,银行服务器910能够在付款期限内从第二客户端930的账户扣除足额的货款,则银行服务器910扣款成功。
银行服务器910在付款期限内从第二客户端930的账户扣款成功或在预设的期限内接收到第二客户端930支付的货款后,可以提高第二客户端930的信用参数。第二客户端930的信用参数提高后,第二客户端930在下次通过银行服务器910作为中介的支付流程中,可以提高垫付款金额。
银行服务器910在付款期限内从第二客户端930的账户扣款失败、或在预设的期限内未接收到第二客户端930支付的货款、或在预设的期限内未接收到第二客户端930返回的扣款请求后,可以降低第二客户端930的信用参数,并根据付款期限要求第二客户端930支付一定金额的滞纳金。第二客户端930的信用参数的更新,将决定第二客户端930是否能够通过银行服务器910进行商品交易,以及是否能够从银行服务器910获得贷款。
如图10所示,为本发明实施例中的一种银行服务器结构图,该银行服务器110包括:
签约模块1110,用于分别与第一客户端和第二客户端签约。
在第一客户端和第二客户端进行交易前,签约模块1110可以分别与第一客户端和第二客户端签约,约定在后续的交易流程中以银行服务器作为第三方进行商品的交付和货款的支付。签约内容可以包括:第一客户端向第二客户端进行商品交付;银行服务器在第一客户端完成商品交付后,代替第二客户端向第一客户端垫付相应的货款;银行服务器向第二客户端发送货款的支付请求,根据第二客户端对支付请求的响应,更新第二客户端的信用参数。
签约模块1110与第一客户端和第二客户端签约前,可以分别获取第一客户端和第二客户端的相关信息,包括:企业规模、企业成立时间、企业类型、资产负债、现金流量、损益情况、交易记录等。签约模块1110综合分析上述信息,确定是否与第一客户端和第二客户端签约,并确定签约内容。签约模块1110与第一客户端和第二客户端签约后,可以分别设置第一客户端和第二客户端的信用参数。在后续的交易流程中,可以根据交易情况,动态更新第一客户端和第二客户端的信用参数。
获取模块1120,用于获取第一客户端与第二客户端之间的交易信息。
第一客户端与第二客户端约定交易信息后,可以通过网络将交易信息发送到获取模块1120。获取模块1120也可以在本地接收运营人员上传的交易信息。,该交易信息可以包括:第一客户端交付商品数量、第一客户端交付商品质量、第一客户端交付期限、第四方验收标准、第三方垫付款金额、第二客户端付款金额、第二客户端付款期限、第一客户端和第二客户端的标识,还可以包括第三方在支付流程中获得的佣金金额或佣金比率。其中,第三方收取的佣金金额可以为第二客户端付款金额与第三方垫付款金额之间的差值,也可以为第二客户端付款金额与佣金比率的乘积。
支付模块1130,用于判断第一客户端履行交易信息完毕时,根据签约模块1110实现的签约内容,代替第二客户端向第一客户端垫付交易信息中规定的货款。
判断第一客户端履行交易信息完毕时,支付模块1130可以代替第二客户端向第一客户端垫付该交易信息中规定的货款。支付模块1130向第一客户端垫付货款的方式可以是将相应的货款从自身的系统账户转到第一客户端的账户。
发送模块1140,用于向第二客户端发送货款的支付请求,根据第二客户端对该支付请求的响应,更新第二客户端的信用参数。
在支付模块1130向第一客户端垫付货款后,发送模块1140向第二客户端发送支付请求,要求第二客户端按照交易信息支付相应的货款。支付请求的发送方式可以是通过电话、信函、传真或E-mail通知第二客户端付款期限和商品金额,发送模块1140向第二客户端发送支付请求后,可以按照交易信息中的付款期限和商品金额从第二客户端的账户中扣除相应的货款。如果从第二客户端的账户扣款成功,则提高第二客户端的信用参数;如果从第二客户端的账户扣款失败,则降低第二客户端的信用参数,并根据付款期限要求第二客户端支付相应的滞纳金。
判断模块1150,用于根据第一客户端和第二客户端的信用参数,判断是否参与获取模块1120获取的交易信息对应的支付流程。
判断模块1150依据第一客户端和第二客户端的交易记录,可以分别设置第一客户端和第二客户端的信用参数。判断模块1150根据获取模块1120获取的交易信息中第一客户端和第二客户端的标识查询第一客户端和第二客户端的信用参数,判断是否参与交易信息对应的支付流程。判断模块1150判断的标准可以是第二客户端的信用参数对应的信用额度与交易信息中第三方垫付款金额之间的大小关系,如果第二客户端的信用参数对应的信用额度不小于第三方垫付款金额,则参与交易信息对应的支付流程;如果第二客户端的信用参数对应的信用额度小于第三方垫付款金额,则不参与交易信息对应的支付流程。判断模块1150判断的标准也可以是第一客户端与第二客户端的信用参数对应的信用额度分别与交易信息中第三方垫付款金额之间的大小关系,如果第一客户端与第二客户端的信用参数对应的信用额度均不小于第三方垫付款金额,则参与交易信息对应的支付流程;如果第一客户端与第二客户端的信用参数对应的信用额度中的至少一个小于第三方垫付款金额,则不参与交易信息对应的支付流程。
授权模块1160,用于指定第四方认证中心验收第一客户端履行交易信息的情况,接收第四方认证中心对第一客户端履行交易信息的情况的验收报告,根据该验收报告更新第一客户端的信用参数。
为保证商品的交付符合交易信息,授权模块1160可以指定第四方认证中心验收第一客户端履行交易信息的情况。第四方认证中心获取授权模块1160的授权后,根据交易信息中的第四方验收标准对第一客户端履行交易信息的情况进行验收,根据验收结果生成验收报告,并在验收报告中签字。第四方认证中心独立于第一客户端和第二客户端,与第一客户端和第二客户端均无直接联系。
第四方验收标准可以包括:交付时间、交付地点、商品数量、商品质量、商品类型、生产厂家、保质期等信息。如果第一客户端履行交易信息的情况符合第四方验收标准,则第四方认证中心生成的验收报告的内容为验收合格;如果第一客户端履行交易信息的情况不符合第四方验收标准,则第四方认证中心生成的验收报告的内容为验收不合格。
第四方认证中心根据验收结果生成验收报告,将验收报告发送给授权模块1160。如果第一客户端履行交易信息的情况符合第一客户端与第二客户端之间的交易信息,则第四方认证中心发送的验收报告的内容为验收合格;如果第一客户端履行交易信息的情况不符合第一客户端与第二客户端之间的交易信息,则第四方认证中心发送的验收报告的内容为验收不合格。
如果第四方认证中心发送的验收报告的内容为验收不合格,授权模块1160将验收报告转发给第一客户端和第二客户端,通知第一客户端第二客户端中止交易。授权模块1160可以依据交易信息向第一客户端收取一定金额的违约金,也可以依据交易信息向第二客户端垫付一定金额的违约金,并降低第一客户端920的信用参数。
授权模块1160还可以要求第一客户端和第二客户端在规定期限内再次进行商品交付,并再次指定第四方认证中心对第一客户端履行交易信息的情况进行验收,接收第四方认证中心返回的验收报告。
如果第四方认证中心对第一客户端履行交易信息的情况的验收报告的内容为验收合格,授权模块1160可以提高第一客户端的信用参数。第一客户端的信用参数的更新,将决定第一客户端是否能够通过银行服务器进行商品交易,以及是否能够从银行服务器获得贷款。
接收模块1170,用于接收第二客户端支付的货款;或
接收第二客户端返回的扣款请求,从第二客户端的账户中扣除相应的货款。
上述发送模块1140,还用于在判断模块1150判断不参与交易信息对应的支付流程后,向第一客户端和第二客户端发送交易失败信息。
在判断模块1150确定不参与交易信息对应的支付流程后,发送模块1140向第一客户端和第二客户端发送交易失败信息,通知第一客户端与第二客户端不参与交易信息对应的支付流程。
上述发送模块1140,还用于在判断模块1150判断参与交易信息对应的支付流程后,向第一客户端和第二客户端发送商品交付请求。
在判断模块1150确定参与交易信息对应的支付流程后,发送模块1140向第一客户端和第二客户端发送商品交付请求,要求第一客户端与第二客户端依照交易信息进行商品交付。
第二客户端接收发送模块1140发送的支付请求后,向接收模块1170返回扣款请求,请求接收模块1170从第二客户端的账户中扣除相应的货款。接收模块1170接收扣款请求后,从第二客户端的账户中扣除相应的货款。
上述接收模块1170,还用于在扣款成功或在预设的期限内接收到第二客户端支付的货款后,提高第二客户端的信用参数;或在扣款失败、或在预设的期限内未接收到第二客户端支付的货款、或在预设的期限内未接收到第二客户端返回的扣款请求后,降低第二客户端的信用参数,要求第二客户端支付滞纳金。
接收模块1170接收第二客户端返回的扣款请求后,从第二客户端的账户中扣除交易信息中规定的付款金额。如果在付款期限内第二客户端的账户的金额小于交易信息中规定的付款金额,接收模块1170无法在付款期限内从第二客户端的账户扣除足额的货款,则接收模块1170扣款失败;如果在付款期限内第二客户端的账户的金额不小于交易信息中规定的付款金额,接收模块1170能够在付款期限内从第二客户端的账户扣除足额的货款,则接收模块1170扣款成功。
接收模块1170在付款期限内从第二客户端的账户扣款成功或在预设的期限内接收到第二客户端支付的货款后,可以提高第二客户端的信用参数。第二客户端的信用参数提高后,第二客户端在下次支付流程中,可以提高垫付款金额。
接收模块1170在付款期限内从第二客户端的账户扣款失败、或在预设的期限内未接收到第二客户端支付的货款、或在预设的期限内未接收到第二客户端返回的扣款请求后,可以降低第二客户端的信用参数,并根据付款期限要求第二客户端支付一定金额的滞纳金。第二客户端的信用参数的更新,将决定第二客户端是否能够通过银行服务器进行商品交易,以及是否能够从银行服务器获得贷款。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
Claims (10)
1.一种支付方法,其特征在于,包括:
银行服务器分别与第一客户端和第二客户端签约;
所述银行服务器获取所述第一客户端与所述第二客户端之间的交易信息;
所述银行服务器判断所述第一客户端履行所述交易信息完毕时,根据所述签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款;
所述银行服务器向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数。
2.如权利要求1所述支付方法,其特征在于,所述银行服务器获取第一客户端与第二客户端之间的交易信息之后,还包括:
所述银行服务器根据所述第一客户端和所述第二客户端的信用参数,确定参与所述交易信息对应的支付流程;所述银行服务器向所述第一客户端和所述第二客户端发送商品交付请求。
3.如权利要求1或2所述支付方法,其特征在于,所述银行服务器判断第一客户端履行交易信息完毕,包括:
所述银行服务器指定第四方认证中心验收所述第一客户端履行所述交易信息的情况;
所述银行服务器接收所述第四方认证中心对所述第一客户端履行所述交易信息的情况的验收报告,根据所述验收报告判断所述第一客户端履行所述交易信息完毕,更新所述第一客户端的信用参数。
4.如权利要求3所述支付方法,其特征在于,所述银行服务器向第二客户端发送货款的支付请求之后,还包括:
所述银行服务器接收所述第二客户端支付的货款;或
所述银行服务器接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
5.一种支付系统,其特征在于,包括:
银行服务器,用于分别与第一客户端和第二客户端签约,获取所述第一客户端与所述第二客户端之间的交易信息,判断所述第一客户端履行所述交易信息完毕时,根据所述签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款,向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数;
第一客户端,用于与所述第二客户端约定所述交易信息,履行所述交易信息,接收所述银行服务器代替所述第二客户端垫付的所述交易信息中规定的货款;
第二客户端,用于与所述第一客户端约定所述交易信息,接收所述银行服务器发送的所述货款的支付请求,响应所述支付请求。
6.如权利要求5所述支付系统,其特征在于,
所述银行服务器,还用于根据所述第一客户端和所述第二客户端的信用参数,确定参与所述交易信息对应的支付流程;
所述银行服务器,还用于向所述第一客户端和所述第二客户端发送商品交付请求。
7.如权利要求5或6所述支付系统,其特征在于,还包括:
第四方认证中心,用于获取所述银行服务器的授权,验收所述第一客户端履行所述交易信息的情况,根据验收结果生成验收报告,将所述验收报告发送到所述银行服务器;
所述银行服务器,还用于指定所述第四方认证中心验收所述第一客户端履行所述交易信息的情况,接收所述第四方认证中心发送的验收报告,根据所述验收报告更新所述第一客户端的信用参数;
所述银行服务器,还用于接收所述第二客户端支付的货款;或接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
8.一种银行服务器,其特征在于,包括:
签约模块,用于分别与第一客户端和第二客户端签约;
获取模块,用于获取第一客户端与第二客户端之间的交易信息;
支付模块,用于判断所述第一客户端履行所述交易信息完毕时,根据所述签约模块实现的签约内容,代替所述第二客户端向所述第一客户端垫付所述交易信息中规定的货款;
发送模块,用于向所述第二客户端发送所述货款的支付请求,根据所述第二客户端对所述支付请求的响应,更新所述第二客户端的信用参数。
9.如权利要求8所述银行服务器,其特征在于,还包括:
判断模块,用于根据所述第一客户端和所述第二客户端的信用参数,判断是否参与所述获取模块获取的所述交易信息对应的支付流程;
授权模块,用于指定第四方认证中心验收所述第一客户端履行所述交易信息的情况,接收所述第四方认证中心对所述第一客户端履行所述交易信息的情况的验收报告,根据所述验收报告更新所述第一客户端的信用参数;
接收模块,用于接收所述第二客户端支付的货款;或接收所述第二客户端返回的扣款请求,从所述第二客户端的账户中扣除相应的货款。
10.如权利要求9所述银行服务器,其特征在于,
所述发送模块,还用于在所述判断模块判断参与所述交易信息对应的支付流程后,向所述第一客户端和所述第二客户端发送商品交付请求。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100867862A CN101937538A (zh) | 2009-06-30 | 2009-06-30 | 一种支付方法、系统及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100867862A CN101937538A (zh) | 2009-06-30 | 2009-06-30 | 一种支付方法、系统及设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101937538A true CN101937538A (zh) | 2011-01-05 |
Family
ID=43390855
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100867862A Pending CN101937538A (zh) | 2009-06-30 | 2009-06-30 | 一种支付方法、系统及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101937538A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105931036A (zh) * | 2016-05-31 | 2016-09-07 | 北京小米移动软件有限公司 | 支付方法及装置 |
CN106228430A (zh) * | 2016-07-28 | 2016-12-14 | 徐晖 | 一种基于第三方的合同管理方法及系统 |
CN107483534A (zh) * | 2017-06-28 | 2017-12-15 | 阿里巴巴集团控股有限公司 | 一种业务处理的方法及装置 |
CN107924536A (zh) * | 2015-07-31 | 2018-04-17 | 株式会社三井住友银行 | 电子请示书的更新方法以及系统 |
CN108074183A (zh) * | 2016-11-14 | 2018-05-25 | 平安科技(深圳)有限公司 | 一种理赔请求处理方法、装置和系统 |
CN110086761A (zh) * | 2014-07-31 | 2019-08-02 | 阿里巴巴集团控股有限公司 | 一种提供资源的方法和设备 |
CN114187999A (zh) * | 2022-02-17 | 2022-03-15 | 四川赛尔斯科技有限公司 | 一种医院统一支付管理平台及控制方法 |
CN116579847A (zh) * | 2023-05-12 | 2023-08-11 | 广州千鸟电商科技有限公司 | 一种基于多源核查的纸质商品交易管理方法及系统 |
-
2009
- 2009-06-30 CN CN2009100867862A patent/CN101937538A/zh active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110086761A (zh) * | 2014-07-31 | 2019-08-02 | 阿里巴巴集团控股有限公司 | 一种提供资源的方法和设备 |
CN110086761B (zh) * | 2014-07-31 | 2022-03-04 | 创新先进技术有限公司 | 一种提供资源的方法和设备 |
CN107924536A (zh) * | 2015-07-31 | 2018-04-17 | 株式会社三井住友银行 | 电子请示书的更新方法以及系统 |
CN107924536B (zh) * | 2015-07-31 | 2022-02-01 | 株式会社三井住友银行 | 更新电子请示书的方法、计算机以及非暂时性计算机可读存储介质 |
CN105931036A (zh) * | 2016-05-31 | 2016-09-07 | 北京小米移动软件有限公司 | 支付方法及装置 |
CN106228430A (zh) * | 2016-07-28 | 2016-12-14 | 徐晖 | 一种基于第三方的合同管理方法及系统 |
CN108074183A (zh) * | 2016-11-14 | 2018-05-25 | 平安科技(深圳)有限公司 | 一种理赔请求处理方法、装置和系统 |
CN107483534A (zh) * | 2017-06-28 | 2017-12-15 | 阿里巴巴集团控股有限公司 | 一种业务处理的方法及装置 |
CN107483534B (zh) * | 2017-06-28 | 2020-07-28 | 阿里巴巴集团控股有限公司 | 一种业务处理的方法及装置 |
CN114187999A (zh) * | 2022-02-17 | 2022-03-15 | 四川赛尔斯科技有限公司 | 一种医院统一支付管理平台及控制方法 |
CN114187999B (zh) * | 2022-02-17 | 2022-04-19 | 四川赛尔斯科技有限公司 | 一种医院统一支付管理平台及控制方法 |
CN116579847A (zh) * | 2023-05-12 | 2023-08-11 | 广州千鸟电商科技有限公司 | 一种基于多源核查的纸质商品交易管理方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8712914B2 (en) | Method and system for facilitating micropayments in a financial transaction system | |
US8335745B2 (en) | Method and system for processing micropayment transactions | |
US7908214B2 (en) | Systems and methods for adjusting loan amounts to facilitate transactions | |
US7979349B2 (en) | Systems and methods for adjusting crediting limits to facilitate transactions | |
US8234212B2 (en) | Systems and methods for facilitating transactions with interest | |
US7904385B2 (en) | Systems and methods for facilitating budgeting transactions | |
US7925585B2 (en) | Systems and methods for facilitating transactions with different account issuers | |
CN101937538A (zh) | 一种支付方法、系统及设备 | |
US20130332337A1 (en) | Systems and Methods for Enabling Trusted Borrowing and Lending Using Electronic Funds | |
US20090043705A1 (en) | Systems and methods for facilitating transactions | |
US20090048886A1 (en) | Systems and Methods for Facilitating Gifting Transactions | |
US20090048969A1 (en) | Systems and Methods for Facilitating Transactions Between Different Financial Accounts | |
CN1355910A (zh) | 个人-个人、个人-企业、银行-个人和银行-银行的财务往来系统 | |
CN101354770A (zh) | 会员名称与银行卡绑定的电子商务系统和方法 | |
US20130253956A1 (en) | Chargeback insurance | |
KR20220089633A (ko) | 지급결제의 운영컴퓨터 및 지급결제방법 | |
KR20080048645A (ko) | 은행의 에스크로 서비스 시스템 및 그 방법 | |
KR20080030593A (ko) | 대행결제 시스템 | |
KR20060108269A (ko) | 안전한 전자상거래 중개 시스템 및 전자상거래 중개 방법 | |
KR20090002100A (ko) | 매출채권 할인 방법 및 시스템과 이를 위한 프로그램기록매체 | |
JP2023516136A (ja) | Ott環境に適した電子支給決済システム及び方法 | |
KR101474386B1 (ko) | 결제 처리 시스템 | |
KR20120054579A (ko) | 원격 거래 승인 방법 | |
KR20090001953A (ko) | 실물상품 선이자 지급을 통한 예금(또는 적금)계좌 운용방법 및 시스템과 이를 위한 기록매체 | |
KR20090002901A (ko) | 대출조건 설정 방법 및 시스템과 이를 위한 프로그램기록매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20110105 |