支付行业中台搭建流程解析

一、行业分析

在搭建业务中台前，首先看一下是否有搭建中台的必要，分析一下支付行业整体的发展方向。

自从2004年支付宝作为第一家第三方支付公司出现至今，支付行业经历了从蓝海到红海的。以前支付牌照是香饽饽，监管不严格，利用牌照特性赚钱非常的容易。

现在央行也被支付公司一次次的套路中，学会如何进行监管，近年来巨额的罚单接连不断。监管意味着支付市场的空间被挤压，中小支付公司更是前有AT两大巨头，后有监管。面临以上种种情况，支付公司目前做的选择有一下几种：

1. 深耕支付领域、切入行业

根据艾瑞数据《2020Q2第三方支付行业数据发布报告》得知，支付行业依旧是支付宝财付通保持领先地位，但是在第二梯队的情况在垂直的行业蓬勃发展。

例如：平安旗下壹钱包深耕在零售、金融、商旅行业，份额逆势而上占到了1.5%。

中小支付公司可以依据自身多年的经营特点，深入商户的支付场景，根据行业特点与商户共同搭建合规的支付系统，共同建立稳固的护城河。

同时还可以深入到平台上下游的厂商、经销商、品牌商等各个环节，通过支付服务、账户服务、供应链服务，并联合物流服务平台、金融服务机构帮助企业疏通产业链的各个堵塞环节，帮助整个产业链实现效能提升，进而达到对交易量、交易效率的改善效果，成功促成交易。

2. 外包服务，转型输出支付平台

随着近年来产业互联网的推进，普通的产业会升级成数字化、在线化经营，这就伴随着支付也必须进行线上支付。

这就给第三方支付公司对外输出支付平台的机会，支付机构可以转型成为系统服务商，对外输出技术服务，可以收取相应的技术服务费用。例如可以为政府缴费平台、分银联支付平台搭建支付底层服务与完整支付的账户体系。

根据艾瑞数据查询的数据得知，目前第三方产业支付市场已经达到了百亿级别，中小支付企业可以乘势而上，加入产业支付升级的互联网大军中。

3. 市场下沉，聚焦聚合支付

在面对支付宝、微信两座大山面前，挑战是必输无疑的选。

那么唯有选择进行合作。在移动支付还没有盛行之前，各支付机构主流采用的都是快捷支付、网银等支付方式。部分商户系统对接能力较差的，无法对接多个支付机构。

但是系统的支付稳定性又没有保障，这时候就出现了四方支付机构。四方支付机构的特点就是一站式服务，解决商户对接困难问题，保证支付的成功率。对接四方的费率就会高一些。

以前只有没有牌照的支付企业才做聚合支付项目，称作是服务商，主要针对的是B端的商户。

但是中小的支付企业目前也是在抢占聚合支付的市场，依靠自身拥有支付牌照，可以建立支付账户体系，可以进行清算的特性，搭建一站式聚合支付服务，为商户提供一站式接入云闪付、支付宝、微信支付、银行APP等主流支付工具进行收款。

4. 出售牌照，金盆洗手

近期看到字节跳动、携程、京东、拼多多系列的牌照收购事件，在被央行监管、支付宝、微信多种挤压下，很多中小型的支付公司已经没有变现盈利的能力了，只能够寻找新的变现渠道，那就是出售牌照。

而同时呢，行业巨头有支付牌照的需求，不希望在自己的场景内，把支付业务的主动权拱手，但却无法再申请新的支付牌照，两者的需求交互，产生了一门新的生意——牌照收购。

所以许多拥有牌照的中小企业，可以依附于行业巨头的树荫下，或者直接出售牌照的所有权，直接金盆洗手，不干支付行业了。

5. 行业分析结果

从目前来看，聚合支付市场以及行业支付领域都是比较饱和的市场，处于一片红海，唯有外包服务服务，还是市场比较大 ，传统的企业需要数字化转型需要大量的外包业务服务。这就给支付公司的业务模式有很大的挑战性。

一般支付公司的后端的逻辑是比较稳定的，为了契合业务方的需求，不断的复制同一套代码，做定制化的业务改造，有些相同的业务也是在重复搭建，维护的时候相当的复杂。

在底层有变更时，需要同步变更多个服务，还需要评估变更对这些业务的影响有多少，可能有的影响多，有的不受影响，这就给中台提供了机会。

二、业务框架梳理

按照业务线的形式，梳理了两条的业务线的产品架构，具体内容如下：

1. 原业务逻辑说明

根据以上梳理的业务框架可以看出，两条业务线之间重合部分比较多。这就导致了两条业务线之间都分别重复搭建业务重合部分，这就造成了很多的资源的浪费。

除此之外并且会造成以下几个问题点：

1. 后端逻辑有改动时，两边业务得同时更改。这就造成后端上线有部分无法兼容所有业务的内容，前端必须反过来兼容后端的业务逻辑。
2. 后台的业务系统日渐趋于成熟，改动点比较难，如果有业务线有新需求接入时，需要兼容的内容太多，会导致迭代的速度非常慢。
3. 商户数据未打通，各业务线容易形成数据孤岛，无法联合进行营销、风控等。

2. 问题案例

以上图框架中以云闪付产品举个例子，分别对应以上的问题点：

1. 例如银联云闪付业务变更，此时后端的逻辑逻辑进行了变更，需要必传参数增多，此时需要同时聚合支付业务线和快捷业务线都得相应的进行改造。
2. 聚合支付业务线向后台业务提了一个需求，希望后端更新云闪付的红包功能，但是这个业务功能并不是快捷业务线所需要的，此时后台就需要兼容快捷线做兼容考虑，可能会导致迭代的效率较慢。
3. 由于聚合支付业务线刚起步，希望针对云闪付的商户做补贴。需要精准的找到补贴用户有些，这些用户在快捷业务线才有。此时聚合支付业务线只能依赖线下传输方式才能完成此时的补贴，用户数据不断变化的，每次做营销活动都得进行线下活动整合数据形式才能完成，并且数据并非是实时数据，还不能和自身业务进行相匹配。

以上的三个案例充分说明了，当有多条业务共用一个后台时，此时就会陷入多方同时维护同一个功能的地步，造成资源极大的损耗。同时会在公司内部不同业务线之间存在极大的信息孤岛，不利于公司的后续发展。

三、中台业务梳理

通过上面的数据分析完成后，说明还是很有必要构建业务中台，在构建之前需要考虑清楚什么业务的才能成中台业务，这些业务如何才能体现中台价值。搭建业务中台最终目的是为了节约成本，包括人力成本、资源成本、时间成本等。

即当公司需要发展多条业务线时，这几个业务有高度重合部分时，可以快速的进行迭代，并且所使用的资源是最少，简单来说就是做一个产品需要性价比高，或者ROI（投入产出比）高。

1. 功能在各业务线使用的频次

在计算业务线使用的频次之前，得先梳理系统的业务逻辑，需要具体到每个业务流程都使用了哪些功能。

以收银为例梳理整个过程所用到的功能：

• 登录商家账号使用的模块：商户管理（商家状态校验、商户信息查询）；
• 选择收款方式：商户管理（商户开通产品）；
• 扫码用户二维码：商户管理（商户信息查询、商户状态校验）、账务管理（账户状态）、路由管理（路由查询可用支付渠道）、订单管理（创建订单、优惠信息计算）、通道管理（往上游上传交易相关信息，获取用户支付信息）；
• 用户确认支付：无（PS:用户端输入支付密码，属于微信、支付宝、银联等客户端输入支付密码，与B端商家侧系统无关，此处是为了流程更加畅通，方便阅读）；
• 收款完成：商户管理（校验商户信息）、订单管理（更新订单状态）、账务管理（计算手续费、计算分润、生成账务流水）、账户管理（更新商户账户余额、更新手续费账户余额、更新代理商分润账户余额）。

整理上述的功能模块复用情况如下：

根据上图可以得知，聚合支付业务线商户管理、订单管理的复用次数最多，同时将其他行业线也一同梳理，最终将不同行业，相同功能模块的模块整理成一个表。

例如下图展示：

以上表可以得出商户管理、订单管理占据在整体比重较大，可以优先抽取至业务中台，剩余的模块需要根据公司业务进行评估处理。

2. 公司战略目标

在设计业务中台时，还需要和公司的整体战略目标相一致，中台的威力才能完全体现。

因为中台最大的作用就是复用能力，当公司业务重心在某一领域时，业务中台应该契合公司业务重心，才能发挥作用，不然又是陷入重复建设的陷阱。

公司想把所有的账户进行打通，让商户接入不同业务线时，资金可以在不同业务线之间共用，而每个业务都有账户管理模块，此时就可以将账户管理模块统一化，建立统一的账户体系。当一个商户对接多条业务线，资金不需要重复的进行提现充值动作，可以直接在不同业务线之间划转。

四、新业务框架

根据业务梳理的情况，构建了新的业务框架，具体如下：

将前台相同模块的业务进行抽取，简化前端的业务逻辑，将大量的运算放置在中台，同时前端业务不直接对接到后端。

后端有变动时，只需要中台进行修改兼容就可以，而不需要每个业务线都进行相应的整改，并且将业务数据进行打通，便于前端进行推广或冷启动时提供更多的商户数据。

五、总结

关于业务中台是否需要搭建，主要还是根据公司业务情况而定，总结一下几点：

1. 如果企业业务是横向拓展，并且相互之间没有太大的关联性，同时公司战略也不是同时多业务线并行开发的，这种搭建中台的必要性就不高。
2. 如果业务集中在某一个领取或者业务之间的功能重合度比较高，此时可以考虑先抽取重合部分抽取组成业务中台。
3. 搭建中台还需要关注行业动态，必须的捕捉行业的发展趋势，因为中台建立后，所有的前台的业务都对接中台，相关的业务承接方变成中台。得中台建立完成后，前台才能完成相关动作，所以中台尤为关键的就是捕捉行业的动态。不然跟不上发展趋势，前台业务可能会另起炉灶，自己重新建立业务系统。

本文由 @TOM 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。