随着公司业务的开展，发现多个环节需要用到支付。我们在购买聚合支付的时候，每年年费不同，享受到的服务也有很大的差距。当资金有限的时候，我们选择了较便宜的服务，这个时候我们能创建的支付应用数量较少，因此我们需要打造支付中心。

其实很早就发现了打造支付中心的想法，但是因为一直有业务在跑，而且很多模块是已经离职同事开发的，每次优化调整都带来了损失，后来领导决定不动了，因此后来就搁置了一段时间。

但是上了新业务，逐渐的发现要支付，而聚合平台新建的应用也已经满了，只能建立支付中心了，领导正束手无策之际。我给他建议，老的那几个应用不动，后面几个较新的腾出2个支付应用的地做支付中心，一个生产，一个测试。

谁能想到，那么多同事一直死板的看问题，就在我的小小建议下，支付中心却诞生了。就支付中心本身来说没什么技术含量，就是在原来支付的基础上增加一些管理功能，对原应用来说就是做一个h5对接。但是要注意的一点，安全要考虑一下，建议加一个“支付金额黑名单”。

支付金额黑名单是什么意思呢？就是说我们很多时候都是凌晨上线，还要在线上测试、这个时间点头晕，线上测试的时候很多时候改成1分钱实际支付；一不注意就会在线上留下1分钱的漏洞，被别人薅羊毛。这个时候我们支付中心采取金额黑名单。比方设置黑名单，1分钱支付的只允许1单（每次测试的时候，支付中心后台加一单）。这样就算程序上有bug、测试数据忘记删，也不会造成大损失。

另外支付中心还有一项工作，就是要智能判断：h5、微信、app。

最后补充一个坑，支付中心尽量准备至少2套方案，而且要做到快速切换。支付有被封的情况，这也是我当初没料到 的，作为一个程序猿，尽管野生程序猿思路活跃一点，怎么也料不到技术之外还有坑。1分钱测多了容易产生支付的时候有恶心提示或者短时间或局部地区的功能受限；公司因为某些原因违规或法律纠纷能直接导致支付关停。所以很多时候公司的老板或股东会注册其他名字接近的小公司，申请支付接口用于临时救急。