1、线上支付日间交易系统概述
图1是线上支付平台在银行系统群中的位置示意图，可以看出，线上支付平台在银行系统群中属于中台系统，下接银行的双核心系统、第三方支付通道等；上接银行各个业务系统、外部合作方，在为银行的各个业务系统提供支付能力的同时，也能把银行的支付能力对外输出，扩展银行的支付业务。
图1 线上支付平台在银行系统群中的位置
线上支付日间交易系统是为了帮助银行整合；接入下游支付通道，并统一向银行其他平台提供支付能力而产生的的交易系统。要求其能满足当前多种支付方式的实现，能够接入当前主流的支付通道，同时能实现互联网金融场景下可能出现的高并发场景，给用户最好的支付体验。
该系统应该采用分布式微服务的架构方式，各个应用之间功能独立，提供接口供远程调用，并且不会互相影响。日后还可以根据业务需求，在不需要对现有系统进行大规模改动的前提下，增加新的微服务应用，使整个系统具有较强的扩展性。
银行在使用了这套统一支付日间交易系统后，可以便捷的接入各个支付通道，并在该系统中进行统一的报文转换和错误码映射。同时银行也可以根据自己的业务场景，自由的拓展新的支付业务逻辑。
2、功能需求
1. 通道接入
线上支付平台最重要的一个功能，就是能支持下游通道自由的接入该平台。不同的支付通道，都有其独自风格的通信方式、报文格式、以及加验签方式。线上支付平台需要具备接入多种下游通道的能力，与此同时，该系统还需具有解析不同下游通道接口返回的报文，并作出对应业务处理的能力。
要实现以上能力，要求线上支付平台的设计足够自由灵活且具有拓展性，同时也要保证各个通道的独立性：通道和通道之间不会互相影响，可以在原有通道代码的基础上自由的开发新的通道。
2. 通道路由
线上支付平台接入众多的下游通道的目的，就是为了让银行在支付的过程中具有更多的选择，不会因为某个通道的异常而导致整个支付业务的宕机。因此，该系统需要通道路由的功能，来保证支付业务可以在众多支付通道中，选择最合适的支付通道。
本系统对路由的设计，主要是从通道路由单笔限额、通道路由优先级、是否支持该银行、通道银行单笔限额、通道是否可用、路由是否可用这几个维度来设计的。通过这几个维度的综合判断，选择出最优的通道。
3. 报文加验签
统一支付日间交易系统主要的业务场景就是资金的交易，涉及的资金交易的系统对安全性的需求较高，为了避免在报文传输途中的安全隐患（诸如报文被恶意篡改等），需要对报文进行加签、验签，以此来保证报文传输的安全性和可靠性，降低交易的资金风险。常用的报文加密方式有不可逆和可逆两种方式，不可逆加密方式指的是在加密后无法进行解密，可逆的加密方式指的是在加密后可以进行解密。
可逆加密又分为对称加密和非对称加密，对称加密指的是加密和解密可以使用同一个秘钥，而非对称加密则指的是加密和解密使用的是不同秘钥。常见的不可逆加密方式有 MD5 加密，对称加密方式有 AES、DES 等，非对称加密方式有 RSA 等。
本系统对加密方式的选择是 MD5 加密。
4. 异步通知
在某些业务场景下，会存在无法实时返回交易结果或者需要等待较长时间才能返回交易结果的情况。这类场景下，为了提升用户的支付体验，需要异步返回交易结果。所谓的异步返回，指的是在无法实时或者在短时间内返回交易结果的时候，先同步返回一个应答，表示交易已收妥，然后等到确定交易已完成的时候，把交易结果通知给支付的上游。
对于异步通知的交易场景，本文采用了消息队列触发的方式。采用消息队列方式的好处在于，触发通知的线程只需把通知任务放到消息队列中，无需等待通知流程完成。负责通知流程的进程则从消息队列中获取到了通知任务，完成通知流程。本系统消息队列选择的是rabbitMq。
5. 超时查询
在交易过程中，难免因为网络等原因，下游长时间不能返回交易结果，从而导致通信超时。这种场景下无法实时返回交易结果，因此需要一种补偿措施来获取到正确的交易结果。
比较常用的超时补偿措施为超时查询。
在本系统中，会设计一张定时轮询表，该表中存有通过定时任务触发的任务。当交易超时时，系统会把该交易的相关信息录入到该表中，然后会有一个定时任务，每隔一段时间从表中提取数据，该任务会以多线程的方式对提取到的超时交易进行查询处理，若查询到交易结果，则更新数据库，否则不处理，等待下次轮询继续处理。
6. 异常处理
对于上游发送过来的交易请求报文，该系统需要对报文的正确性、以及报文中相关信息的合法性进行校验，具体有以下几种情况：
（1）必输字段是否为空；
（2）报文格式是否正确；
（3）上游系统状态是否正确；
（4）交易是否重复；
（5）是否有适用于该交易的可用通道；
在校验完成后，对于没有校验通过的交易，该系统需要给出正确的错误码作为响应，提示上游重新组织正确的报文进行发送，或者联系支付系统管理员解决问题。
7. 错误码映射
第六条所述的错误码，为日间交易系统自己的异常错误码，除此之外在实际生产交易中，还有许多属于下游通道的错误码需要进行映射。不同的通道同样错误信息返回的错误码都是不同的，日间交易系统需要把这些错误码统一映射成系统自己定义的错误码，然后返回给上游。下游通道返回的错误码中，有三种是比较重要的：
（1）余额不足；
（2）单笔限额超限；
（3）日累计金额超限
这三种错误码会被单独映射成支付平台日间交易系统自定义的错误码，除了这三个错误码之外，其余的错误码，统一映射成：下游通道返回失败，失败原因{0}，其中的{0}是占位符，表示的下游通道返回的失败原因。
3、业务需求
本次开发，该系统需要实现的业务需求有委托代收业务以及银行账户充值业务。
1. 委托代收是指线上支付平台把自己接入的代扣通道进行对外输出。
商户可以通过接入线上支付平台，获得代扣用户银行卡金额的能力，从而完成一次支付交易。委托代收业务，能够帮助银行扩展外部商户，并赚取代扣手续费。由于是外部商户接入，所以上游发送过来的请求报文需要进行加签处理，并在支付平台验签通过后才能进行交易。另外对商户请求的代扣订单要进行校验并落地，通过路由选择合适的通道进行交易。大致流程如下：
图2 委托代收业务流程
下表给出了委托代收业务的接口。
表1 委托代收接口
2. 银行账户充值业务是指，把客户他行卡的钱转入本行的一类户（银行卡）或者二类（电子账户）。
充值业务是由行内系统作为交易发起方请求线上支付日间交易系统，无需进行加验签校验，但需要对报文格式进行校验。并且该业务不涉及商户订单，无需进行订单落地。大致流程如下：
图3 银行账户充值业务流程
下表给出了银行账户充值业务的接口。
表2 银行账户充值接口
