一个支付网关的实现
2017-02-10
最近给我司的支付系统增加了 Apple Pay 支持，一周多一点儿搞完了，当然这个不是重点，发现我们这个支付网关设计的很不错， 写个文章学习一个。
一般的支付流程，比如电商的支付需要支持多个通道，支付宝、微信、apple Pay 等等，而根据不同的业务线又会有多个服务同时来做支付 比如线上业务和线下业务，所以这是一个多对多的关系，具体到第三方支付相关的逻辑都一样，只是根据不同的业务线有不同的配置，基本的结构 如下图所示：
功能
先确定一下一个支付网关需要做的事情
- 处理来自各个业务服务的请求
- 处理来自第三方支付渠道的回调
- 支付/退款/可能还有转账
- 需要自己维护各个支付渠道的数据
- 维护一份账单
第三方支付渠道的支付流程基本都大同小异
细节
业务配置
一开始设计就要支持多个 AppID，未来增加应用只用增加配置即可
给第三方的 OrderID
网关这边传给第三方支付渠道的 OrderID 应当是网关自己生成的一份 OrderID，网关自己要维护一份业务 OrderID 的映射
重复支付
一个业务的一笔订单在网关这边有且仅有一个 OrderID
业务细节
网关不应关心具体业务的细节，比如多个店铺在一个订单一起支付这种，网关的认知是一笔交易，具体的分帐的逻辑应该在各个业务线内处理
存储
因为涉及到钱，设计的时候宁可多存，不能少存，数据表做好 onSave 快照，打好日志，方便后期排查
消息通知
接受通知的逻辑是，第三方服务回调网关/自己去拉消息(比如微信)，然后网关再推给各个服务，当服务应答成功后，才能标记位消息发送成功
存储
- MySQL: 存储具体的数据
- Redis: 供 Celery 使用
- MC: 可选，做业务层缓存
MySQL 表
- 核心的交易表和退款表
- 各个支付方式自己维护的交易表和退款表(详细信息)
- 简单对账的收入和支出表
- 消息通知表