商户聚合支付系统设计（一）
产品概述与整体设计
背景
如今，网购已经渗透到人们日常生活中的方方面面，做为网购的载体，互联网电商平台发展如火如荼，支付功能做为其不可或缺的一部分，实现起来，也有各种各样的方案。根据自己有限的认知，我主观上把目前行业内的支付实现方案做以下归类：
- 持有支付业务许可证，又称支付牌照，自有支付品牌，比如阿里的支付宝、腾讯的微信支付（财付通）、京东的京东支付等；
- 自建第三方支付聚合平台，对接第三方支付（支付宝、微信支付、中国银联、各大商业银行直连等），为其自有订单提供支付功能；
- 一些研发资源有限的电商平台，选择市场中直接能提供全套聚合支付的支付平台，省去研发环节，能够以最短时间较低的成本为其平台提供支付功能。
我从开发者的角度，主要针对第二类，讲述怎么去构建商户自己的聚合支付平台，以及投产上线后所需要主意的事项，打造一套简单、稳定、高效的聚合支付平台。
整体设计
一个完善的聚合支付系统，拥有支付网关、主动对账、退款网关、支付/退款状态查询等功能模块。我会以LNMP架构为基础，细分成六个章节对每一部分做尽量详细的说明。
聚合支付平台的核心，就是怎么合理的去管理接入的各种支付SDK，很多童鞋从官网下载到SDK，几乎不做任何逻辑修改，就直接放到项目的目录中使用，这样做虽然开发成本很低，但弊端颇多，首先要说的就是不易维护，各支付SDK代码结构、风格不一样，后期维护成功高；代码各自为政，没有统一的调用方法；配置分散，无法集中维护系统配置项；无法提供统一有效的日志数据等。因此，我建议首先定义一个Interface，如下图：
然后，每次接入新的支付方式的过程，其实就是实现该Interface的过程。
通常情况下，一种支付方式有一个class[将其class备注为支付类]来实现，但面对一种支付方式提供了多种支付场景，比如微信（提供了公众号支付、APP支付、扫码支付、H5支付、小程序支付、微信免密代扣等）、中国银联（提供了PC网关支付、WAP支付、APP支付、银联云闪付等），我们该怎么办，我建议针对每种不同的支付场景，都有单独的class来实现，理由如下：
- 不同的支付场景，程序执行的流程也不一样，比如中国银联PC网关支付，是需要将支付报文通过客户端浏览器表单POST给银联支付网关，跳转至银联支付网页进行支付，而银联APP支付则是通过curl将支付报文提交给银联支付网关，再将其返回的tn码返回给商户APP，商户APP凭该tn码发起支付交易；
- 对订单系统的订单支付方式展示更加准确，分配给商户不同购物平台（PC端、H5端、APP）的支付方式id是唯一的。如果商户系统不同支付场景所申请的商户号不一样，则需要在推送至财务系统的支付方式也不能重复，否则无法对账；
- 支付类的代码逻辑只关注于自身的支付逻辑处理，不引入额外的判断流程。
那么，就有童鞋就会想到了，一个很头疼的问题，代码冗余。大部分第三方支付，虽然提供了不同支付场景，但基础接口都是一样的，只是部分参数不同，或支付流程上面的少许差别。这时候我们就要考虑好以第三方支付平台为单位来封装一个支付基类，该支付基类实现其所必须的接口调用，比如微信支付，代码如下图：
上面分别提到了 支付Interface、支付类、支付基类三个概念，它们之间的关系是怎样的，见下图
对上图做简要说明，PaymentHandlerInterface是所有支付类的接口，WechatPayment是所有微信支付类的基类，WechatAPPPayment、WechatJSAPIPayment、WechatNativePayment都是提供支付服务的支付类，都需要继承WechatPayment并实现PaymentHandlerInterface接口。同理，系统如果需要接入银联在线支付，那么就需要按照开发文档实现一个ChinaPayPayment做为银联在线支付的基类，然后分别开发出具体支付场景的支付类，比如ChinaPayAPPPayment(银联app支付)、ChinaPayWAPPayment(银联wap支付)、ChinaPayPCPayment(银联pc支付)，这三个支付类需要继承ChinaPayPayment并实现PaymentHandlerInterface接口。
原文地址：https://blog.csdn.net/think2017/article/details/79820786