第四方支付介于第三方支付和商户之间，其将各种不同类型的支付接口融合在同一运营平台上，为商户提供综合支付接口服务。按业务分类，聚合支付分线上和线下两种类型。线上是聚合网络支付，主要为电商服务；线下是聚合支付收单，主要为实体店服务[1].据统计，2016 年一季度，第三方互联网支付交易规模市场份额中[2],支付宝占比43.3%、财付通占比20.1%、银联商务占比11.1%、快钱占比7.0%、中金支付占比5.1%及汇付天下占比5.0%.可以明显看出，第三方支付市场呈现出明显的碎片化特征，对于大量中小商户来说，与不同的第三方支付公司的支付接口一一对接往往需要大量时间和资金成本。在此背景下，第四方支付（聚合支付）通过APP、网站等渠道可实现聚合多家合作银行、第三方支付平台及其他服务商，为B端中小型商户提供在线支付综合解决方案的优势[3].
在国外，第四方支付已经诞生了Stripe级别的企业，其提供的支付服务在用户体验上更加流畅、合理和拥有更高的整合度[4].目前，国内第四方支付领域虽然没有出现同等级别的企业，但其发展却势不可挡[5],且整个行业处初级阶段。在支付框架结构上，当前第四方支付与现有的第三方支付最大不同点体现在是否有代理商业务链条的嵌入。此外，第四方支付存在的问题集中在结算业务方面的“二清”风险[6]以及信息防篡改等方面。
就API技术角度而言，当前市面上主流的在线支付主要有：支付宝及时到账支付、支付宝WAP支付、支付宝APP支付。针对这些支付方式，本文设计了一种融合多种在线支付接口的第四方支付平台框架。该平台基于J2EE（Java2 Platform Enterprise Edition）以及改进型的MD5信息加密技术，实现了上述三种主流支付接口的融合，通过采用代理商的合约运营模式，依据上游成本费率来管理商户成本费率，降低了商户接入和结算维护费用，为第四方支付公司或商业银行机构提供一个有效的基于PC端的综合运营管理平台。
1、平台框架设计
本文设计的第四方综合支付管理平台采用J2EE轻量级多层体系框架，共分为三层：表现层、业务逻辑层、数据库持久层，并由对应的SSM（Spring MVC+Spring+Mybatis）框架来控制执行，能更加便利、高效地开发出业务应用功能[7].此外，平台运用新型MD5数据加密方式并整合第三方支付接口，最终通过WAN网络连接对应的第三方支付机构、商业银行、代理商以及商户，完成了代理商开户、商户入驻、支付交易、对账、结算等业务。
1.1 网络拓扑结构设计
第四方综合支付运营平台的网络拓扑结构如图1所示。
平台网络拓扑结构具体包含以下6个节点，分别为：数娱终端、 商户站点、代理商平台、第三方支付平台、商业银行及第四方综合支付运营管理平台。
数娱终端是指数字娱乐行业的用户发起支付时所借用的硬件平台，包括移动端和PC端；商户站点特指商户机构创建的APP、网站、服务窗等，主要负责为终端用户提供虚拟的购物平台，发起支付请求；代理商平台与商户平台一样，作为整个第四方运营管理平台的子系统，负责完成商户进件、绑卡、费率设置、交易查询等工作；第三方支付平台为运营管理平台中涉及的支付上游，主要完成商户的入驻、审核、风控以及支付请求与响应等功能；商业银行主要的工作是参与平台日交易的结算工作，经清算人员核算，将结算款汇入商户的结算账户。
综合支付运营管理平台即本文要论述的第四方综合支付管理系统，主要处理商户报件、交易、对账、结算四大业务，分为对下游服务和对上游服务。对下游服务主要负责代理商开户、审核、费率设置、商户进件、商户绑卡、费率和结算周期维护工作，对上游服务主要负责商户入驻支付宝审核、订单请求、商户风控、对账、清分、出款。
1.2 平台功能结构设计
第四方综合支付运营管理平台为商户提供了三种主流支付渠道的接入方式，通过代理商模式发展商户，便于分级支付运营管理。针对下游支付信息的安全性，平台采用改进型的MD5加密方式，为商户提供快捷、安全、稳定的支付服务。
平台的业务从功能层次上主要分为以下几个层面，平台功能结构如图2所示。
1） 网络支撑层
网络底层支撑层为上层应用提供了多种网络接入方式，包括3G,4G,WiFi以及WAN,此外还包括一些软硬件支持，包括定时任务系统、商户风控系统、挂靠云服务器以及持久层应用等。
2） 接口层
平台接口层的主要业务逻辑是对支付请求的处理与响应。图3为平台核心支付业务处理模型。
下游商户站点采用HTTP通信协议以及POST请求方式将加密订单信息通过代理商平台传递至运营管理平台，通过相关参数的验证、组装，最终响应下游商户支付链接，由用户发起最后的支付。
此外，该层不仅包括商户进件接口、费率接口、支付接口，而且还包括对账、清分操作后涉及的出款接口。对账清分过程是获取上游支付宝的订单信息，再与平台信息对比生成差异报表，最终调账、清分，通过商业银行提供的出款接口标准请求参数至商业银行出款给商户。
3） 业务层
基于J2EE多层体系架构的模块化设计了业务逻辑层，为运营人员、客服、代理商、商户提供网络化管理、订单查询等功能；其中包括代理商开户、商户报件、绑卡、费率设置、对账报表下载功能，同时也为下游机构提供了身份复核、支付宝商户入驻等功能。
4） 平台子系统
第四方综合支付平台共分三个子系统，分别是：运营管理系统、代理商系统和商户系统。运营管理系统由运营人员、客服、清算人员进行维护，提供代理商和商户管理、交易、对账、清算、咨询服务等功能；代理商系统负责商户进件、商户费率设置、交易查询、分润报表下载功能；商户系统负责为商户提供交易订单的查询、订单统计功能。
2、在线支付流程
支付交易是第四方综合支付平台的核心业务。用户终端通过在商户线上站点或线下实体店下单，然后商户对应支付接口通过网络将订单信息MD5加密，向上游代理商系统和运营管理平台传递，运营管理平台验签通过后会将订单信息包装成对应的支付链接返回给用户终端，最后由用户发起支付。此种运营平台作为第三方支付服务商的支付模式，在支付发起时用户并不在第一时间与外部第三方系统交互，而是通过服务商设置一个交易预下单的过程，这样在很大程度上杜绝了交易信息被篡改的风险，提高了支付的稳定性。本文设计的聚合平台的支付请求处理流程如图4所示。
支付请求处理流程的主要步骤如下：
1） 支付请求发起后，先由平台进行商户合法性的验证，然后再对支付订单加密信息进行验证签，并对应响应；
2） 判断是否有重复订单，并在判断基础上重新生成订单信息；然后再验证商户是否设置了费率以及代理商和商户的支付渠道限额情况，并响应；
3） 根据订单信息生成支付订单号，组装支付宝请求参数，将支付流水信息同步到本地数据库，同时将包含请求参数的支付链接返回给下游，最终由终端用户发起授权支付；
4） 上游确认支付成功后，将支付结果异步回调给运营平台，再由运营平台回调给下游。
3、信息安全加密
支付平台涉及商户账户以及交易现金流水信息，因此综合支付平台从多方面进行了信息安全方面的考虑。
3.1 支付下游信息加密
在下游商户入驻以及下游订单信息上传过程中，平台使用了MD5签名机制，以确保商户入驻信息在传递过程的完整性和敏感信息的私密性，确保交易报文在传输过程中不被篡改，确保信息传输的双向安全[8?10].在商户入驻平台以及交易订单上传的过程中，对应接口会将请求数据组装好：首先采用UTF?8编码格式对接口请求参数进行字典排序，加上参数赋值后生成{json}格式的待签名字符串；其次，将对应代理商开户时生成的AGENT_KEY拼接在两头，生成key+{json}+key的签名内容；最后，采用MD5函数对签名内容进行签名，从而得到32位签名结果字符串，并将该字符串赋值于参数sign,然后再请求。当平台获取到请求参数后，也会采用同样的方式对数据进行签名，生成另一个参数sign;最终通过与原有请求中的sign值对比，以验证信息传输的安全性。支付上传信息MD5加密实现代码如下：
3.2 支付上游信息加密
入驻到平台的商户信息会通过定时任务（10 min发起1次），将商户信息报件至上游第三方支付平台进行审核。此过程采用支付宝RSA2签名验证机制，通过对请求参数进行摘要、非对称加密以及SHA1WithRSA验证来保证入驻信息的安全性。
此外，平台提供了针对商户账户的风控服务，通过及时获取上游第三方支付平台的风控信息，对商户的结算账户进行冻结或者解冻操作，进而杜绝非法交易的情况发生，同时也保障了终端用户的利益。
3.3 定时任务
由于网络环境的原因，在支付流程结束后存在平台未能收到来自上游返回的单笔交易的交易状态。平台设计了完整的定时任务系统，通过自动向上游发起的交易查询、自动向下游代理商发起的9次交易状态的异步通知等途径，保证了支付交易状态下的及时性。此外，还包括日交易的定时对账、对账文件以及对账差异报表生成等。
4、结 语
本文设计了一种第四方综合支付运营管理平台框架。该平台独立于第三方支付平台、商户和商业银行，采用J2EE多层体系架构分布式部署方式，运用代理商运营模式，为商户对接上游各种支付接口，完成了商户入驻、费率设置、清分、结算等业务。此外，平台框架的可拓展性强，可以对接支付上游不同类型的接口，实现其他针对商户的支付服务以及金融衍生服务。目前，该平台框架已经在某公司取得成功案例，为数字娱乐行业类型的商户提供了稳定、可靠的全方位支付服务；后期，平台会在系统高并发上做进一步的改进与研究。
