交易和支付,有啥区别?
可能不少人会有疑惑:交易系统和支付系统,二者之间存在哪些差别?有时甚至会觉得支付系统可以完成交易系统的职能,那后者存在的意义又是什么?如果想了解这个问题,可能我们需要从企业分工等角度进行考虑。先一起来看看作者的分析。
昨天微信群里有一位朋友问了一个问题,我觉得特别有代表性,也是很多初中级甚至是高级产品经常会遇到的疑惑:
“感觉交易系统的事,其实支付系统也能做。”
但,我不想直接去回答,因为说了这次的答案,还会遇到更多同类问题,如“交易系统跟订单系统有什么区别,清分系统、清算系统、计费系统三者有什么区别,账务系统、账户系统、会计系统三者有什么区别”…
因此,问题的关键不是问题本身,而是他没有“分析方法”,如果有分析方法,任何问题都可以自洽,就算没有最终的所谓的标准答案,标准答案不重要也没有,关键是在我们自己的认知体系里要自洽,可解释。
我尝试着将我的思考过程展示给他,让他从中收获一项“可复用的分析模型”。
那么交易系统和支付系统究竟有什么区别呢?
我们先思考一个问题:问题中提到支付系统也能做,其实它什么都能做,但为什么它不做呢?
这要从系统发展史说起,在企业发展过程中形成的“职能细化,子系统的独立拆分”现象,就像盘古开天辟地一样,从混沌到复杂的生态。
一、一个系统打天下
当公司刚成立很小的时候,做在线交易只需要一个“交易系统”就可以了,因为业务体量小,公司没钱,没人,所以没必要搞那么复杂的产品体系。
而就算是一个“交易系统”,其中也完整地包含“收银台、订单、卡券、计费结算、支付处理、渠道管理、财务”。
所以,虽然是一个系统,但是他承载的职能是清晰、明确的;无论有多少系统,系统规模大小,一个企业的主体业务大体都是一样的,用户要选购、要下单、要支付、商家要结算。
因此,在认识系统之前,先明白企业的各种职能,什么是交易、什么是订单、什么是支付……因为解决这些职能不只是系统可以实现,线下面对面也可以实现,比如支付,线下给现金就可以,写个收据就可以,把“事搞明白”。
二、旧系统解体,新体系形成
随着公司的发展,业务体量的增加,原来的交易系统越来越笨重,调整越来越难,逐渐成为平台的瓶颈。
而这个时候公司也有钱了,开始重新细化和打包职能,重新定义和规划旧交易系统中的“收银台服务”“订单服务”“清结算服务”“支付处理服务”“卡券营销服务”“渠道管理”,为了更精准高效的管理这些服务,开始逐渐独立出新的单独的系统,交付给单独的团队和产品经理去负责。
因此,子系统“收银台”“订单系统”“清结算系统”“卡券系统”“支付处理系统”“渠道管理系统”出现……
这样将每个独立出来的系统分派给不同的产品部门和产品团队,这时候产品经理队伍可能逐渐扩招到了20人甚至是200人,2000人,其中这些独立出来的众多系统之间的协同成了非常重要的问题,因为一次交易大家都要参与,而这种协同关系和处理流程就是“交易”。
也就是最原始的那个系统“交易系统”,虽然大家都独立出去了,但是留下来的那些职能逐渐成为了交易系统的核心职能,比如,订单系统独立出去了,但是“创建订单服务”留在了交易系统里;卡券系统独立出去了,但是核销优惠券服务留在了交易系统……
这个过程随着企业发展而不断的重复。
企业更大了,业务体量是期初的上百万倍,更多的职能开始产生,更多的子系统开始独立处理,更多的人开始被招募进来;
- 收银台被分化出前台、后台、H5收银台、App收银台、收银台中台、收银台策略平台……
- 清结算系统开始分化出计费系统、清分系统、规则子系统、结算系统、账户系统……
- 支付系统开始分化出收款系统、付款系统、调拨系统、支付风控系统、支付策略系统……
- 渠道管理开始分化出路由系统……
周而复始,无穷尽也。
所以,不能静态的去理解“谁能做什么,谁做什么,做成什么样”,而是要从历史发展和演变的角度、分工的角度、选择的角度去理解当前的职能是什么,系统是什么,这都是在企业发展过程中,基于企业的特色和个性化选择下,所形成的系统体系。
先理解职能,企业要干什么;再去理解谁来干,怎么干,为什么这么干。
最后我们再去回答最初的那个问题,交易系统和支付系统的区别,但我的回答不代表所有企业都是这么定义。
从用户进到平台开始选购,到最后支付成功,做的所有事情都是交易,而交易就是统筹管理这个过程,所以这个过程里的所有业务都可以划给交易系统,也都可以从交易系统中独立出去,而支付系统就是从中独立出来的一部分。
因此,支付系统只是大交易中的一个环节,主要是处理外部支付渠道支付,也就是用户“实付”那一部分资金的处理系统,比如用微信支付、支付宝支付、银行卡支付的那一部分资金。
但是,一笔交易,可以用卡、用券、用积分……这部分就不会由支付系统处理,而是由卡、券、积分系统承接,而与他们的链接就交给了“交易系统”,这种链接职能,就是卡券积分从交易系统独立出来以后留在交易系统的那一部分职能……可以参考上面的演变图。
专栏作家
陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
支付是交易的一个子流程
作者大大,我好崇拜你,我是你的粉丝!看你的文章让我受益匪浅,每看一遍都会有新的收获
那这样看交易系统是不是基本不会有存储设计呀?
有交易记录,你可以理解为交易账单;具体可以看我的交易系统那篇文章,最好看公众号中的,更新一点
应该会有自己的一套存根。。。且这个存根其实是一种特化过的订单类型。
即:只限定于这个交易系统内部的订单类型,这暗示着还会有其它的交易系统的内部将会关注不同的订单类型,
但这些订单类型的共性是:
都只不过是对“订单服务”中的公共订单能力的一层薄薄的封装,封装成自己的订单类型。
学习到了,新的思路