技术领域
[0001] 本发明涉及网络支付技术领域，尤其涉及一种学费监管系统。
相关背景技术
[0002] 为了加强对培训机构的学费监管，需要一种资金监管系统，目前B/S结构的资金监管系统在与各类大小合作企业对接时，需要将B/S系统与第三方实际业务场景融合在一起改造，成本高，工期长，仅能完成少量的对接；另外，目前现有的支付方式都是下单后直接转账，缺乏有效的监管。
具体实施方式
[0014] 为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。
[0015] 在本说明书的描述中，所使用的“包含”、“包括”、“具有”、“含有”等，均为开放性的用语，即意指包含但不限于。参考术语“一个实施例”、“一个具体实施例”、“一些实施例”、“例如”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。各实施例中涉及的步骤顺序用于示意性说明本申请的实施，其中的步骤顺序不作限定，可根据需要作适当调整。
[0016] 这里先对本发明实施例涉及到的术语进行解释。
[0017] 范式：数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入(insert)、删除(delete)和更新(update)操作异常。
[0018] BC范式：鲍依斯-科得范式(BCNF)，在第三范式的基础上，消除主属性对于码的部分依赖，或传递函数依赖。
[0019] 外键(Foreign Key)：表示了两个关系之间的相关联系，以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称为主表的从表，外键又称作外关键字。
[0020] B/S结构：表示broswer浏览器和server服务器架构。一般由用户访问B端的页面，S端向B端提供服务，具备较好的跨操作系统能力。
[0021] API服务过滤器(filter)：API一般都会有一个过滤器层filter，用来执行对每个接口API都必须要执行的方法，比如身份验证，会话过期验证等。
[0022] 控制器(controller)：可以向系统的service层发送指令，调度软件服务完成特定数据处理。
[0023] 圈存：圈存是银行术语，指将消费者银行户头中的钱直接圈存在个人账户上，圈存的资金只在特定的消费环境下进行消费的。本发明所提到的圈存的资金只用于在对应的培训机构消费。
[0024] 图1为本发明实施例中学费监管系统的示意图，如图1所示，该系统包括：
[0025] 至少一种学费监管API101，与每种学费监管API对应的API服务控制器103，API服务过滤器102，其中，
[0026] 学费监管API101，用于接收第三方平台发送的与学费监管API对应的交易请求，并发送至API服务过滤器；
[0027] API服务过滤器102，用于对接收的交易请求进行验签操作和解密操作，并将解密后的数据明文发送至API对应的API服务控制器；
[0028] API服务控制器103，用于在接收到数据明文后，进行交易操作。
[0029] 在本发明实施例提出的系统中，通过不同的学费监管API可以接收不同的交易请求，灵活性与适应性高，通过API服务过滤器进行验签操作和解密操作，保证了第三方平台数据和用户学费的安全，无需与第三方实际业务场景融合，降低了开发成本。
[0030] 在一实施例中，所述学费监管系统采用H5嵌入方式接入第三方平台。
[0031] 在上述实施例中，由H5页面与学费监管API完成业务逻辑的交互，其中，H5页面为借记卡学费监管H5。采用H5嵌入方式接入第三方平台有极高的接入效率，可以同时接入多个第三方平台。
[0032] 在一实施例中，所述至少一种学费监管API包括下单API、请款API、退费API和交易结果查询API；
[0033] 所述交易请求包括下单请求、请款请求、退费请求和交易结果查询请求；
[0034] 所述API控制器包括下单API控制器、请款API控制器、退费API控制器和交易结果查询API控制器。
[0035] 具体实施时，图2为本发明实施例中学费监管系统的详细示意图，学费监管API是采用接口封装的方式，将下单、请款、退费、交易结果查询封装成接口提供给第三方平台调用。
[0036] API服务过滤器对接收的交易请求进行验签操作和解密操作，并将解密后的数据明文发送至API对应的API服务控制器，一般是验签成功后，用私钥对报文进行解密，确认数据未被篡改，篡改过的报文解密时会失败。本发明实施例采用Spring MVC，对标准API过滤器的过滤方法进行重写，重写的方法中包含验签、解密功能，用来确认服务的调用方是一个持有私钥证书的合法第三方平台，并对报文进行解密，保证了报文是未被篡改的。
[0037] 在一实施例中，下单API控制器具体用于：在接收到下单请求对应的数据明文后，在数据库创建订单，调用银行系统对该订单进行资金圈存，在数据库中生成流水记录；
[0038] 请款API控制器具体用于：在接收到请款请求对应的数据明文后，在数据库查询该请款请求对应的订单，调用银行系统对该订单进行资金解圈操作和转账操作，在数据库中生成流水记录；
[0039] 退费API控制器具体用于：在接收到退费请求对应的数据明文后，在数据库查询该请款请求对应的订单，若该订单未进行请款操作，调用银行系统对该订单进行资金解圈操作，若该订单已进行请款操作，调用银行系统对该订单进行资金转账操作，在数据库中生成流水记录；
[0040] 交易结果查询API控制器具体用于：在接收到交易结果查询请求对应的数据明文后，在数据库查询该请款请求对应的订单，获得该订单对应的交易结果，在数据库中生成查询记录。
[0041] 在上述实施例中，存储在数据库中的订单、流水记录、查询记录都是存在数据库表中的，下单请求是第三方平台用户向第三方平台发起的，第三方平台发送至下单API，第三方平台指各种类型的培训机构平台，可以是APP等，请款请求是第三方平台直接发送至请款API的，退费请求时第三方平台用户向第三方平台发起的，第三方平台发送至退费API，交易结果查询请求时第三方平台直接发送至交易结果查询API的。
[0042] 上述交易请求在由第三方平台发送至对应的学费监管API时，先进行了加签和加密，加签和加密方式及种类是第三方平台与学费监管系统约定好的。采用私钥证书加签，公钥证书验签的方式，确保保证交易一定是从第三方平台发出，达到交易抗抵赖目的。可以采用公钥加密，私钥解密的方式，保证数据不被篡改。
[0043] 在一实施例中，下单API控制器具体用于：
[0044] 在接收到下单请求对应的数据明文后，获取下单请求对应的第三方平台用户的用户信息，所述用户信息包括手机号；
[0045] 根据所述用户信息，生成第一短信验证码；
[0046] 将所述第一短信验证码发送至对应的API；
[0047] 在接收到第二短信验证码后，验证第一短信验证码与第二短信验证码是否一致，若一致，在数据库创建订单；
[0048] 下单API具体用于：
[0049] 将第一短信验证码发送至第三方平台用户手机；
[0050] 接收第三方平台用户输入的第二短信验证码，并将第二短信验证码和发送至对应的API服务控制器。
[0051] 在上述实施例中，银行系统由于不能完全信任第三方平台发送的涉资金的交易，在下单缴费时，向用户在银行预留的手机号发送短信验证码，由用户填写，随交易回送银行进行验证，保证用户交易的自愿性。可以限制同一手机号每分钟只能请求一次短信验证码，极大降低短信验证码撞库的成功机率。
[0052] 在一实施例中，所述系统还包括数据转化模块104，图3为本发明实施例中学费监管系统的另一示意图，数据转化模块104用于：
[0053] 基于订单数据模型实例化生成存储在数据库中的订单；
[0054] 基于流水记录数据模型实例化生成存储在数据库中的流水记录；
[0055] 基于查询记录数据模型实例化生成存储在数据库中的查询记录。
[0056] 在上述实施例中，存储在数据库中的订单、流水记录、查询记录都是数据库表，每实例化一条数据，插入对应的数据库表中即可，方便快捷。本发明实施例采用hibernate来构建数据转化模块104。
[0057] 在一实施例中，存储在数据库中的订单、流水记录、查询记录符合BC范式，从而在第三范式的基础上，消除主属性对于码的部分依赖，或传递函数依赖。
[0058] 在一实施例中，存储在数据库中的订单通过预留外键字段与对应的第三方平台的订单关联，以此达到将学费监管系统与第三方平台数据相统一，维护关系数据库的完整性。
[0059] 在一实施例中，所述系统还包括数据模型描述模块105，图4为本发明实施例中学费监管系统的再一示意图，数据模型描述模块105用于：
[0060] 采取面向对象方式生成订单数据模型、流水记录数据模型、查询记录数据模型。
[0061] 上述每种数据类型有字符串、整数、日期、浮点数等基础数据类型。本发明实施例采用java注解来描述数据模型与数据库表以及数据模型字段与数据库表字段的映射关系。
[0062] 在一实施例中，API服务控制器还用于：向对应的学费监管API返回交易操作结果；
[0063] 学费监管API还用于：向第三方平台反馈交易返回报文。
[0064] 在上述实施例中，交易返回报文包括交易成功报文和交易失败报文，格式如下：
[0065] 交易成功报文格式：
[0066] {result:”ture”,msg:{key1:val1[,key2:val2...]}}。
[0067] 交易失败报文格式：
[0068] {result:”false”,msg:”错误原因[错误码]”}。
[0069] 综上所述，在本发明实施例提出的学费监管系统中，学费监管API，用于接收第三方平台发送的与学费监管API对应的交易请求，并发送至API服务过滤器；API服务过滤器，用于对接收的交易请求进行验签操作和解密操作，并将解密后的数据明文发送至API对应的API服务控制器；API服务控制器，用于在接收到数据明文后，进行交易操作。在上述系统中，通过不同的学费监管API可以接收不同的交易请求，灵活性与适应性高，通过API服务过滤器进行验签操作和解密操作，保证了第三方平台数据和用户学费的安全，无需与第三方实际业务场景融合，降低了开发成本。另外，采用H5嵌入方式接入第三方平台有极高的接入效率，可以同时接入多个第三方平台。向用户在银行预留的手机号发送短信验证码，由用户填写，随交易回送银行进行验证，保证用户交易的自愿性。数据转化模块使得存储在数据库中的订单、流水记录、查询记录都是数据库表，每实例化一条数据，插入对应的数据库表中即可，方便快捷。存储在数据库中的订单通过预留外键字段与对应的第三方平台的订单关联，以此达到将学费监管系统与第三方平台数据相统一，维护关系数据库的完整性。数据模型描述模块采取面向对象方式生成订单数据模型、流水记录数据模型、查询记录数据模型，方便后续应用。
[0070] 以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
