在高校电子支付“虚拟化”发展的过程中，“多种支付方式并存、多种支付渠道并用”为高校移动支付提供了解决方案，并实现了多样性选择，但同时也带来了一些问题，主要表现如下：

1.支付体验较差。对于线下支付方式，如使用圈存机购电，存在服务终端有限导致排队时间过长、无法实现随时随地支付的问题；对于线上支付，由于支付渠道分散，用户需要在支付宝、微信、虚拟校园卡APP等多个支付渠道重复进行身份认证。

2.收费场景支持度不够。目前，微信/支付宝电子校园卡、虚拟校园卡APP、聚合支付等支付方式主要面向食堂、学校超市等移动现场支付场景使用，而学费、住宿费、四六级报名费等还需要在校园网支付平台进行缴纳，缺乏相关移动在线支付方式的支持。

3.数据存在安全风险。微信/支付宝电子校园卡、虚拟校园卡APP等的身份认证信息、业务数据一般存储在公有云上，存在数据泄露风险。

面向服务的智慧校园统一移动支付平台方案的设计

1.设计思路和设计原则

（1）设计思路

①连通全部移动支付渠道：设计统一移动支付接口，为支付场景提供接口服务，用户在支付时进行选择即可，无需在多个支付渠道之间进行切换。

②覆盖全部在线支付场景：面向学费、住宿费、团费等收费场景，采用费用中心模式；面向一卡通充值、购电、网费缴纳等消费场景，采用校园商户模式。

③统一支付入口：面向服务的统一移动支付平台连通全部移动支付渠道，并覆盖全部在线支付场景，使用户无需在微信或支付宝等多个平台重复进行身份认证，从而减少数据泄露风险。

（2）设计原则

为实现上述设计思路，面向服务的智慧校园统一移动支付平台方案的设计原则包括：

①开放性：满足全部支付场景的接入能力，即平台需向业务部门的新增支付场景开放，只需与平台对接即可进行支付。

②拓展性：功能模块能够进行自由拓展，而不需要重构整个系统，如新增扫码支付方式、增加平台的支付渠道等。

③安全性和稳定性：需确保交易过程安全、数据传输和存储可靠、系统运行稳定，并支持一定规模的高并发支付业务。

2.平台方案架构

平台方案主要分为支付平台层和支付渠道层，覆盖的场景包括消费类场景（校园一卡通充值、电费缴纳等）和财务收费类场景（学费、住宿费、团费、四六级报名费等）。为快速响应新增支付场景和功能模块插件式扩展的需要，平台方案采用微服务架构进行设计与开发。

（1）支付平台层

支付平台层包括用户端和管理端。其中，用户端面向终端用户，通过搭载校园门户APP的统一移动支付平台轻应用，无需身份认证（校园门户APP在注册、激活时已认证身份），即可利用各类校园商户如一卡通、费用中心等模块进行在线移动支付；而管理端主要面向平台管理人员、业务部门、财务部门，提供商户管理、订单管理、费用中心、对账中心等功能。

（2）支付渠道层

支付渠道层是支付场景层的基础，提供支付接口服务。统一移动支付接口是在总支付渠道微服务的基础上开发形成SDK（Service Development Kit）包，向用户提供支付页面并获取支付结果的接口。统一移动支付接口可以降低业务部门与统一支付平台的耦合度，从而最大限度地减少业务部门对接的复杂度。

具体来说，支付渠道层包括四方面内容：

①API网关，在网关层面做出统一的权限控制，实现所有外部服务的统一访问、管理。

②微服务注册中心，提供服务注册与发现功能，并保证不同微服务之间调用的高可用性和负载均衡。

③核心交易微服务群，负责整体交易系统的正常调度与运行，如订单管理、支付管理、交易校验、商户管理等。

④统一移动支付接口，部署支付宝、微信支付和一网通支付等支付渠道，并支持跳转支付、结果通知等各类支付相关活动。

面向服务的智慧校园统一移动支付平台方案的支付场景划分与支付流程

1.针对收费场景的费用中心及其支付流程

在面向服务的智慧校园统一移动平台方案中，支付平台层的目标是支持在线移动支付的全部场景。其中，针对学费、住宿费、四六级报名费、团费等收费场景，设计了面向财务收费的费用中心。费用中心支持新增收费场景，旨在借助费用中心使支付平台层具备覆盖全部收费场景的能力，同时借助支付渠道层连通全部支付渠道。

费用中心的支付流程如图2所示。

具体如下：

①业务部门（如学生处）在管理后台通过费用中心发布收费数据（如应收费人、收费金额），查询收费进度→

②用户登录“统一移动支付平台”用户端→

③用户查询收费信息→

④用户针对应收费款项（如学费）进行支付交易→

⑤用户通过移动支付页面，选择支付渠道→

⑥统一移动支付接口唤起相应支付渠道，跳转支付→

⑦支付成功后，统一移动支付接口收到支付结果通知→

⑧核心交易微服务群根据支付结果通知，请求费用中心为用户提供收费回执，并启动交易校验模块；对于没有收到商户确认的情况，按照设定的轮询机制对商户进行重复提醒→

⑨费用中心向用户发送收费回执→

⑩费用中心将回执成功通知发送给核心交易微服务群→

⑪核心交易微服务群启动交易检验模块，校验交易流程的完整性，将完整的交易设为“交易完成”；对于轮询周期完成后尚未收到商户确认的情况，将订单状态设为“异常”，由管理员手动触发发货请求。

2.针对消费场景的校园商户及其支付流程

为实现支付平台层覆盖全部在线移动支付场景的目标，对于不适合采用费用中心的其它在线支付场景均可应用校园商户及其支付流程，如一卡通充值、宿舍购电等消费场景。每个校园商户即对应一种消费场景，通过增加校园商户使支付平台层具备覆盖全部消费场景的能力，同时借助支付渠道层连通全部支付渠道。

校园商户的支付流程如图3所示。

具体如下：

①用户登录“统一移动支付平台”用户端→

②用户选择校园商户（如一卡通）→

③用户创建交易→

④用户在支付页面确认商品信息并选择偏好的支付渠道→

⑤统一移动支付接口唤起相应支付渠道，跳转支付→

⑥支付成功后，支付渠道通知统一移动支付接口的支付成功状态→

⑦核心交易微服务群根据支付结果通知，异步向商户通知支付结果，同时请求校园商户业务系统（如一卡通管理系统）给用户发货，并启动交易校验模块；对于没有收到商户确认的情况，按照设定的轮询机制对商户进行重复提醒→

⑧商户给用户发货→

⑨商户将发货成功通知发送给核心交易微服务群→

⑩核心交易微服务群启动交易检验模块，对交易流程的完整性进行校验，校验通过设为“交易完成”；对于轮询周期完成后尚未收到商户确认的情况，将订单状态设为“异常”，由管理员手动触发发货请求。

智慧校园统一移动支付平台的应用

1.对比虚拟校园卡的应用优势

本研究选择微信/支付宝电子校园卡、虚拟校园卡APP、聚合支付等虚拟校园卡支付方式，与智慧校园统一移动支付平台方案进行了对比分析，如表1 所示。

基于对比结果，本研究发现平台方案具有以下优势：

①只需一次认证或无需身份认证（当平台搭载于校园门户APP 时）；

②具备支付场景扩展能力，通过费用中心和校园商户可覆盖包括在线支付和现场支付的全部场景；

③具备支付渠道扩展能力，可覆盖全部支付渠道；

④自主开发和私有化部署，数据安全性更高。

2.“校园钱包”：平台方案在同济大学的具体应用

基于智慧校园统一移动支付平台方案，结合校园支付的实际需求，同济大学联合招商银行于2016年11月推出了统一移动支付平台——“校园钱包”。“校园钱包”将Spring Cloud 微服务架构作为开发框架，实施本地私有云部署，将其搭载于同济大学移动校园门户“同心云”，以轻应用的形式为师生提供校园支付服务。

“校园钱包”连通了3 种支付渠道——支付宝、微信、招行一网通，可支持5 种在线支付场景——一卡通充值、宿舍购电、学籍证明费自助打印、教师公寓租赁押金、租金缴纳，并具备全部支付渠道和全部移动在线支付场景的扩展能力。应用“校园钱包”，用户既无需多次身份认证，也无需在多种支付方式和支付渠道之间切换，提升了用户体验。

经过3年多的平稳运行，同济大学“校园钱包”的用户数已超过3.7万，交易成功订单数超过28万，充值总金额超过3800万元。“校园钱包”的最大支持并发量为3000TPS（Transactions Per Second），能同时为财务部门提供了自动对账功能、为各个业务部门提供商户订单查询与异常订单处理功能、为校园钱包后台管理员提供系统管理功能，并配置新增商户及其相应管理权限，添加了商户系统IP白名单功能，可有效保障统一移动支付平台的安全性。（来源：《现代教育技术》2020年09期。本文系节选。）