1.设计思路
每个公司都有自己的支付系统，有很复杂的像支付宝这种，也有超级简单的就是一个接入第三方支付。这里我想设计一个简易的完整的支付系统，我应为应当包括，支付网关，支付渠道，基本支付，以及风险监控。
1.1支付网关
支付网关是对外提供服务的接口，所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型，后续就很少，也很难调整。而支付渠道模块是接收网关的请求，调用渠道接口执行真正的资金操作。每个渠道的接口，传输方式都不尽相同，所以在这里，支付网关相对于支付渠道模块的作用，类似设计模式中的wrapper，封装各个渠道的差异，对网关呈现统一的接口。而网关的功能是为业务提供通用接口，一些和渠道交互的公共操作，也会放置到网关中。
1.2 支付渠道
这里并没有采用现在最流行的微服务的方式，因为考虑到渠道不会很多，而且一般支付的交易量不会太大。这里一般有两种拆分模式：
-
按渠道拆分，指每个渠道单独拆分，对支付网关提供相同的服务。
-
按服务拆分，是按接口来拆分，分为支付，对账，退款等子系统，所有服务都实现在一起。
这里个人比较喜欢按渠道拆分，不喜欢按功能拆分。因为按照面向对象的使用习惯，按渠道拆分类似于面向对象，每个支付渠道就是一个支付对象，按服务拆分有点类似于面向过程，把整个支付的过程拆开来实现，本人常年使用Java所以更推荐按渠道拆分。
1.3基本支付
这里的基本支付会涉及到你的业务系统，一般会涉及到虚拟货币,代付，应用内支付，账户支付（领钱，余额），银行卡支付，信用支付等。在这个模块中会处理我们的业务逻辑，实现整个货币在平台内的流通。
1.4风险监控
我们在交易中如果发现大额交易或者异常交易，这个时候就要评估交易风险
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。
-
阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；
-
增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。
-
放行交易，即本次交易是安全的，可以继续往下走。
数据库设计
这里数据库的话采用mysql，因为简单轻量，当然还有很多涉及到具体业务的表就没有发出来了。
1 pay_channel：可供接入的支付渠道
2 ali_pay支付应用信息
3 wx_pay微信支付应用信息
4 pay_order支付订单
具体流程如下：
未完待续