基于hvps系统的第三方支付平台缴费系统和方法

文档序号:6578234阅读:915来源:国知局
专利名称:基于hvps系统的第三方支付平台缴费系统和方法
技术领域
本申请涉及一种缴费系统和方法,尤其涉及一种基于HVPS系统(大额实 时支付系统,High Value Payment System ),且通过第三方支付平台进行网上 缴费的系统和方法。
背景技术
目前,我们的公共事业缴费种类繁多,比如公共交通、邮政、电讯、城 市供水排水、热力、供电、供气等收费。面对如此繁多的缴费种类,然而各
地公共事业单元的营业网点分布较少,从而导致了公共事业缴费困难的问题。 银行代收业务也就应运而生,但是各个银行所签约的公共事业单位各不相同, 比如A银行只签约了热力和供电,而B银行签约了供气,因而缴费仍然不能统 一,再加上目前传统的缴费业务更多的在银行拒面系统进行,大大占用银行 拒面宝贵资源的同时,用户缴费过程也变得繁杂。
中国人民银行推出央行小额支付系统。通过这个系统,用户只要在任何 一家银行开一个账户,便能够完成所有水、电、煤气、电话费以及养老、医 疗险等的缴费。付款单位也通过这个系统,向在不同银行开户的收款人办理 工资、津贴和社保资金的发放。如果大力推广,部分银行网点面临的排队压 力将得以缓解。但是,目前,该系统推广却存在很大的阻力,除了央行和各 家银行之间的利益分配存在不合格而使得各家银行的推广不积极之外,还有 技术上的问题也使得推广受阻在小额支付系统推广上线以前,各银行之间 跨行的汇兑业务大多依靠银行之间的同城清算系统来实现,而跨行的取款和 刷卡业务,则可以由银联来实现。小额支付系统的应用,完全覆盖了同城清 算系统的功能,也覆盖了一部分锒行卡支付的功能。于是,对于已经建设起 了行与行之间同城清算系统的各大银行而言,再建一个小额支付平台,是一 种资源上的重复和浪费。即使小额支付系统能达到推广,但是,在实现支付过程中依然存在技术
问题小额支付的特点是笔数多、金额小、涉及的银行多。以水费为例,各 家银行都需登录至自来水公司提供的缴费系统进行缴费操作,再把收到的钱 打入自来水公司在某家银行开的账户中。请参阅图l,其为水公司系统缴费的 一实施原理图。水公司系统11与各个签约银行12连接,用户通过各个签约银 行12缴纳水费,签约银行12将缴纳的水费转账至开设有水公司结算账户的结 算银行13对应的结算账户中。结算银行13可以是签约银行12中的一家。
由于不能预测用户通过哪家银行来进行缴费,因此需要各家银行都需与 自来水公司的缴费系统连接,各家收到钱的银行定周期将费用打入该自来水 公司在某家银行(称之为开户行)开的账户中,并且该些收款的银行需要与 结算银行完成每笔资金清算。这种操作模式,大量占用各家银行包括网络在 内的资源,造成整个小额支付系统实现支付成本很高。
也就是说,上述的支付模式,存在以下的问题
1、 这些签约银行在接收到不同用户缴纳水费的申请时,会与水公司系统 建立链接并读取相关信息,由于会建立N条链接,因此,会给水公司系统造成 较大负担。
2、 用户缴纳完费用后,这些签约银行需要与结算银行、水公司系统进行 清算操作,这种操作模式,大量占用各家银行包括网络在内的资源,造成整 个小额支付系统实现支付成本很高。

发明内容
针对上述缺陷,本申请的思想在于提供一种基于HVPS系统的第三方支 付平台缴费系统,以解决现有技术中现有利用第三方缴费平台来完成自动缴 费功能实现复杂、可操作性差的技术缺陷。
本申请的另一思想在于,提供一种基于HVPS系统的第三方支付平台缴 费系统,以解决现有技术中现有利用第三方缴费平台来完成自动缴费功能实 现复杂、可操作性差的技术缺陷。
一种基于HVPS系统的第三考支付平台缴费系统,包括至少 一服务提供单位缴费平台,用于提供用户需缴费用信息;
第三方支付平台,分别连接每一服务提供单位缴费平台和用户,用于接 收用户的缴费请求,实时登录至对应服务提供单位缴费平台获得对应的需缴 费用信息或是查找预先存储的由服务提供单位缴费平台提供的需缴费用信 息从中获得用户对应的需缴费用信息,后进行对应的扣款处理,并对已缴费
用按服务提供单位为单元分类整合;
资金托管机构,连接所述第三方支付平台,用于接收第三方支付平台支 付的按服务提供单位为单元分类后的已缴总费用;
销账机构,通过HVPS网络连接至所述资金托管机构,其有服务提供单 位开设的账户,用于在对应的账户上接收资金托管机构转交过来的已缴总费 用。
一种基于HVPS系统的第三方支付平台缴费方法,其通过一第三方支付 平台将各种缴费在网上予以支付,包括如下步骤
步骤(1 )第三方支付平台接受用户的缴费申请,并进行扣款处理。 步骤(l)第三方支付平台接受用户的缴费申请后还包括实时登录至对应 服务提供单位缴费平台获得对应的需缴费用信息,或查找预先存储的由服务 提供单位缴费平台提供的需缴费用信息从中获得用户对应的需缴费用信息。
再判断所述用户是否是第三方支付平台的注册用户,如果不是,则先完 成注册步骤,建立所述用户账户信息,再进行A2,否则直接进行步骤A2; A2:第三方支付平台判断用户账户中的金额是否大于等于该用户需缴纳的费 用,若是,则进行扣款处理,否则,提示用户进行向所述账户充值的步骤, 充值成功,则重新进行A2步骤,充值不成功,则结束缴费操作。
步骤(2)第三方支付平台将处理完的缴纳费用通过所述资金托管机构利用 HVPS网支付至各个服务提供单位在所述销账机构上开设的对应的结算账户。
步骤(2)进一步包括
(2-l)第三方支付平台定期将已处理的缴纳费用汇总,并将该些已缴纳费 用以服务提供单位为单元进行分类汇总;
8(2-2)资金托管机构将汇总后的总缴纳费用从打款账户中进行扣款,所述 打款账户存放有第三方支付平台在所述资金托管机构上存储的储备资金;
(2-3)资金托管机构将扣除的总缴纳费用通过HVPS专网转帐至对应销帐 机构的HVPS清算账户;
(2-4)销帐机构从HVPS清算账户入账至目标帐户后再分流入账至各个服 务提供单位的结算账户。
和现有技术相比,本申请的缴费系统具有如下优点
首先,各家服务提供单位只需要与第三方支付平台通过网络或专线建立 通信,不需要与各家银行建立通信,由此节省了大量的接口,不仅实现起来 方便,而且维护方便,降低了成本。
接着,本申请利用HVPS网络进行已缴费总费用的转账,速度快且安全 系数高,更为重要的是无需占用各家银行的大量资源,也就是说,第三方支 付平台与各个服务提供单位进行对账销账,资金托管机构和销账机构完成的 是总支付金额的一个转账和对账工作,处理速度快且不需要占用过多的银行 资源。
最后,用户只需要利用网络即可完成各种费用的缴费操作,无需跑任何 一家银行,实现方便,灵活,具有极强的可操作性和便利性。


图l为为水公司系统缴费的一实施原理图2为本申请一基于HVPS系统的第三方支付平台缴费系统结构图3为本申请实施例的 一 第三方支付平台的结构图4为本申请实施例的 一用户缴费服务器的结构图5为本申请实施例的 一 资金托管机构的结构图6为本申请实施例的一企业网银前置服务器的结构图7为本申请实施例的 一销帐机构的结构9图8为本申请一种基于HVPS系统的第三方支付平台缴费方法的原理流程
图9为本申请一种基于HVPS系统的第三方支付平台缴费方法的示例流程图。
具体实施例方式
本申请的核心在于在基于HVPS系统的基础上,第三方支付平台在只 需设立 一个资金托管机构账户即可为用户提供高效、便捷且覆盖面极大的网 上缴费。本申请所称资金托管机构既包括各类银行,也包括信用社;本申请 所称网上缴费主要指公共事业缴费,如公共交通、邮政、电讯、城市供水排 水、热力、供电、供气等,但并不排除其它需要在多个银行进行资金转移的 应用。
人民银行的HVPS系统是一个实时全额清算系统,建立该系统的目的, 是为了给银行和广大企事业单位的金融市场提供快速、高效、安全的支付清 算服务,防范支付风险。它对中央^l行更加灵活、有效地实施货币政策具有 重要作用。该系统处理同城和异地的、金额在规定起点以上的大额货记支付 业务和紧急小额货记支付业务,其处理的支付业务种类包括汇兌、委托收 款划回、中央银行和国库部门办理的资金汇划,以及公开市场操作室和债券 交易的即时转账等。该系统覆盖面广,其包括了全国范围内的商业银行、信 用社、四大国有银行。HVPS系统具有实时、且能大额支付的功能,因此,本 发明采用HVPS系统进行费用支付,也具有支付速度快、安全等技术效果。
第三方支付平台,以支付宝为例,已建立起成熟的网上支付模式。用户 只需要有一个第三方支付平台的用户账户即可完成对应的扣款处理。当用户 账户余额不够时,可以通过现有的支付模式(如利用网上银行、汇款等)对 对应的用户账户进4亍扣4欠处理。
本申请就是利用现有的HVPS系统和第三方支付平台完成用户的缴费处 理。在对本申请进行详细阐述前,需要明确几个账户概念
打款账户第三方支付平台在资金托管机构设立的用以存储备付资金的账户;
资金托管机构的HVPS清算账户用以接收打款账户中扣除的金额,并 将之发送至销帐机构的HVPS清算账户;
销帐机构的HVPS清算账户接收资金托管机构的HVPS清算账户发送 的信息,并将相应的款打至目标账户;
目标账户销帐机构用以临时存储各种缴费的过渡账户;
服务单位结算账户各个服务单位在销帐机构内设立的用以对其服务进 行销帐的账户,是本申请中资金流动的最终账户。
本申请提出一种基于HVPS系统的第三方支付平台缴费系统,用以为用 户提供便捷高效的网上缴费服务,请参见图2,其为本申请一基于HVPS系统 的第三方支付平台缴费系统结构图。该系统包括至少一服务提供单位缴费 平台、第三方支付平台310、用户350、资金托管才几构320、通过HVPS系统 330与资金托管机构320连接的销帐机构340。
至少一服务提供单位缴费平台,用于提供用户需缴费用信息。如供水平 台360、供电平台370。
第三方支付平台310,其是一些和国内外各大银行签约、具备一定实力和 信誉保障的第三方独立机构提供的交易支付平台,比如支付宝。第三方支付
平台310可以通过网络连接每一服务提供单位缴费平台和用户350,用于接收 用户350的缴费请求,实时登录至对应服务提供单位缴费平台获得对应的需 缴费用信息或是查找预先存储的由服务提供单位缴费平台提供的需缴费用信 息,从中获得用户对应的需缴费用信息后进行对应的扣款处理,并对已缴费 用按服务提供单位为单元分类整合。在本实例中,第三方支付平台310在资 金托管机构320开设有用以存储备付资金的打款账户,资金托管机构320可 以根据第三方支付平台310的指令从该打款账户中扣除一定金额并转入其它 账户。当然,第三方支付平台310也可以将对应的已缴纳的费用总和打入资 金托管机构320对应的账户中。
HVPS专网330是人民银行为HVPS系统专门铺设的专线网络;销帐机构340是和服务提供单位进行销帐的各类银行和信用所,服务提供单位在该销帐 机构340开设有账户。第三方支付平台310通过因特网和资金托管机构320 相连,而资金托管机构320则通过HVPS专网330和销帐才几构340进4亍连通。
第三方支付平台310是直接面向用户端的,请参见图3,其为本申请实施 例的一第三方支付平台的结构图,其包括用户缴费服务器311、缴费数据库 312及企业网银客户端313。该缴费数据库312连接至用户缴费服务器311, 用户缴费服务器311用以接受并处理用户的缴费申请,并将这些申请及其对 应的处理结果存入缴费数据库312。企业网银客户端313是第三方支付平台 310为了与资金托管机构320进行交互而设置的,其和用户缴费服务器311相 连,这种连接可以是直接的,也可以是间接的。当企业网银客户端313和用 户缴费服务器311直接相连时,该第三方支付平台310可以实现自动通过企 业网银客户端313向资金托管机构320发起大额支付申请的功能(如图3所 示),而企业网《艮客户端313和用户缴费服务器311间接相连时,它们之间需 通过操作员对相关数据进行审核后再控制企业网银客户端313向资金托管机 构320发起大额支付申请。企业网银客户端313主要是负责建立第三方支付 平台310和资金托管机构320之间的安全交互。
更具体的说,上述用户缴费服务器3U进一步包括用户接口单元3111、 缴费处理单元3112和缴费管理单元3113,且它们依次相连,请参见图4。用 户在用户终端根据第三方支付平台310提供的缴费申请界面输入相应的缴费 信息,该些信息可以包括地区、交费项目、收费单位,账单上的条形码编码 和金额等,而用户接口单元3111则负责收集该些信息并存入缴费数据库312 内。用户的缴费类型、金额和缴费地点等都种类繁多,所以需要缴费管理单 元3113对该些繁杂的数据加以管理,缴费管理单元3113可以将该些数据分 门别类加以存储, 一般来说,可以将用户的缴费类型、地点、时间分为一类 并制成相应的缴费明细表类存储在缴费数据库312内,这样可以在很大程度 上方便后续大额支付申请的提交。缴费处理单元3112用以处理用户输入的缴 费信息,包括将需要缴纳的费用进行扣款处理。缴费处理单元3112主要是完 成在对应账户上进行扣款处理操作,并将扣款处理的结果保存至缴费数据库312中。
还请参阅图3,缴费数据库312进一步包括
缴费记录存储单元3121:用于存储每一笔用户输入的缴费信息,并保存 其对应的处理结果。缴费记录存储单元3121可以以交易笔数为单元,存储每 一交易笔数的用户信息及交易结果。
缴费记录分类存储单元3122:用于将已缴纳的费用信息分类整合后的分 类信息进行存储。缴费记录分类存储单元3122可以以各个服务提供单位为单 元制作各种缴费记录单,缴费记录单上可以只保存定期(如每天、每个星期 或每个月)的缴费记录及缴费总额度。服务提供单位可以是以各家总的服务 提供商为单位,如管水费的供水公司、管电费的电力公司。服务提供单位也 可以是以各家各地方的服务提供商为单位,如管水费的浙江供水公司、管水 费的上海供水公司等。以便后续对账处理。
缴费数据库312还可以包括需缴费用信息存储单元(图未示),当接收用 户350的缴费请求,实时登录至对应服务提供单位缴费平台获得对应的需缴 费用信息时,就无需在缴费数据库312中设置需缴费用信息存储单元。考虑 到实时去获取数据有一定的延时性,也可通过需缴费用信息存储单元保存由 服务提供单位缴费平台提供的需缴费用信息,当接收到用户的缴费请求时, 可以从中获得用户对应的需缴费用信息。
第三方支付平台310通常还包括
用户信息存储单元3123,用于存储包括用户账户信息在内的用户信息。 用户建立账户的时间、账户对应的密码、账户的交易情况、该用户的信用等级等。
所述缴费处理单元3112还进一步包括
扣款处理子单元用于在对应的用户账户中扣除对应的需缴纳费用。比 如,当接收到用户的缴费请求时,,先判断该用户是否是注册用户,如果不是, 则先进行用户注册步骤,如果是,则进行用户登录操作,再进行扣款处理。 用户注册包括建立用户账户信息。扣款处理包括判断用户账户内的金额是否大于等于需缴纳的费用,如果是,则进行扣款处理,如果否,则提示用户 进行账户的充值处理。所述充值处理包括用户通过网上银行或邮局汇款等对 用户账户进行充值处理。只有当账户上的金额大于等于需缴纳的费用时,才 进行扣款处理。
缴费触发处理子单元,用于接收用户350的缴费请求,实时登录至对应 服务提供单位缴费平台获得对应的需缴费用信息,或者访问需缴费用信息存 储单元从中获得用户对应的需缴费用信息。
请参见图5,其为本申请实施例的一资金托管机构的结构图。该资金托管 机构320包括第一HVPS前置服务器321、企业网银前置服务器322、第一核 心服务器323、第一数据库324和第一行内转帐服务器325,其中,第一HVPS 前置服务器321和企业网银前置服务器322、第一核心服务器323和第一数据 库324之间通过行内LAN进行相互之间的通信和数据传递,而第 一行内转巾艮 服务器325则既可以是独立于第一核心服务器323但与其连通的物理服务器, 同时也可以是第一核心服务器323内的一个子系统。
企业网银前置服务器322和上述企业网银客户端313相对应,其和企业 网银客户端313通过因特网相连,用以接收企业网银客户端313发出的包括 大额支付申请在内的各种请求,以及反馈各种信息至企业网银客户端313,如 回单信息等,在本申请中,企业网银前置服务器322还有一个重要作用,就 是对企业网银客户端313发送的大额支付申请的数据进行预处理,验证其合 法性。该验证过程可以是通过验证第三方支付平台方面发起大额支付申请时 输入的帐号密码是否匹配以及大额支付申请的金额是否小于其打款账户内的 金额等来进行的。企业网银前置服务器322具体来说可以包括如下部分企 业接口单元3221、预处理单元3223和资金托管机构接口单元3222,且它们 依次相连(请参见图6)。企业接口单元3221负责和企业网4艮客户端313之间 的通信,其将接收的信息送至预处理单元3223进行数据验证,经过验证后的 数据再送至资金托管机构接口单元3222以进入第一核心服务器323。
第一核心服务器323是资金托管机构320的主服务器,其负责各种搡作 的调度调配,在本申请中,其接收到由企业网银前置服务器322转发过来的由第三方支付平台310提出的大额支付申请,控制行内转帐服务器325将第
然后再组成对应的支付报文转交至第一HVPS前置服务器321,由第一HVPS 前置服务器321转交至对应的销账机构340。第一核心服务器321可以直接将 第三方支付平台打款账户中的相应金额打入资金托管机构的HVPS清算账户。 第一 HVPS前置服务器321是HVPS系统在资金托管机构320的接入点, 其通过HVPS专线直接和人民银行的HVPS系统相连,因此其具有很高的安 全性。第一HVPS前置服务器321接收到第一核心服务器323的处理请求后, 即按照HVPS系统的统一接口标准,向人民银行HVPS系统发起大额支付请 求。
第一数据库324用以存储上述各个服务器操作中所涉及的各种数据,比 如企业网银前置服务器322所转交过来的大额支付申请中的各种费用明细数
据等等。
请参见图7,其为本申请实施例的一销帐机构的结构图。该销帐机构340 包括第二HVPS前置服务器341、第二核心服务器342、第二数据库343和第 二行内转帐服务器344,其中,第二HVPS前置服务器341、第二核心服务器 342和第二数据库343之间通过行内LAN进行相互之间的通信和数据传递, 而第二行内转帐服务器344则既可以是独立于第二核心服务器342但与其连 通的物理服务器,同时也可以是第二核心服务器342内的一个子系统。
第二 HVPS前置服务器341同样通过HVPS专线连接至人民银行HVPS 系统,其接收人民银行HVPS系统转发的来自资金托管机构320的大额支付 请求,并对请求数据进行预处理,验证其合法性,如果数据合法,则递交该 信息至第二核心服务器342进行处理。第二核心服务器342通过行内LAN收 到该支付报文信息后,根据信息中的打款金额控制第二行内转帐服务器344 从销帐机构的HVPS清算账户中扣款,并入账至销帐机构的收款账户,此时 大额支付过程结束。销帐机构只需再将收款账户中的金额通过行内转帐系统 分流入账至各个服务提供单位的结算账户即可。第二数据库343也同样用以 存储上述各个服务器操作中所涉及的各种数据。需要说明的是,第三方支付平台310可以将缴费记录分类存储单元3122和缴费记录存储单元3121存储 的信息(如缴费记录单、缴费记录分类记录单等)直接发送至各个服务提供 单位,也可以通过HVPS专网发送至各个服务提供单位。
需要说明的是,资金托管机构可以和销账机构是同一家银行,也可以是 不同的银行。
基于上述系统,本申请又提出一种基于HVPS系统的第三方支付平台缴 费方法,其通过统一的第三方支付平台将各种缴费在网上予以支付,请参见 图8,其为本申请一种基于HVPS系统的第三方支付平台缴费方法的原理流程 图,该方法包括如下步骤
S310:第三方支付平台接受若干用户的缴费申请,并进行扣款处理。
第三方支付平台接受用户的缴费申请后,实时登录至对应服务提供单位 缴费平台获得对应的需缴费用信息,或查找预先存储的由服务提供单位缴费 平台提供的需缴费用信息从中获得用户对应的需缴费用信息。
并且,可以直接将用户需缴纳的费用从用户提供的银行账户中进行扣款 操作,但是考虑到资金的安全管理,第三方支付平台可以在本端建立用户的 账户信息,对所述用户的账户进行对应的充值操作,后对充值后的账户进行 对应的扣款处理。如果是采用这种方式,则具体的扣款操作为
Al:第三方支付平台接受用户的缴费申请时,判断所述用户是否是第三方 支付平台的注册用户,如果不是,则先完成注册步骤,建立所述用户账户信 息,再进行A2,否则直接进行步骤A2;
A2:第三方支付平台判断用户账户中的金额是否大于等于该用户需缴纳 的费用,若是,则进行扣款处理,否则,提示用户进行向所述账户充值的步 骤,充值成功,则重新进行A2步骤,充值不成功,则结束缴费操作。
S320:第三方支付平台将处理完的缴纳费用汇总后通过所述资金托管机 构利用HVPS网支付至各个服务提供单位在所述销账机构上开设的对应的结 算账户。
步骤S320进一步包括
16(2-1 )第三方支付平台定期将已处理的缴纳费用汇总,并将该些已缴纳费
用以服务提供单位为单元进行分类汇总。第三方支付平台向资金托管机构中 发送的数据包中至少包括本次已缴纳的费用总和,当然,第三方支付平台向
的费用总和。
(2-2)资金托管机构将汇总后的总缴纳费用从打款账户中进行扣款,所
(2-3)资金托管机构将扣除的总缴纳费用通过HVPS专网转帐至对应销帐 机构的HVPS清算账户;
(2-4)销帐机构从HVPS清算账户入账至目标帐户后再分流入账至各个服 务提供单位的结算账户。
得各个服务提供单位的本次已缴纳的费用总和,将对应的费用分流入账至对 应的服务提供单位的结算账户.中。
以下就举一个具体的应用例来说明(请参阅图9)。
S410:第三方支付平台预先和资金托管机构进行双方安全通信的约定;也 就是说第三方支平台和资金托管机构之间交互的数据安全性预先进行处理, 比如,第三方支付平台预先部署资金托管机构的企业网银客户端、硬件证书 以及操作员、复核员的用户及密码。企业网银客户端和硬件证书是为了使第 三方支付平台和资金托管机构之间的交互通信更为安全,操作员和复核员用 户和密码的设置是为了对大额支付申请过程加以人工干涉,保证其准确性,
需要指出的是,该复核员既可以是现实的人,也可以是系统中的一个虚拟用 户,其才喿作由系统自动完成。
S420:第三方支付平台为用户提供一缴费页面,引导用户输入相关的缴费 信息和完成付款操作,该些缴费信息可以包括地区、交费项目、收费单位, 账单上的条形码编码和金额等,并将收集到的该些信息加以整理,输入至一 预先设定的缴费明细表予以存储。第三方支付平台根据当日所有缴费用户的缴费明细表并经由企业网银客 户端向资金托管机构提交大额支付申请,在该大额支付申请被送出前,需要 经过第三方支付平台的复核员复核通过。第三方支付平台向资金托管机构提 交大额支付申请的时间可以是以天为周期,也可以是以周为周期等等,这都 可以是预先约定的。
S430:资金托管机构接收上述来自第三方支付平台的大额支付申请,并对 该申请的相关数据进行预处理以验证其合法性,该-验证过程可以是通过验证 第三方支付平台方面发起大额支付申请时输入的帐号密码是否匹配以及大额 支付申请的金额是否小于其打款账户内的金额等来进行。
企业网银前置系统将通过验证后的申请通过行内LAN (局域网)送至资 金托管机构的核心系统,核心系统根据该申请令行内转帐系统从第三方支付 平台的打款账户内扣除相应的金额至资金托管机构的HVPS清算账户。然后 核心系统再将该大额支付申请转交至资金托管机构的HVPS前置系统进行处 理。
资金托管机构的HVPS前置系统收到核心系统的处理请求后,其按照人 民银行HVPS系统的统一接口标准,通过HVPS专网向人民银行HVPS系统 发起大额支付请求。HVPS系统首先根据该请求匹配对应的销帐机构,然后将 该请求转发至该对应的销帐机构,同时将金额从资金托管机构的HVPS清算 账户转入销帐^M勾的HVPS清算账户。
S440:销帐机构的HVPS前置系统收到上述转发的大额支付请求后,先对 该请求进行预处理,验证其合法性,然后递交请求至销帐机构的核心系统, 核心系统根据该申请令行内转帐系统从销帐机构的HVPS清算账户中扣除相 应的金额至目标账户。最后再将该目标账户内的金额分流入账至各个服务提 供单位的结算账户,从而完成整个大额清算过程。
综上所述,和现有技术相比,本申请的缴费系统具有如下优点
1、本申请通过第三方支付平台在网上来完成各种缴费,尤其是公共事业 缴费,避免了过多的占用银行拒面资源,同时也方便了用户,节省了用户的 宝贵时间。2、 本申请是基于人民银行的HVPS系统的,所以其覆盖面相当广,涵盖 了全国范围内的商业银行、信用社和四大国有银行,可以支持缴费事业的后 续业务拓展。另外大额支付系统与各银行业机构的行内系统直接连接,实现 了从发起行到接收行全过程的自动化处理,实行逐笔发送,实时清算, 一笔 支付业务不到l分钟即可到账,加快了资金清算速度。
3、 本申请只需在一个资金托管机构办理账户,大大降低了账户管理的成本。
以上公开的仅为本申请的几个具体实施例,但本申请并非局限于此,任 何本领域的技术人员能思之的变化,都应落在本申请的保护范围内。
权利要求
1、一种基于HVPS系统的第三方支付平台缴费系统,其用户利用一第三方支付平台将各种需缴纳的费用通过HVPS系统进行支付,所述HVPS系统包括通过HVPS专网连接的资金托管机构和用以和各个服务提供单位进行销账的销账机构,所述第三方支付平台连接用户和所述资金托管机构,其进一步包括用户缴费服务器用于接收并处理用户的缴费申请,并将处理完的已缴纳费用汇总后通过所述资金托管机构支付至各个服务提供单位在所述销账机构上开设的对应结算账户;缴费数据库连接至用户缴费服务器,用于保存包括用户缴费数据在内的数据,以完成与各个服务提供单位的对账处理。
2、 如权利要求l所述的系统,其特征在于,所述用户缴费服务器进一步 包括用户接口单元用以接收用户输入的缴费信息;缴费处理单元与用户接口单元相连,用以处理用户输入的缴费信息, 包括将需要缴纳的费用进行扣款处理;所述缴费管理单元,与缴费处理单元相连,用以将已缴费信息进行分类 整合。
3、 如权利要求1或2所述的系统,其特征在于,所述缴费数据库进一步 包括缴费记录存储单元用于存储每一笔用户输入的缴费信息,并保存其对 应的处理结果;缴费记录分类存储单元用于将已缴纳的费用信息分类整合后的分类信 息进行存储。
4、 如权利要求3所述的系统,其特征在于,所述系统还包括用于保存用 户需缴费用信息的各个服务提供单位缴费平台,所述服务提供单位缴费平台 通过网络或专线连接至第三方支付平台。
5、 如权利要求4所述的系统,其特征在于,缴费数据库进一步包括需缴费用信息存储单元,用于保存定期从所述服务提供单元缴费平台获 得用户需缴费用信息。
6、 如权利要求4所述的系统,其特征在于,所述缴费处理单元进一步包括缴费触发处理子单元用于当接收到用户的缴费请求后,连接至对应的 服务提供单位缴费平台,获得用户需缴纳的费用信息。
7、 如权利要求2所述的系统,其特征在于,所述缴费处理单元进一步包 括扣款处理子单元用于在对应的用户账户中扣除对应的需缴纳费用。
8、 如权利要求l所述的系统,其特征在于,所述资金托管机构进一步包括第一 HVPS前置服务器,用于建立与销账机构的安全信息交互;第一核心服务器,用于处理第三方支付平台发送的支付请求,并将已缴 纳的金额发送至销账机构第一数据库,用于存储支付请求的处理结果。
9、 如权利要求8所述的系统,其特征在于,所述资金托管机构还包括第 一行内转账服务器,连接第一核心服务器,用于完成将已缴纳的金额从打款 账户中进行扣除处理,所述打款账户为第三方支付平台开设在所述资金托管 才几构的账户。
10、 如权利要求l所述的系统,其特征在于,所述销帐机构包括 第二 HVPS前置服务器,用于建立与资金托管机构的安全信息交互 第二核心服务器,用于将已缴纳的金额支付至各个服务提供单位在本端上开设的对应结算账户第二数据库,用于存储每一笔的支付记录。
11、 如权利要求10所述的系统,其特征在于,所述销账机构还包括第二 行内转账服务器,连接至第二核心服务器,用于在第二核心服务器的控制下 完成对应金额分别打入对应的结算账户操作。
12、 一种基于HVPS系统的第三方支付平台缴费系统,其特征在于,包括至少一服务提供单位缴费平台,用于提供用户需缴费用信息;第三方支付平台,分别连接每一服务提供单位缴费平台和用户客户端, 用于接收用户的缴费请求,实时登录至对应服务提供单位缴费平台获得对应 的需缴费用信息或是查找预先存储的由服务提供单位缴费平台提供的需缴费 用信息,从中获得用户对应的需缴费用信息后进行对应的扣款处理,并对已 缴费用按服务提供单位为单元分类整合;资金托管机构,连接所述第三方支付平台,用于接收第三方支付平台支 付的按服务提供单位为单元分类后的已缴总费用;销账机构,通过HVPS网络连接至所述资金托管机构,其有服务提供单 位开设的账户,用于在对应的账户上接收资金托管机构转交过来的已缴总费 用。
13、 一种基于HVPS系统的第三方支付平台缴费方法,其通过一第三方 支付平台将各种缴费在网上予以支付,包括如下步骤(1傳三方支付平台接受若干用户的缴费申请,并进行扣款处理;(2傳三方支付平台将处理完的缴纳费用汇总后通过所述资金托管机构利用HVPS网支付至各个服务提供单位在所述销账机构上开设的对应的结算账户。
14、 如权利要求13所述的方法,其特征在于,步骤(l)第三方支付平台 接受用户的缴费申请后还包括实时登录至对应服务提供卑位缴费平台获得对应的需缴费用信息,或查找预先存储的由服务提供单位缴费平台提供的需缴费用信息从中获得 用户对应的需缴费用信息。
15、 如权利要求13所述的方法,其特征在于,步骤(2)进一步包括 (2-l)第三方支付平台定期将已处理的缴纳费用汇总,并将该些已缴纳费用以服务提供单位为单元进行分类汇总;(2-2)资金托管机构将汇总后的总缴纳费用从打款账户中进行扣款,所述 打款账户存放有第三方支付平台在所述资金托管机构上存储的储备资金;(2-3)资金托管机构将扣除的总缴纳费用通过HVPS专网转帐至对应销帐 机构的HVPS清算账户;(2-4)销帐机构从HVPS清算账户入账至目标帐户后再分流入账至各个服 务提供单位的结算账户。
16、 如权利要求13所述的方法,其特征在于,步骤(l)中第三方支付平台 向资金托管机构提交的大额支付申请先进行数据预处理,验证其合法性,所 述验证过程进一步包括通过验证第三方支付平台发起大额支付申请时输入 的帐号密码是否匹配以及大额支付申请的金额是否小于其打款账户内的金 额。
17、 如权利要求13或14所述的方法,其特征在于,步骤(l)还包括Al:第三方支付平台接受用户的缴费申请时,判断所述用户是否是第三方 支付平台的注册用户,如果不是,'则先完成注册步骤,建立所述用户账户信 息,再进行A2,否则直接进行步骤A2;A2:第三方支付平台判断用户账户中的金额是否大于等于该用户需缴纳 的费用,若是,则进行扣款处理,否则,提示用户进行向所述账户充值的步 骤,充值成功,则重新进行A2步骤,充值不成功,则结束缴费操作。
全文摘要
一种基于HVPS系统的第三方支付平台缴费系统,包括第三方支付平台、资金托管机构、销帐机构和HVPS专网,其中,第三方支付平台通过网络和资金托管机构相连,而资金托管机构则通过所述HVPS专网和销帐机构相连。本申请的缴费系统通过第三方支付平台来完成各种缴费,避免了过多的占用银行柜面资源,节省了用户的宝贵时间。另外由于本申请是基于人民银行的HVPS系统的,所以其覆盖面相当广,涵盖了全国范围内的商业银行、信用社和四大国有银行,可以支持缴费事业的后续业务拓展。
文档编号G06Q20/14GK101540032SQ20091014051
公开日2009年9月23日 申请日期2009年4月30日 优先权日2009年4月30日
发明者亮 张 申请人:阿里巴巴集团控股有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1