如何拆解支付结构?这篇文章里,作者将支付结构拆解为5层,一起来看看,或许可以帮助你了解“支付核心”,打好支付体系、支付产品架构的一些知识基础。 整个支付结构由5层组成,终端属于业务层,不考虑在内,而支付是向各终端提供支付多样化的服务,帮助业务完成收付诉求。 我们从下往上看。 01最底层是支付渠道层。 没有任何一家企业或者机构可以不依赖外部的支付服务,就可以独自完成一个支付体系的建设,所以至少要接入一家支付服务商。 接谁,接什么产品,至少要考虑清楚这两个问题。 如果只是一家刚起步的Toc电商APP,那么接一个微信APP支付、支付宝APP支付就足够用了,因此也就是2个渠道,2款支付产品,2组支付接口。 但是,随着业务的不断扩大,支付场景越来越多,为了提升用户支付体验势必要接入更多的支付渠道和产品,满足用户多样化的支付诉求,比如消费分期。 那么,可以将支付渠道层抽象出支付渠道维度和支付产品维度,总结成一句话就是“接谁的什么产品”。 你不能指望支付核心去适应每一个渠道的不同,比如微信APP支付、支付宝APP支付、云闪付APP支付,渠道侧虽然是3套接口,但是对内完全可以抽象出APP支付一套接口,所以这是做了第一次统一。 支付网关还承载着支付安全、支付通讯、协议转化和处理等一系列的能力。 03网关之上就是支付核心。 支付核心是支付业务的核心处理层,也是基于渠道支付能力包装出内部支付业务的核心所在。 我们将支付核心分化出三大主要部分:支付核心、风控子系统、路由子系统,当然了,后2部分完全可以独立出去,将处理链接的服务留在支付核心内。 在支付核心内有2大部分。 第1部分是接入处理的核心流程,处理来自上游系统的支付请求,进行一系列的支付校验、参数补全、风控调用等,并将支付请求转换成最终的支付指令提交给网关完成最终的支付,以及结果回调通知业务方。 第2部分是支付核心的服务集群,包括支付处理、支付单处理、支付结果处理、外部服务调用模块、收银台服务、支付协议管理、支付营销、基础服务等综合支付服务的构建。 比如付款的核心单据。 这只是可视化的那一部分,或者说是操作台的部分。 支付核心的大部分能力和逻辑是不可视化的,是服务化的,比如支付单的创建,支付数据的补全,要补哪些数据,从哪里获得;支付参数的校验,校验哪些,检验不通过怎么处理等等。 04支付核心之上就是统一支付能力。 之所以将这部分从支付核心分化出来,是因为这一部分是对外的,是支付核心支付能力产品化提供给外部的体验。 明确了支付核心,能为你做什么。 比如,收款、付款、退款、代扣、分期、绑卡、合单支付等等。 05然后就是支付的接入层。 支付的接入层最被熟知的就是收银台,是用户可视化的部分,也是支付的最直接入口。 当然,还有一个接入模式就是支付API,直接将支付能力以API的形式提供给其他业务系统调用,比如资金调拨系统。 对于收银台来说,最主要的就是支付方式种类的抽象,每一个支付方式背后都有一组支付通道的支持,例如微信支付,背后可能有直联微信的通道、间联微信的通道,间联通道可能来自多家提供商。 而,从收银台的一个支付方式发起支付,到最终从多个支付通道挑选出一个完成支付,这中间其实就是“支付核心”的使命所在。 每一种支付方式都有一个相同流程和个性化流程,那么支付核心就是通过相同的支付主流程完成多种个性化支付子流程的融合,形成多个支付核心流程。 同样,其他收款流程类似,但微信APP、H5支付有稍微的区别;付款流程也是如此,每个通道大体相同,但有稍微的区别,这是支付核心每一个支付流程抽象的依据。 将每一类支付流程,分成“主流程”“子流程”“环节”三部分。 可以说,每一个支付场景,都有一个独立的支付流程,而支付系统就是总工程师,控制这些流程的全链条和链条是环节链。 整个大支付体系可以抽象成12个字。 买、收、付、退、充、提、转、调、算、结、管、对。 每一个字都代表了一个大的业务,依赖某一款产品去实现。 比如:
当然还有财票税,咱就先剔除在外,自成一家。 本来就想介绍一张图,写着写着就刹不住车了,本文只是对支付核心做了一个整体的概述,后面会有更多单独模块的剖析。 讲明白支付,非一日之功,也非一文能概括,细水长流,慢慢来。 一个点,一个点,地徐徐道来! 专栏作家 陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务! 本文原创发布于人人都是产品经理,未经许可,禁止转载 题图来自 Unsplash,基于 CC0 协议 该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。 |