一般来说，银行会提供两种支付途径：无跳转的快捷支付接口和带跳转的网银接口。前者在绑卡，支付的时候，不需要跳到银行页面上去处理，后者则需要在银行的网银页面上完成。显然前者对用户来说体验要好多了，用户流程不会被打断。快捷支付要求支付系统在本地保存用户的支付信息，如卡号，登记手机。系统要确保这些信息不被泄漏。风险非常好，所以大部分银行要求接入方必须经过ADSS检验才能够接入快捷支付。
这种固定方式的接入有单点故障的问题，一旦某个渠道出问题，绑定的支付方式就无法使用。改进策略是为每个支付方式定义多个渠道，第一个渠道出问题即选择第二个，以此类推。
当然，更进一步，可以为候选渠道定义权重，按照权重来选择支付方式。当渠道出问题，自动调整权重。
路由实现上还会更复杂，对同一张银行卡，运营上会要求在不同的系统上，比如android，iOS，windows上，或者不同地区，如大陆，台湾，香港，北美等，甚至不同业务上，采用不同渠道来支付。
支付渠道
如果采用微服务来实现，整体设计上，可以考虑将支付渠道分离、支付网关前置分离。支付渠道的微服务实现有两种策略，一种是按照服务来拆分，一种是按照渠道来拆分。
● 按渠道拆分，指每个渠道单独部署在一个容器中，对支付网关提供相同的服务。
● 按服务拆分，是按接口来拆分，分为支付，对账，退款等子系统，每个服务单独部署，所有容器的服务都实现在一起。
渠道拆分
按照服务来拆分的一个典型案例是大众点评网的早期实现。 大众点评支付渠道网关系统的实践之路。 每个支付服务接口实现为一个独立的子系统，独立部署，通过支付网关前置来对外提供服务。 这篇文章里面也提到这种方式存在的问题，
● 银行的加密客户端会有各种奇葩的需求，有些可以支持linux，有些要windows系统，如何在一个容器中满足所有需求？
● 这样拆分后，每个渠道接口独立部署。某个渠道出问题也不会影响其他渠道。至于渠道访问量小导致资源浪费问题，可以通过虚机或者docker的资源调度来解决，谁也不会在物理机上玩微服务。
● 对接渠道难点在于对输入输出做加密和解密，以及组装和解析报文。同一个渠道对不同的服务的加密解密方式是一样的，报文格式也是一样的。按渠道来构建服务可以共用这样方法，减少开发投入。
● 从安全的角度，按渠道划分也有优势。一般渠道都要求只对接到特定ip的机器，这样每个渠道对接系统所在的机器仅开放对渠道和支付网关前置机的访问白名单即可，尽可能的缩减被暴露的风险。
接入渠道
对于支付渠道，首先考虑的是接入哪些渠道。要对接的渠道按优先级有：
● 第三方支付，对大部分应用来说，支付宝和微信支付都是必须的，一般来说，这两者可以占到90%以上的交易量。用户不需要绑卡，授权后直接支付就行。各种平台都支持，性能和稳定性都不错。对于一些特殊业务，比如游戏，企业支付，可以查看一些专用的第三方支付平台。
● 银联，这货的存在，极大方便了和银行的对接。和第三方支付主要不同在两个地方一是需要绑卡，也就是用户先把卡号，手机，身份证号提供出来。这一步会折损不少用户。绑卡后，以后的支付操作就简单了，用户只需要输入密码就行。手机客户端不需要像第三方支付那样安装SDK，都在服务器端完成。当然，这是针对快捷支付。网银支付还是挺麻烦的。银联接入也需要ADSS认证。
● 银行，建议先看这一篇文章，了解下对接银行的难度。那最终需要选择哪些银行？先看个统计数据。 截至 2015 年底，我国银行业金融机构包括 5 家大型商业银行、12 家股份制商业银行、133 家城市商业银行、5 家民营银行、859 家农村商业银行、71 家农村合作银行、1373家农村信用社、1 家邮政储蓄银行、3 家政策性银行、 311 家村镇银行、48 家农村资金互助社。优先选择5家商业银行，他们占40%的交易量。其次是股份制银行和邮储。这就18家银行了。老板要是不满意，城商行和农商行加起来有1000多家呢。一般对接一个银行预计有3周左右的工作量，大部分银行需要专线接入，费用和带宽有关，一年也得几万费用。不同银行对接入环境有不同要求，这也是成本。另外，还有一个重大风险，就是央行在搞得网联系统，毕竟还没有出来，相关资料参考知乎上关于网联的一篇讨论。
● 手机支付，现在不少厂商都内置了各种支付，比如苹果的In-App支付， 三星支付、华为支付等， 这些支付仅针对特定的手机型号， 支持NFC等，根据业务需要也可以接入。 就是目前用户群不大，收益不明显。
● 话费支付， 这一块容易被人忽略，但考虑到国内不少职场人士，话费是公司报销的，每个月多的用不完，所以这块支付还是相当有市场的。 问题是，联通和移动两大运营商，不仅接口不能互通，内部各个地域也是各自为政，所以对接起来还是有点麻烦。不过话费支付领域也有类似支付宝微信的第三方支付公司，比如虹软、联动优势等公司。
这篇文章对支付系统整体设计做一个概要描述，后续会逐步补充内容并完善。其实每个模块都是一个大坑，有很多的技术细节。
原文地址:https://blog.csdn.net/sz_bb/article/details/53300999
原文地址：https://www.cnblogs.com/jpfss/p/9290064.html