金融业务系统对接第三方支付/银行放款经验

工作十六年年很是惭愧，回头望去在泛金融的圈子里面苦苦挣扎，保险、银行、P2P、信贷这些公司都待过。有核心也有边缘项目，回首走过的路还是做过的各种业务支付项目最让我印象深刻，粗鄙的经验与君共享，希望不吝指教。

A公司的购物支付

这是十年前的项目，已经记不清楚公司卖的是虚拟物品还是实体物品了，作为Java小兵的我第一次接触支付项目，直接和钱打交道，内心还是很激动的，我胡汉三终于进入到核心项目（后面学了DDD才知道，支付项目在这样的公司也就属于支撑域，甚至还是通用域，虽然有一定重要性，但还不至于是核心）。

在那里的经验其实谈不上，基本都是听指挥干活，就喝我们淘宝买东西类似，对接成熟的第三方支付只要按照他的接口来就可以了，唯一可以分享的就是多和支付公司团队沟通，搞清楚每个字段的具体用途，别传错返工即可。

B公司的代收代扣

来到B公司了，哥哥我可不一样了。自从我的领导离职后，我就升为技术负责人了，管着研发和运维的十几号兄弟。在这里我最重要的事情就是维护好公司的支付系统，悲哀的是我是从别人那里接收的，更悲催的是他第一次设计支付系统，做完就跑了。于是悲催的故事来了。

你见过一次收益发放多放出去几百万吗？

用户投资后为用户提前生成好每月的收益发放计划。通过跑批的方式发放当天的收益，有些用户投资了多个标的也一并当天发放。悲催的事情来了，刚开始没问题，后面要发放的数据多了发现之前的开发居然没有加分布式锁，两个支付应用各发各的，导致很多用户的收益发了两遍，瞬间几百万出去了。当时的法律规范还不完善，公司给每个用户开了余额帐户，我们赶紧从余额中冲正，但还是一百多万已经被用户提现追不回来。

后面开始给用户操作逻辑加锁，帐户流水对账，帐户余额对账，还有对总账，各种操作上去后再也没发生这样的情况了。

你见过在支付系统上做活动项目吗？

公司之前的核心是基金和高净值，可能开发人员也没想到支付项目会变成公司的重点收益项目，当我知道支付系统还有个针对活动的子应用时，真想找到当时的人质问一番，他到底是怎么做到在这里支持公司之前的秒杀活动的？

改吧！首先应用独立出来。还好我们不是互联网那种超高并发，卖的是高收益的理财产品，秒杀活动基本不到一千并发，名额也是秒没。大家想到我应该各种限流和熔断再加安全验证防重？不好意思，那个时候还不会！那个时候分布式刚普及，微服务也还没完全在金融系统中普及。

做法很简单，活动页面全部是nginx部署的静态页面，页面按钮JS防止重复点击，活动二级域名跳转到活动机器，但节点无分布式，配置一个独立缓存还是memcache，他就是我的数据库，后台独立线程从缓存读数据持久化。有人说缓存扛不住怎么办，毕竟不是Redis。好办呀，内存空间用起来，单节点怕啥。后面用Jmeter在测试环境压测下，妥妥2000并发没问题，更不用说生产环境的机器要更好的了。

上线后，其实那一瞬间的并发也就700多，到后面其实影响用户体验的不是后台原因，而是公司的带宽扛不住了。技术上能做的无法就是减少每个POST包的信息，外部依赖JS或者CSS走CDN，其实效果也不算太大，老老实实去扩了公司的带宽。

你能想到我能用自己的电脑CURL生产接口给自己发钱吗？

首先申明我是个有职业道德的人，小公司的权限就是这样乱给的，我甚至可以本地eclipse对生产的代码远程debug。没有docker、k8s，公司的生产机器也是vmware分割出来的，权限没有任何限制，无非是知不知道生产密码。接手负责人后赶紧安排运维加网络限制，所有的流量只能从F5（奇葩，那么小的公司居然还有钱买F5，而weblogic用的是盗版）进来。生产环境控制台也只能走跳板机，跳板机也限制申请了权限的人登录。

C公司的商家支付

来到C公司了，不用写代码了朋友们。因为我是架构师了，只需要做设计安排方案即可，不用落地代码。跟着CTO将公司十余年内公司的200多个项目重新做了梳理规划，DDD的思想的确好用，就像你原本凭借经验就知道应该做的事情有了理论的依据。我天真的以为我不会再去coding项目落地了，我想得太简单了，一日程序员，只要还在IT行业内，逃不掉的。

你了解过第四方支付公司吗？好用吗？

CTO去创业了，我们跟着一起过来了，公司提供了一个引流项目。大多人应该在买东西时候扫过商家的码或者被扫码。这个引流项目就是扫商家码的支付系统，关注小程序再扫码支付有较大优惠，再一次安排我负责该项目。好吧，带了两个外包直接搞起。

第四方支付公司不是我选的，集团安排的对接，根本没得选。其实他有三方支付牌照，但是他一家银行没对接，对接了各种你能想到的支付公司，主流也就支付宝和微信。

我本以为和A公司的购物支付差不多，还真不完全一样，A公司的角度是C，作为客户对接进行支付即可。而这里我们的角度是B，除了应用的支付后端模块外，还要增加前端收银台拉起，做过的人应该都知道，支付公司返回一段JS帮助C端付款时候拉起本机收银台，输入密码完成支付。

同时，作为商家角度还需要增加订单管理、退款处理等功能。我觉得有个经验可以分享下，不要依赖四方支付公司的支付异步回调，因为整个支付链路较长，异步通知往往来的很迟，这对C端的使用体验非常不好，商家就会来投诉，基本上都是依赖支付结果查询结果。

可能是因为烧钱了，流量还真不少。并发不算高，最多就是几十，但是持续时间长，只要白天有消费的时候都会有支付产生。那么在技术上就要有一定的控制：

• 前端的防重，限流，熔断先安排上，根据业务确认了幂等键，使用分布式锁控制起来。
• 业务校验之前需要有一个安全验证，针对用户ID进行限制，因为一个用户不可能同时扫描两个商家码，同时在时间间隔上也要限制。
• 在交易和用券的过程中注意状态机的设计，每笔订单最终都要走到终态。优惠券也要加幂等校验防止被重复使用。
• 我们对IP的访问量其实也做了限制，但是以我的了解手机用户的IP应该用的都是基站的，这块是否起到作用至今未知？了解的朋友希望帮忙解答下。

还好的是，这个项目一直没有出现过问题，让我平平安安度过了整个项目周期直到CTO创业烧掉营销资金然后创业失败，哈哈哈。

D公司的海外放款

D公司的业务还是挺广的，除了大陆信贷业务外还有香港信贷，大陆的信贷业务我了解到的资金细节并不多，只是作为架构师帮助评估过技术方案和需求冲突点。

你知道吗？在你决定贷款的那刻起，信贷公司就安排好哪张银行给你提供资金。

国内的地方商业银行往往都不会像四大行那样业务广泛且不缺客户，他们的技术能力也也不足也支撑他们全国铺开业务。于是D公司这样缺少资金的就会找到他们，当然拿到的利率也不会低，但是不重要，再加上保险费，担保费这些一起让消费者承担好了。不然你以为动不动20%的年利率是怎么冒出来的。

D公司有一个资金引擎，资金管理平台有配置几十家银行的放贷额度和利率等信息。当用户确认贷款意向后，引擎就会根据用户的征信等数据确定好了提供资金的银行以及利率。每家银行当然也不是D公司一家帮他们放贷，资方永远是大佬，就算是再大的中间公司也要和银行搞好关系拿到资金，因为中间担保公司是不允许用自有资金放贷的。

你对接过香港的金融支付系统吗？推不动啊。

D公司香港开展的放贷业务，不出意外的是支付系统又是我负责。对方是一家巨无霸国资银行，全世界都有业务。不知道是不是根本看不上我们这样刚去香港的小虾米，全程推的累啊。业务合作就谈了三个月，不过与我无关，聊聊技术这块的。

有人看过财务使用的银行的企业管理控制台吗？我们刚开始放款用的是那个，支付系统根据最终的放款需求做一个报盘文件，把文件给到财务，财务上传放款。我没想到有天支付系统还可以这简单。然后开始自动化放款，好嘛，故事原来才开始。

代扣代付在大陆是非常普通的业务，在香港可不是。支付容易，代扣业务就很麻烦了，香港是不太容易允许直接从客户银行卡里面直接扣钱。在技术对接银行的支付中也需要注意很多：

• 交易需要幂等、幂等、幂等。从上游系统到支付系统，支付系统到银行。不可以有一个地方出现重复订单，IT上的网络抖动也不可以。
• 所有的应用部署在香港云环境，香港是不允许数据出境的，进大陆也不可以。
• 同样的，异步通知不可能，要自己主动去查交易结果。
• 香港放款美元很慢，不知道是不是因为走SWIFT的原因，有时候两三天后才有最终结果，失败的话公司流水上有一条REFUND记录，所以技术上不能以公司账户中成功扣除了作为放款成功的依据。
• 港币走FPS还是蛮快的，但是有1M的限制。

D公司的支付系统我是最小心的，别看一天交易就那么几笔，但是最低放款50万港币，最高的放款100万美金，我尼玛赔不起啊。宁愿放不出去，也不能多放！

最后

人生有时就是玩笑，自从多年前面试被多家支付公司拒绝后，本身不想再接触支付这个行业，没想到人生如戏，抬头都是冤家。反正都是生活，笑着面对吧，做好每个业务使用的支付系统，怎么说我也一直是支付公司的甲方不是。

欢迎使用haptool.com(哈普工具)，让程序员的工作更有效率。