多渠道支付平台建设 第1篇
支付渠道有很多，常见的就是微信支付宝使用者众多，几乎每一个人的智能手机上面都有这两个软件，日常转账付款都是使用这两个软件，但是随着移动互联网的快速发展，致富渠道也越来越多，包括京东钱包，百度钱包，云闪付等平台都是可以进行支付的。而第3方支付通道，其实就是把各种渠道综合在一起的一个支付平台，可以接收多渠道的账户收款。例如聚合支付，支持多渠道收款。
商家怎么选择支付平台
作为商家，如果想要应对用户各个支付渠道就需要选择一个靠谱的第3方支付平台。首先这个支付平台要适应多元化渠道支付，可以接受各大平台的支付收款。其次这个支付平台应该保障自己安全，毕竟对于商家来说选择这个平台就等于把账目全部展示给这个平台，如果平台比较靠谱，就能够保障自己安全。
多渠道支付平台建设 第2篇
路由要素有很多，下图列了一下常见的要素。
渠道与支付方式的映射关系：是某个支付方式可以走哪个渠道的关键配置。
通道限额：除了微信或者支付宝支付的，银行卡支付通道都是有单笔支付限额，以及日限额。
渠道状态：渠道当前是否可以用。
渠道权重：比如建设银行-借记，提交筛选完之后，还有2个渠道可以用，这个时候就需要通过配置的权重，选择有限走哪个渠道。
白名单：渠道上配置白名单，白名单类型可以是卡号、买家用户ID、卖家用户ID，如果配置了白名单，在满足渠道条件之后，会优先走这个通道。
产品码：做业务区分。根据前面场景分析，某些渠道只能走特定的业务。
支付环境：同一种支付方式在不同的环境路由到不同的渠道。比如微信支付，可能的支付环境有：微信小程序环境、微信h5环境、SDK环境、浏览器环境，环境不一样，实际发送渠道请求的参数也不一样，所以需要进行区分。
渠道费率：每个渠道都会收手续费，会有一个费率配置。在实际路由配置的时候，费率选择问题可以和权重进行合并，运营人员直接根据产品策略，配置渠道权重，以达到目的。
维护时间：通道会有维护时间，即某段时间不能接受交易请求。银行类的交易，维护比较常见。
多渠道支付平台建设 第3篇
提升用户体验。一般如果支付失败，渠道都会返回对应的错误代码以及错误原因，但是有些渠道，特别是银行卡支付的时候，因为失败的原因有很多种，且渠道直接返回的原因，如果直接展示给用户的话，用户不一定能理解，所以需要做一层转换，转换成用户容易理解的文案。
退款都是原路退，即支付的时走的银联，退款的时候也走银联渠道退款。但是也有情况例外，比如：
超过通道的原路退款时间：每个通道不尽相同，有的是一年、两年或者更久，也有个的只有6个月，比如微信支付宝。超过期限就不能原路退了。
原路退异常：比如微信账号注销、卡注销等等。
所以退款这里，还需要考虑下无法原路退的情况，应该如何处理。
这块涉及的功能和支付流程类似。需要额外考虑的是如果所有的提现渠道都有问题的时候，提现流程如何进行处理。
根据上一部分的业务场景分析，支付渠道管理系统的架构设计如下：
多渠道支付平台建设 第4篇
退款渠道的路由很简单，就是退款的时候获取到原单渠道，那么这个渠道就是退款渠道。
这里不仅有支付失败的错误文案映射，也还有订单状态的映射，因为渠道的返回报文有对应的返回码，这个在对接时候，渠道方会告知哪些返回码是成功的。这块的处理流程如下：
不管是支付、退款还是提现，补单流程是统一的，如下图所示（图十一）：
不同的是，支付/退款/提现的查询，需要请求不同的接口，需要跟进订单类型进行适配。
这里说的超期包含2种情况：
一是这笔退款订单的处理超过了一定的时间还没成功，我们就认为可能是有问题。这个时间是多少呢？不同渠道还不一样，微信或者支付宝的退款一般是很快的，银行卡的退款可能会慢一点，最长可能会到几天才会成功，所以这个时间配置在渠道配置里；
二是这个笔订单像上面说的几种情况，没办法原路退款了。
这2种情况我们都是需要发现并解决的，毕竟最终是需要把钱退给买家的，所以我们需要把这部分订单找出来，然后进行处理就好。整个处理流程可以设计如下：
这块核心就是需要把这个订单发送到【线下处理系统】（一个能承载这部分订单且能串通这个流程的系统即可）。对于处理方式，常见的有：
联系买家，进行线下打款，打一笔资金到买家的银行账户或其他的收款账户。
如果是渠道系统问题，可以再把退款单进行原单重新发送（前提是渠道支持重复发送）。
这里的支付银行和收银台侧支付方式对应，是用于后面配置支付渠道路由。
支付渠道管理维护了支付通道的基本信息。描述为：哪个机构（外部机构的简称）、什么业务（入款、出款等）、什么支付类型（借记、贷记渠道）的通道，并为其定义一个在该支付平台的唯一通道编码。其中：
渠道路由维护了支付银行和支付渠道的一些条件，如果需要修改。
白名单管理是为某个用户或者是卡号添加渠道白名单，在白名单列表里，渠道路由的时候有优先走这个渠道。