CN105096106A - 一种利用互联网缴纳学费的系统 - Google Patents

Abstract

本发明提出了一种利用互联网缴纳学费的系统，该系统与用户的终端之间通过互联网通信连接，包括：银行服务器、学校服务器，银行服务器与学校服务器之间通信连接；银行服务器包括：信息接收模块、签名验证模块、支付信息验证模块、款项处理模块，学校服务器包括：身份信息认证模块、缴费信息获取模块、支付订单生成模块。本发明提出的利用互联网缴纳学费的系统具有新颖的架构，该系统利用较低成本解决了学校代收学费问题，节省了人财物的投入，满足了高校对于收取学费的需求，保证了学校数据的安全，同时还方便了学生缴纳学费，提升了学生的体验，收获了社会效益。

Description

一种利用互联网缴纳学费的系统

技术领域

本发明涉及互联网领域，尤指一种利用互联网缴纳学费的系统。

背景技术

我国文化教育高校设立的比较集中，例如，陕西省是全国的文化教育大省。省内高校在校学生逐年增加，多年来交通银行陕西省分行与高校保持紧密合作，与省内将近30多所高校展开了代收学费业务的合作。银行现有代收学费的渠道多属于银行传统业务渠道，包括：人工上门、柜面终端延伸、批量代扣、系统直联、自助通自助缴费、个人网银、手机银行等方式。这些渠道分别存办理业务时间范围受限、缴费场所受限、受理业务的银行卡种类受限、远程教育客户缴费困难等问题，因此急需开拓新的渠道来解除这些限制。

当前，银行作为服务机构，应当紧随用户使用习惯的改变而改变。目前通过B2C平台(商对客电子商务模式，Business-to-Customer)的支付方式之所以没有全面推开，主要难度在于学校的学费金额不确定、学校内外网是物理隔离的(内外网打通资金需求量大、技术复杂、学校推进难度大)。

另外，一些高校也对于缴纳学费提出了以下需求：一是学生携带大量现金或者存有大量现金的银行卡不安全；二是网上学习的学员，遍布全国各地，分支点报名管理不规范，到账时间长，账务核对工作复杂；三是学校的学费金额不确定、学校内外网是物理隔离的；四是学校如果直连第三方支付公司，软件公司需要不断地从学校获取数据，属于非直连模式，对于学校而言，存在数据安全问题，获取信息滞后而且只能进行定额的报名费收缴，无法与学校财务系统对接，在产生缴费行为后，无法实时更新校内学费数据库的数据内容，后期对账、结算麻烦。

发明内容

针对上述问题，当前亟需改进学生缴纳、银行代收学费的方式。例如，通过创新手段实现B2C平台的代缴学费业务，为每个学校提供定制化服务。即银行自建统一的B2C平台，将学校统一接入，从现有的代收学费系统获取缴费信息数据，客户通过学校网站链接到该平台，实现互联网上学费缴存业务的办理。

为达到上述目的，本发明提出了一种利用互联网缴纳学费的系统，该系统与用户的终端之间通过互联网通信连接，包括：银行服务器、学校服务器，该银行服务器与该学校服务器之间通信连接；所述银行服务器包括：信息接收模块、签名验证模块、支付信息验证模块、款项处理模块，所述学校服务器包括：身份信息认证模块、缴费信息获取模块、支付订单生成模块；其中，所述信息接收模块，用于接收所述终端发送的用户身份信息，并将该用户身份信息发送至所述身份信息认证模块；所述身份信息认证模块，用于根据本地存储的身份信息数据库认证所述用户身份信息；所述缴费信息获取模块，用于在认证所述用户身份通过后，获取该用户的缴费信息；所述支付订单生成模块，用于根据所述缴费信息生成支付订单，并利用银行下发的证书对该支付订单进行签名，生成带签名的支付订单发送至所述签名验证模块；所述签名验证模块，用于验证所述带签名的支付订单中的签名合法性，验证合法后，发送所述支付订单至所述终端；所述支付信息验证模块，用于接收所述终端发送的所述支付订单的支付信息，并验证所述支付信息是否正确；所述款项处理模块，用于在验证所述支付信息正确后，从所述支付信息的账户中扣除对应所述支付订单的款项，发送支付结果至所述终端，并将所述款项打入学校的对公账户，发送收款明细至所述学校服务器。

本发明提出的利用互联网缴纳学费的系统具有新颖的架构，该系统利用较低成本解决了学校代收学费问题，节省了人财物的投入，满足了高校对于收取学费的需求，保证了学校数据的安全，同时还方便了学生缴纳学费，提升了学生的体验，收获了社会效益。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1为本发明一实施例的利用互联网缴纳学费的系统结构示意图。

图2示出了本发明的实施方式可以在其中实施的应用场景。

图3为本发明一实施例的利用互联网缴纳学费的系统进行缴费的流程示意图。

具体实施方式

以下配合图示及本发明的较佳实施例，进一步阐述本发明为达成预定发明目的所采取的技术手段。

图1为本发明一实施例的利用互联网缴纳学费的系统结构示意图。如图1所示，该系统包括：银行服务器1、学校服务器2。

银行服务器1与用户的终端3之间通过互联网通信连接，银行服务器1与该学校服务器2之间通信连接。

银行服务器1包括：信息接收模块11、签名验证模块12、支付信息验证模块13、款项处理模块14，学校服务器2包括：身份信息认证模块21、缴费信息获取模块22、支付订单生成模块23；此外，银行服务器1还可以包括：缴费信息接收模块15、确认指令接收模块16。

其中，用户可以利用终端3输入用户身份信息，用户身份信息可以至少包括：学校名称、学号、入学年份。

信息接收模块11，用于接收终端3发送的用户身份信息，并将该用户身份信息发送至身份信息认证模块21。

身份信息认证模块21，用于根据本地存储的身份信息数据库认证用户身份信息。身份信息数据库内存储有学生信息，例如：学号、入学年份等。

缴费信息获取模块22，用于在认证用户身份通过后，获取该用户的缴费信息。缴费信息可以根据学生信息，由学校服务器生成，缴费信息至少包括：缴费年份、缴费名称、以及每一项缴费名称对应的应缴金额。

支付订单生成模块23，用于根据缴费信息生成支付订单，并利用银行下发的证书对该支付订单进行签名，生成带签名的支付订单发送至签名验证模块12。

签名验证模块12，用于验证带签名的支付订单中的签名合法性，验证合法后，发送支付订单至终端3。

支付信息验证模块13，用于接收终端3发送的支付订单的支付信息，并验证支付信息是否正确。该支付信息至少包括：用户的银行卡账户、该账户对应的密码、对应该支付订单的支付款项信息。

款项处理模块14，用于在验证支付信息正确后，从支付信息的账户中扣除对应支付订单的款项，发送支付结果至终端3，并将款项打入学校的对公账户，发送收款明细至学校服务器2。在款项处理模块14处理完支付结果及收款明细后，用户的支付完成。

在本实施例中，缴费信息获取模块22获取该用户的缴费信息后，可以发送至缴费信息展示模块15。

缴费信息展示模块15，用于发送该缴费信息至终端3，通过终端3展示给用户。

用户可以通过终端3确认该缴费信息是否是他应当缴纳的学费。如果确认无误后，用户可以利用终端3发出一确认指令。

确认指令接收模块16，用于接收终端3发送的缴费信息相应的确认指令，并将该确认指令发送至支付订单生成模块23。

支付信息验证模块23，用于在接收到该确认指令后，根据缴费信息生成支付订单。

下面参考图2，其示出了本发明的实施方式可以在其中实施的应用场景。图2中所示的场景包括：用户的终端3、总行DMZ区反向代理服务器101、总行TRS区反向代理服务器102、分行销售平台服务器103、分行核心服务器104、前置服务器105、学校服务器2。

其中，终端3可以是移动终端，例如手机、平板电脑、笔记本电脑、个人数字助理等移动电子设备，也可以是台式电脑等。终端3与总行DMZ区反向代理服务器101之间可以通过移动互联网等进行通信连接。

图1中所示的银行服务器1可以由图2中所示的多个子服务器组成，该些子服务器之间利用银行内部网通信，包括：总行DMZ区反向代理服务器101、总行TRS区反向代理服务器102、分行销售平台服务器103、分行核心服务器104、前置服务器105。图1所示的银行服务器1中的各个模块可以设置于该些子服务器中，银行服务器1所包含的各个模块所实现的功能，可以由该些子服务器实现。

如图2所示，前置服务器105可以设置于学校，通过校内专网路由器与学校服务器2通信连接，双方在防火墙上只打开必要的应用程序端口，双方地址在防火墙上进行地址转换。所有学校的网络接入，都放在银行核心的内部网络架构的物理外联区域。前置服务器105通过运营商专线与分行销售平台服务器103、分行核心服务器104通信连接，用于传输该些子服务器与学校服务器2之间的数据。

分行销售平台服务器103通过银行运营商专线与总行TRS区反向代理服务器102通信连接。总行TRS区反向代理服务器102与总行DMZ区反向代理服务器101通信连接，两者之间的通信是为了将互联网信息接入银行内部网络，同时可以保证银行内部网络的安全。

用户100(例如，想要查询或缴纳学费的学生)可以通过终端3，登录银行网站(或者通过学校网站，链接到总行互联网入口)，选择缴纳学费。由于设置了总行DMZ区反向代理服务器101及总行TRS区反向代理服务器102，终端3发送的数据会通过银行内容进入分行销售平台服务器103。分行销售平台服务器103可以根据用户100输入的身份信息在学校服务器2上查询并获取缴费信息。当用户确认缴费信息后，学校服务器2可以生成相应的支付订单，使用银行发放的商户(学校)证书对订单进行签名，将客户的浏览器重定向至银行支付页面。

分行核心服务器104可以验证商户(学校)证书及签名的有效性。验证通过后，可以在终端3显示支付页面。支付页面上可以包括用户100应缴纳的缴费信息，例如可以包含商户(学校)名称、缴费年份、缴费名称、以及每一项缴费名称对应的应缴金额等信息。

用户100可以通过终端3输入支付的银行卡号及密码等支付信息，分行核心服务器104根据支付订单对用户100的账户进行扣款。

支付成功后，分行销售平台服务器103可以将页面重定向回平台，同时发送支付结果给终端3，并且生成收款明细发送至学校服务器2。

支付模式分为本行网银支付和跨行支付两种模式。本行网银模式即个人开通本行网上支付功能，即可在本行直联商户上进行支付；跨行支付又分为银联直联(即商户直接与银联系统对接，持卡人在商户消费时直接通过银联提供的支付系统完成支付，本行作为收单行仅为商户提供结算账号用于清算。)和银联间联(即商户直接与收单行系统对接，持卡人在商户消费时，通过收单行支付系统转至银联后完成支付，即银联为收单行提供支付业务的服务支撑。)本行作为收单机构，与银联合作提供互联网收单服务，商户只需与本行一家对接，即可支持银联卡的在线支付。

本发明的利用互联网缴纳学费的系统架构新颖，在学校放置前置服务器，通过校内专网路由器与学校财务系统服务器连接，再通过运营商专线与银行系统连接。所有学校统一接入，互联网接入、域名解析全部由总行接入，而实际的服务器是放置在分行内网；业务创新性，通过互联网实现缴费业务的办理，进一步拓宽了银行各类代收费业务的渠道。

在进行数据传输时，双方在防火墙上只打开必要的应用程序端口，对接模式已经固定。双方地址在防火墙上进行地址转换。所有学校的网络接入都放在全行核心网络架构的物理外联区域，保证银行数据安全。

学校可以为银行提供其代收学费数据信息，由银行获取到该信息后，以统一界面展现在银行的各个渠道界面，学生通过身份验证后，确认自己的数据正确无误，即可进行缴费。

该系统在上述应用场景下，具有以下优点：1、交易的安全性高，分行B2C销售平台统一由总行互联网入口接入，采用了总分行联动的模式。2、应用范围广，可以将所有学校统一接入，互联网接入、域名解析全部由总行接入，而实际的服务器是放置在分行内网，与分行核心上学费特色业务接口对接，与总行2.0支付系统对接，平台域名从总行统一申请。3、模式创新性，该平台支持所有银联卡缴费，交学费免注册，客户满意度大力提升。4、业务办理高效，办理业务时间7×24小时，任何可以访问互联网的设备都可以办理。5、与其它网购平台的不同点：该产品不同于普通的网上购物商城，网购商城的产品都是固定价格，大部分商家不存在自身的系统，而是依托网上商城这个平台集中处理交易流程，存在商家、商城、第三方支付公司三层结构，本系统只存在学校系统和银行系统两层机构，交易金额的改变会引起学校财务系统金额的实时改变，保证校方的资金安全和对账方便，支付渠道就是银行自身，具有较高的安全性。

通过对该互联网交易类型的系统进行创新和改造，本发明的系统优势会长期保持领先。一是对现有业务的创新，实现了银行线下支付业务转线上支付的转换。市场规模有限，而银行数量越来越多，银行需要通过对传统业务进行创新，才能在维系原有客户数量的基础上再争取到更多的客户。二是将银行产品渗入到客户系统中，增强客户对银行的依赖和黏性。三是利用这个系统，将传统银行业务转移到互联网上，银行自身风险防控的机制是优于互联网金融的，所以银行自身作为一个支付平台也是优于互联网金融的。四是用互联网的理念和技术将学校系统与银行系统对接，可以实现更多模式上的创新，银行可以实时获取对接后的高校数据。该系统的硬件环境采用分行现有的虚拟机资源，不存在新购设备问题。五是大数据的获取可以为银行后期业务的发展做好铺垫，通过对客户数据进行技术分析，可以寻找到业务发展的突破点。

为了对上述利用互联网缴纳学费的系统进行更为清楚的解释，下面结合一个具体的实施例来进行说明，然而值得注意的是该实施例仅是为了更好地说明本发明，并不构成对本发明不当的限定。

图3为本发明一实施例的利用互联网缴纳学费的系统进行缴费的流程示意图。该流程示意图可以结合图1、2所示的内容来进行说明。如图3所示，流程如下：

步骤S301，用户输入用户身份信息。

步骤S302，接收用户身份信息。

步骤S303，认证该用户身份，如果认证通过，则继续执行步骤S304，如果未通过，则本次缴费失败，需用户重新输入用户身份信息。

步骤S304，获取该用户的缴费信息。

步骤S305，发送该缴费信息至终端，显示给用户。

步骤S306，判断用户是否确认缴费信息，如果用户暂时不考虑缴纳该些费用，则本次缴费失败，如果用户确认缴费信息，则执行步骤S307。

步骤S307，接收确认指令。

步骤S308，根据缴费信息，生成支付订单，并利用银行下发的证书对支付订单进行签名。

步骤S309，验证签名是否合法，如果验证合法，则继续执行步骤S310，如果验证不合法，则缴费失败。

步骤S310，用户输入支付信息。

步骤S311，验证支付信息是否正确，如果正确，则继续执行步骤S312，错误则缴费失败。

步骤S312，扣除支付订单的款项，发送支付结果至终端，并将款项打入学校的对公账户，发送收款明细至学校服务器。至此，支付完成。

本发明提出的利用互联网缴纳学费的系统具有新颖的架构，该系统利用较低成本解决了学校代收学费问题，节省了人财物的投入，满足了高校对于收取学费的需求，保证了学校数据的安全，同时还方便了学生缴纳学费，提升了学生的体验，收获了社会效益。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种利用互联网缴纳学费的系统，该系统与用户的终端之间通过互联网通信连接，其特征在于，包括：银行服务器、学校服务器，该银行服务器与该学校服务器之间通信连接；所述银行服务器包括：信息接收模块、签名验证模块、支付信息验证模块、款项处理模块，所述学校服务器包括：身份信息认证模块、缴费信息获取模块、支付订单生成模块；其中，

所述信息接收模块，用于接收所述终端发送的用户身份信息，并将该用户身份信息发送至所述身份信息认证模块；

所述身份信息认证模块，用于根据本地存储的身份信息数据库认证所述用户身份信息；

所述缴费信息获取模块，用于在认证所述用户身份通过后，获取该用户的缴费信息；

所述支付订单生成模块，用于根据所述缴费信息生成支付订单，并利用银行下发的证书对该支付订单进行签名，生成带签名的支付订单发送至所述签名验证模块；

所述签名验证模块，用于验证所述带签名的支付订单中的签名合法性，验证合法后，发送所述支付订单至所述终端；

所述支付信息验证模块，用于接收所述终端发送的所述支付订单的支付信息，并验证所述支付信息是否正确；

所述款项处理模块，用于在验证所述支付信息正确后，从所述支付信息的账户中扣除对应所述支付订单的款项，发送支付结果至所述终端，并将所述款项打入学校的对公账户，发送收款明细至所述学校服务器。

2.如权利要求1所述的利用互联网缴纳学费的系统，其特征在于，所述银行服务器还包括：缴费信息接收模块、确认指令接收模块；其中，

所述缴费信息展示模块，用于接收所述缴费信息，并发送至所述终端展示给所述用户；

所述确认指令接收模块，用于接收所述终端发送的所述缴费信息相应的确认指令，并将该确认指令发送至所述支付订单生成模块；

所述支付信息验证模块，用于在接收到该确认指令后，根据所述缴费信息生成支付订单。

3.如权利要求1所述的利用互联网缴纳学费的系统，其特征在于，所述用户身份信息至少包括：学校名称、学号、入学年份。

4.如权利要求1或2所述的利用互联网缴纳学费的系统，其特征在于，所述缴费信息至少包括：缴费年份、缴费名称、以及每一项所述缴费名称对应的应缴金额。

5.如权利要求1所述的利用互联网缴纳学费的系统，其特征在于，所述支付信息至少包括：所述用户的银行卡账户、该账户对应的密码、以及支付款项的信息。