这篇不聊技术，换回支付金融相关话题。
总结一下，我自己做开发这几年，参与的项目比如P2P、保险、、证券、消费金融，本身就围绕着钱在转，电商系统也是，多是和钱打交道。
系统和钱有关系的除了虚拟资产，就是支付。
具有支付能力主要有两类，第三方支付以及直连银行。
自己有幸，多少都接触过，踩过的坑儿，不少。遇到有意思的事，也不少，今天唠唠。
先提前说下，我是作为支付的使用方，所以对于第三方支付以及银行系统的开发人员，最好不要阅读，我会抱怨很多，锅嘛，总得找人来背。
专业一点，我们把银行以及三方支付当作一种支付渠道，或者支付通道，支付行业里名词其实不少，统一一下概念对后面的理解有帮助。
这里支付渠道==支付通道==XX道。
什么是通道？
道儿，是人走路的，从一个地点通向另一个地点。
金融系统的通道也是这样，不过道上经过的不是人，是资金。
所谓通道，就是一个能把金钱从一个卡转移到另一个卡的方式。
或者在本质一点，支付渠道是能操作我们共识的资产账户，一个账户余额减，另一个余额账户加。
对于通道，站在不同的角度问题去看，是截然不同的。
我画了下面这个图：
平台使用方角度看到支付渠道
作为平台需要支付能力的开发发人员，看到的，需要的通道，可以是某具有支付牌照的第三方公司，比如支付宝、微信支付，和XX宝之类的支付公司；
或者你有足够的能力，能直连银行系统，或者直连银联、网联系统，这些都能成为你支付系统的通道的备选方案。
这里澄清一个概念，对于短直连，断的是三方支付公司与银行的直连，某些具有特殊业务或者牌照的业务线还是能直连银行的。
三方支付角度看到支付渠道
如果你是某个具有支付牌照，对外提供支付能力的第三方公司，你看到的通道是那些金融机构：银行、网联、银联是你应该抱的大腿，你靠联通他们的系统，间接具有转移资金的能力。
银行的角度
如果你是金融机构比如银行，央行就是你的通道，跨行、结算清算都是央行的职责。央行系统才是是金融活动的根基。
总结一下：
通道的理解是分层次的，下层为上层服务，监管机构严格执行这套体制，各司其职，每一层的角色有不同的监管标准和要求，我们能做的就是在合理合法的基础上，为用户提供更低更好的支付能力。
下面是干货，作为业务方对接支付公司以及银行的一些实战经验，或许叫做踩坑经验更贴切。
对接一个支付渠道大概的流程是这样的，商务对接；签订合作合同；产品经理介入；需求制定；开发人员参与；产品上线测试...
这里详细说一下开发人员做的事：开文档了解业务》要demo》要测试环境》开发》接口调试》综合联调》上线》改Bug......
第一条：
不要全部相信支付公司的文档，不要全部相信支付公司的文档，不要全部相信支付公司的文档，重要的事说三遍；
文档干什么用，了解大概业务就可以了，比如有签约、验证、支付、代扣、代收....等接口就可以了，看看会不会和其他家有特别大的区别。
当商务和支付机构谈下来合作后，对方一般都会提供接入的文档，这个文档就是一份对方的接口功能介绍和使用说明。
支付宝微信牛不？牛，支付开发文档怎么样？对接过的，没有不吐槽的。
所以，给大家介绍个小技巧，和对方人员沟通时，可以先问问其他人怎么使用这些接口的，千万不要自己是第一个吃螃蟹的。
更不要当他们线上新功能的小白鼠，资金系统不是闹着玩的。
第二条：
一般支付公司为了支持众多使用者，提供的接口较多，同一个功能也有多个实现。
所以先确定自己的功能需求，把业务与对方讲明白清楚，一般对方开发人员会比你更了解，对于使用哪些接口，他们一般很快就能想到。不仅节约了你的时间，代码安全上也有保证，他们都会推荐自己觉得靠谱的接口。
第三条：
每一个参数，即使文档以及demo字段有备注，也要多问问，比如必传／非必传就有一定的时效性，对方可能改了代码，但说明文档没有及时更新，这个坑太常见。
第四条：
举个例子，对于查询接口，一定要把是时间控制好，不是所有系统都支持全类型查询的，时间的格式要求。
记得有一次没传查询时间范围，对方系统也没有参数校验，导致了一个严重的全表查询，效率极低。
时间点也要控制好，尤其是起始时间、截止时间是否包含当天。这些边界小问题往往在对账中能引起大问题。
第五条：
友商的返回值和返回描述很重要，一定要和对方确定好是以码为准，还是以描述为准，不要笑，真的有支付公司系统以描述为准的。
还有一点，返回码和描述的内容，你以为是你理解的，可是会啪啪打脸，差距会很大，一定及时沟通，问清具体含义。
最极端的，有的支付公司的，有的接口返回值描述的都是系统异常，这个就蛋疼了，你需要自己去猜，去拿案例去验证，拿线上错误来尝试，坑爹。
第六条：
友商不只对接你一家，功能业务升级很常见，和我们一样，银行和第三方支付功能的开发人员也许还不如你呢，所以，偷偷的上线，你没有一点防备，线上出现报警，你左查右查，什么原因呢，代码没改动呢，悄悄的告诉你，问问友商有没有接口调整。
小技巧，友商的线上发版时间一定要提前熟知，一般金融系统会有定期的发版周期。
友商发版时间内，注意留人观察我方系统是否受到影响。
在我合作的这些公司上，时不时的会遇到发布新功能，但是带着伤。你必须不要被友商拖死，他们可以发公告由于网络原因。。。，你怎么办?
第七条：
金融系统都会对安全要求很高，对IP有严格的限制。请求合作方，合作方回调，都会遇到直接使用IP的场景。
此时定要及时的通知双方IP变化。
记得有一次，合作方的域名解析改变，这么大的事情我们没有收到通知，入金充值请求根本无法使用，费了九牛二虎之力排查原因，谁曾会没有想到对方IP会变化。
Https证书升级。
支付系统大多是HTTPS请求，难免会遇到证书变化，证书升级。这个也要注意。
通讯协议变更
支付接口的加解密也要注意，同一个文档上的不同接口，加解密方式也有可能调整，因为合作方的升级也是慢慢更新，你本协议没有变化，一旦上线，又是想不到的问题。
第八条：
做支付失败率最高的可能是因为限额问题。
对方提供的限额根本不准确，通道不能用，友商也不来不及告知。
毕竟支付公司的通道一般受对接的银联、网联银行诸多影响，有的公司能及时动态调整，有的做的不尽如意。
我们需在把握合理的阈值，保持金额略低于对方提供值，或者失败后动态调整限额。
第九：
对接过支付公司都会知道，有日间数据和日终数据。但是同样是一家公司的系统，日间和日终数据也会出现差异，一定要和产品同学和合作方沟通好，以哪个数据为准。
不同的问题，对应不同的解决方案。记得有一次合作方提供的日终数据为空，代表着什么啊？我们白天做的可能都是错的，当时慌得一比，幸好及时和合作方确定是他们的系统问题。
第十：
你觉得银行核心系统会出问题吗？有人说不会，这出现问题还了得。
负责人的说，是程序员写的代码，就会有bug，银行系统也躲不过去。
记得又一次对接的银行系统升级，资金账户全乱了，对账报警一条接着一条，我们都傻眼了，怎么了，天塌了。
最后怎么了，银行账户系统出现问题，想都没想过，以至于我把自己的资金都从该家银行转移出去了。
其实你也应该理解，银行的核心系统早期都是部署在大型服务器上的单体服务，很少升级改动，那些核心代码更是不可能改动，也许是互联网的冲击，银行内部也掀起了去单机去IOE的行动，花了很长时间和成本去改造核心系统，所以出现问题也能理解。
还有一些关键时间点，除了对方系统的发布时间，银行的一些跑批时间也要小心，比如切夜这个时间点，有点银行12点，有的11点，有的1点2点的，总之，这段时间的资金其实不准确，即使普通客户，你在该节点去充值体现买理财，收益利息什么的计算都会有一定误差，为什么大多数人发现不了？其实银行按年按月，都会慢慢的找补给你。
还有一次遇到最想不到的事，对接的合作方居然线上环境和测试环境没有分开，也是由于我们自己代码造成了多线程的死循环，不要去频繁请求合作方，最终友商赶紧让我们杀死进程，他们的线上库都快拖死了。
所以，最后一件重要事，使用接口时，询问好QPS和TPS。
今天列举对接银行和支付机构的十宗罪，不是嘲笑，我们只是作为使用方在挑刺儿，如果让你去开发服务方代码，这些问题你就能处理的好吗？
对接的多了，怀疑人生是常有的事儿，墨菲定律，你担心的总会发生。
最后一条建议，保存好对方紧急联系人，这是最重要的也是最有效快速解决的一个前提，不要大半夜想找人都找不到，干着急。
本文完。
