文章目录
一、支付路由的架构设计
1-1、设计目的
- 省钱。哪个支付通道更省钱选择哪一个通道
- 提升支付产品的QoS。这体现在系统的可靠性、稳定性、性能和可用性上。通过屏蔽掉无法连接、不稳定、性能低的通道来提升这些指标。
- 支持营销。通过优先选择有优惠活动的通道，可以帮助业务提升付费客户量。
- 降低运营成本。
1-2、系统架构
二、支付路由的计算因子
三、支付路由的限制规则
3-1、银行与渠道黑暗期
- 支付渠道或者开户银行会不定期发布某个银行或者整个支付渠道维护的公告，例如中国银行将于X月X日凌晨00:30至03:30进行系统维护，届时代收业务将受影响。
- 作为支付路由的重要因素，为了进一步保障交易成功率，支付路由方案需要考虑银行与支付渠道维护信息（即黑暗期）。在黑暗期内的支付渠道要避免将交易路由过去，以免由于通道不稳定而导致交易失败。
3-2、余额不足次数阈值
为了降低客户投诉量以及进一步满足开户银行风控要求，支付渠道一般都会对商户的代扣交易中“余额不足”的报错次数进行限制。（这个可以坑到被银行停掉代扣通道）
3-3、单笔鉴权验证
- 使用不同的渠道需要不同的授权。
- 授权无法静默（需要有短信验证码）
3-4、通道启停控制
因商务或者其他原因临时停止某通道时，应能做到一键迅速关停。
3-5、交易量分流
- 商务层面：由于BD一般要跟支付渠道打好关系，因此当支付渠道要求增加交易量时，可以通过每个支付渠道的交易量分流来实现。
- 支付渠道维系：虽然某个支付渠道可能由于价格较高或者稳定性较差等原因，导致路由选择不到该支付渠道，但作为后续支付渠道的备份，系统仍需要少量的走一些交易到这些支付渠道。
- 技术层面：当某个支付渠道出现不稳定表现（比如单位时间内异常数量增加）时，需要临时降低该支付渠道的权重，增加系统的整体稳定性
四、支付路由的软件架构
- 业务系统和支付路由系统分离
- 服务发现能力
- 本地缓存+同步
五、支付路由的理想与现实
5-1、手工路由
- 大部分支付系统在接入渠道不多时，人工路由也是一个不错的选择。运营人员指定支付渠道和产品之间的映射关系。出问题时人工切换即可。
- 这种路由的优势是性能高，路由结果可控，出问题时易于排查问题。当接入通道数量增加，营销活动频繁时，人工路由会是一个巨大的投入。
5-2、基于规则的路由
这种相对比较简单的自动路由设计。按照业务要求设置各种路由规则，比如：
if (支付方式 == 招商借记卡 && 额度<100) then 目标通道 = 招商快捷支付
技术上，规则可以使用规则引擎drools来描述。
5-3、基于权重的路由
规则路由的难点在于各种规则的制定。
在路由因子增多的情况下，规则的维护会是一个噩梦。基于权重的路由则可以缓解这个问题。这种计算方式，简单说，就是对各个通道打分，分数最高的就命中。难点在于制定打分的标准以及计算公式。
比如可以从费率、优惠额度、QoS和使用率角度来评分，给优惠额度高一点的比重，这会导致高优惠额度的通道被优先命中。
注意每个维度上的计算公式也不是一成不变的，比如使用率和QoS都是动态打分计算。
权重的调整是一个挑战，需要在运行过程中不断的调试。必要时，可以使用旁路测试来比较两种算法的优劣。
路由是支付的核心模块，稳定性是第一要素，其次是性能，
最后才是怎么省钱。路由系统的设计，需要和公司业务发展保持一致，并适度超前。
简单的if-else实现可以满足大多数场景下的需求。避免在系统建设初期引入过于复杂的路由。
六、在实际支付中遇到的典型问题
6-1、充值掉单
- 问题描述：客户在账户中心显示的状态为充值中，余额未反应本次充值，但银行账户中的钱已经被划扣成功。
- 问题原因：三方支付公司同银行间的接口出现异常或者超时，未向我方系统反馈充值结果。
- 最初解决方案：客服接到客户反馈后，通知运营人员由运营人员通过交易流水号核实该笔充值在三方支付公司正常完成后，手动将交易金额充值入客户账户。
- 优化后的解决方案：系统通过定时任务每5分钟对充值中订单自动进行最终状态确认，如果是交易成功就自动将余额充入客户余额（补偿）
6-2、提现最终一致
- 问题描述：客户提现，账户中心显示提现成功，提现记录也显示提现成功，查询第三方的交易明细也显示交易成功，但是钱就是未到客户银行卡
- 问题原因：该种交易都未走央行的超级网银系统（金额超过5万也是事实），而使用银行间结算系统，在进行结算时出现故障导致款项未到客户账户中，提现金额会在7个工作日后自动退回支付公司，但是支付公司不再通知我们。
（已知的一个清算错误的原因如下：公司的全称中包含了一个全角的括号，但是银行间结算系统部分情况不识别全角括号，导致一部分付款处理失败，需要人工核对后人工处理。） - 解决方案：无有效解决方案，需运营人工处理。因为提现成功的状态已经不再是最终状态，存在先交易成功然后7天后该笔交易又变成交易失败，需要退回金额的情况。系统自动工作存在安全风险，需要人工审批后，系统自动核实交易流水后自动对该笔提现进行退回。
6-3、提现操作防止重复提交
- 问题描述：客户申请提现27万，实际到账了54万。
- 问题原因：银行的最终支付接口防止重复提交出现bug，导致同一笔交易被执行两次。
- 解决方案：无有效解决方案，客户不反馈我们都不会发现。理论上我们应该每日和三方支付公司或者银行对备付金账户的实际金额和指令金额是否一致的，但是由于备付金账户的钱实时都在发生变化，而且变化时间点不受我们控制，且支付公司和银行也说不清楚。导致无法完成虚账和实账的对账工作。
6-4、同人同出保证
- 问题描述：客户投诉账户金额被非法分子盗刷。
- 问题原因：用户密码被不法分子盗取。早期为了更简便的实现客户入金，在入金前未要求实名验证，只有在提现时才进行4要素验证。并且不投资的钱也可以直接提现。导致不法分子将客户的钱提现到了第三人的银行卡中。
- 解决方案：初次入金前要求必须完成实名验证和银行卡4要素验证，银行卡的换卡环节加入人脸识别确认是本人意图操作。
6-5、QoS保证
- 问题描述：现在的支付系统基本都是采用https协议，IPsec，公共互联网环境，掉单率，网络延时，TPS均无法达到要求。
- 掉单率：反应各三方支付公司实力的指标，在使用过的三方支付中，京东的掉单率为0（使用期限较短），其他的通道均在万分之2左右。（15年~16年支持pos机充值的时候，掉单率比这个数值要高很多）
- 网络延时：公司的支付通道在从A系统切换成B系统后，支付系统的延时从20ms级别上升到了200ms级别。且高峰时超时现象从万分之5左右，上升到了万分之65左右。导致了系统在切换后出现了大量的客户投诉。引入了实时补偿功能后系统才恢复正常。
- TPS：这个非常可害怕，根据我们的经验发现三方支付的系统是多商户公用的，一个商户的瞬时峰值会对其他商户的支付TPS造成影响。严重时甚至会由于其他商户的影响造成自身的瘫痪。需要支付路由动态切换。
七、简易支付路由设计
由于生产环境的B支付通道出现突发情况，直接单方面通知我们即将停用，造成了非常被动的局面，在短期内紧急商谈了C通道（付出了费率等方面较大的代价）。
为了将来的系统稳定性考虑，后期会接入多家支付，因此进行了一个简单的支付路由建设。
以下为根据公司实际情况做的设计概要，供参考。
【需求背景】
为了支付通道的稳定性，公司将陆续接入不同的支付通道。
在通道出问题时，能快速的切换到其他支付通道。不同的支付通道的成本、稳定性、可靠性各不相同。
我们一期支付路由规则比较简单，只考虑静态路由。
【规则条件说明】
规则的条件主要有银行单笔/单日限额、支付通道是否可用、支付通道对应银行是否可用、支付手续费、通道流量占比。
-
支付通道不可用，有些突发情况，支付公司系统突然无法访问或者支付通道的短信渠道出问题或者其他问题，此时需要禁用支付通道下所有的银行
-
单笔限额保证用户支付时提供满足单笔限额的支付通道
-
支付公司对应银行不可用，支付通道的运营流程中，如果银行临时维护，支付通道会通知商户银行的维护时间，此时需要在维护时间内支付通道对应的银行不可使用
-
支付费用，考虑成本原因，会优先使用费用低的支付通道
-
流量占比，考虑满足单笔、费用又相同有可能有多个支付可以，此时用户会使用流量占比高的支付通道。
【路由规则】
- 正常处理逻辑
-
优先查找是否有可用支付通道，如有可用支付通道，看单笔/单日限额是否满足；
-
满足单笔、单日限额有多个支付通道，则按照支付金额，计算每家支付通道的费用，优先费用低的支付通道；
-
费用低的有多个支付通道，则使用流量占比优先的支付通道。
-
异常情况：若是支付的金额 不满足 所有支付通道的银行限额，则默认选择此优先通道去进行支付。
-
优先通道也支付失败，则进行提示：本次支付失败，请联系客服。
