经验分享｜支付渠道的可用性设计，背后的产品思路是这样的
笔者近期负责提升支付渠道的可用性，做完后有些想法，写出来和大家分享下。
需求的源头
用户在进行支付时，有时候会出现银行系统不可用、超时情况，导致用户不知道明确的支付结果，那么用户80%会进行投诉，客服处理完后，这个用户就基本上和支付/电商平台说再见了。
要满足上面的需求，我们就需要关注以下几个问题：
- 银行系统出现异常是否能及时进行故障隔离？
- 如果要隔离，是否能第一时间发现银行系统出现异常？
- 如何判断银行系统出现了异常，异常的原因是什么？
其实这三个问题对应的解决方案很明确：
- Q1——我们需要一个路由系统
- Q2——我们需要一个监控系统
- Q3——我们需要一个错误码表
在产品设计过程中，我们按照Q3 → Q2 → Q1这种自下而上的方法去进行。
产品设计
我们需要一个错误码表
一家支付公司或电商平台接入的银行渠道都很多，而每家银行都有自己的错误返回规范。那么，这时候我们就需要将N家银行返回的错误码进行抽象，建立一套错误码表。
渠道错误码分类
错误码的拆分维度有很多种，我是按照渠道可用——>用户信息校验——>交易来分类的；渠道不可用、用户信息校验、交易这3个只是大类，还需要针对每个大类进行二次拆分，细分出小类，小类分的越细，遇到问题定位的也就越快，同时对接下来的两步也就更有帮助。
我们需要一个监控系统
对于监控系统，存在着一些基本要求：
- 监控的对象要具体，最好能细分；
- 监控的指标要足够明确，每一个独立指标的计算方式要简单；
- 监控指标要有时效性。
那么，针对支付渠道的监控系统，监控的对象应该要具体到所有接入的银行渠道；监控指标要对每个银行进行个性化定制，因为每家银行的系统性能都不一样；
监控指标设定的维度也很多，因为渠道在整个支付链路的底层，对系统层面要求比较高，所以监控的指标如下：
- 每个渠道调用的平均耗时
- 每个渠道调用的系统成功率
- 每个渠道调用的耗时峰值
- 每个渠道调用的异常订单数
监控指标的时间跨度建议根据业务量来设置，一般采用秒级或者分级；监控指标定义好后，我们就要为每个渠道设置告警规则，这些规则的阀值需要根据日常的交易情况和每个渠道自身的属性进行独立设置；而规则的触发就要依靠渠道错误码表了。
这样，监控系统就可以在某个渠道出现问题时，根据错误码表来分析当前的异常属于哪一类，是否影响到用户的正常支付，如果影响了，就会发出告警。
我们需要一个路由系统
一个支付产品最终于能让用户顺利的&愉快的完成支付；而让用户顺利的完成支付依赖于出现异常的通道。
能否被及时的隔离掉，同时能否将用户带到可以正常支付的通道上，路由功能做的就是这件事情。
为此，我们也需要在路由系统中对每一个渠道设立一个路由规则；这个规则将告诉路由系统当渠道出现问题时，该如何隔离。
路由规则的设定有一种比较简单的方法：渠道A在｛num｝分钟内触发了｛num｝次告警，那么就执行渠道隔离（关闭或者切换）的动作。
这样在通道出现问题时就可以及时隔离掉，保证用户正常的支付了。
结语
我们可以把支付渠道可用性看作一个大的系统，这个大系统是由3个独立的小系统组成的；它是一个自下而上的，闭环的体系；引用《失控》中的思想，一个复杂的系统是由若干个独立的小系统协同合作组成的，每个小系统越简单，它们组合在一起后，就能展现出更强大的组织性和发展性。
目前只是建立了一个最原始的生态，还存在着部分的人工干预，那么后期我们就要考虑，现在人做的事情，机器能不能做；我们能不能在用户提交支付之前就帮Ta选择好最适合的支付渠道。
文：tony
关键字：产品经理, 产品设计, 渠道
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
