支付系统的设计概要

一、背景

本文不意长篇累赘地描述支付系统，通过一张设计图，目标是已有一定支付业务基础的同学，在做设计的时候，仅供参考一二。

本文的内容重在微服务化的模块设计。

二、系统设计

1、以支付系统为中心

你的支付系统不应该仅支持商城业务，而是支持整个公司的支付需求。

换句话说，支付请求是不校验上端业务的， 有自己的单独的支付网关。

这也是出于部署方面的安全考虑，如果有条件的话，其部署也应该和其他服务隔离开来。

你可以在任意地方创建订单（比如OA后台，收取用户的应收款项，这里压根就没有商品），都允许调用支付系统。

2、通知模块

支付成功，更新支付订单的状态，然后异步通知其他相关服务，比如订单、积分、会计、对账等等。

3、对账

隔天调用第三方支付的对账接口，分汇总和明细存储到本地表，和支付订单进行一一对比。
得到单边账，可能手动处理，也可能自动处理。

4、退款

退款首要考虑的是安全性。不单是外网访问的校验，内网也不能例外。

所以建议你有自己的支付网关，对退款接口进行额外的校验。

当然手段有很多，最基础的就是通过短信验证码的方式，将操作退款的口令发送给指定人，然后在退款的时候必须输入退款口令。

另外就是http header传递认证字段，类似token。

或者你采用开放平台方式，给调用方发放appkey和appsecret。

总之，安全和复杂是孪生兄弟，看你怎么取舍了。

5、风控

支付的风控，侧重于是否重复支付，不能多收用户的钱。
退款的风控，是我们的重点，可不能发生货发给用户了，钱却退了。

做风控的对象就是钱-货-人，做不了实时的，至少要能够事后发觉风险。

6、支付路由

这是支付系统的必要功能了。

因为不同的业务线，采用的支付方式，必然是不一样的。

这就涉及支付的路由，说白了，是一个一对多的映射关系。

支付下单接口，允许让业务方传参选择即可。

7、商户

你应该对同一个支付渠道，申请多个商户，应对某个商户被禁的突发情况。

三、后话

商城系统，再加上支付系统，从业务上看，大家都易于理解，甚至耳熟能详。

后期有空把我们公司实现的模块，拣选有意思的梳理出来，大家一起讨论。