支付-支付整体架构
支付架构
-
支付渠道层
没有任何一家企业或者机构可以不依赖外部的支付服务,就可以独自完成一个支付体系的建设,所以至少要接入一家支付服务商。但是,随着业务的不断扩大,支付场景越来越多,可以将支付渠道层抽象出支付渠道维度和支付产品维度,总结成一句话就是“接谁的什么产品”。虽然渠道不同,支付产品不同,但是支付能力大致相同,因此,将支付产品的共性抽象出来,可以更好地管理支付渠道层。可以按照终端类型抽象,比如抽象出App支付、小程序支付、网站支付等。这样做的目的,就是看清楚渠道的画像,让渠道和产品选择更加合理和高效,避免过多的重复接入同等能力的支付产品。 -
支付网关层
网关是支付核心与外部渠道通讯的关卡,也是外部多样化支付产品和接口向内部第一次统一的一层。
- 支付通讯
- 协议转化
- 错误码统一
- 加密解密签名证书
-
支付核心
支付核心是支付业务的核心处理层,也是基于渠道支付能力包装出内部支付业务的核心所在。在支付核心内有2大部分:
3.1 接入处理的核心流程,处理来自上游系统的支付请求,进行一系列的支付校验、参数补全、风控调用等,并将支付请求转换成最终的支付指令提交给网关完成最终的支付,以及结果回调通知业务方。
3.2 支付核心的服务集群,包括支付处理、支付单处理、支付结果处理、外部服务调用模块、收银台服务、支付协议管理、支付营销、基础服务等综合支付服务的构建。 -
统一支付能力
之所以将这部分从支付核心分化出来,是因为这一部分是对外的,是支付核心支付能力产品化提供给外部的体验。明确了支付核心,能为你做什么,比如,收款、付款、退款、代扣、分期、绑卡、合单支付等等。 -
统一支付接入层
支付的接入层最被熟知的就是收银台,是用户可视化的部分,也是支付的最直接入口,当然,还有一个接入模式就是支付API,直接将支付能力以API的形式提供给其他业务系统调用。
对于收银台来说,最主要的就是支付方式种类的抽象,每一个支付方式背后都有一组支付通道的支持,例如微信支付,背后可能有直联微信的通道、间联微信的通道,间联通道可能来自多家提供商。从收银台的一个支付方式发起支付,到最终从多个支付通道挑选出一个完成支付,这中间其实就是“支付核心”的使命所在。
整个大支付体系可以抽象成12个字:买、收、付、退、充、提、转、调、算、结、管、对
- 买:交易体系的能力,支付的业务起源
- 收付退:支付核心的主要支付能力
- 充提转:钱包的支付能力
- 调:资金管理系统的支付能力
- 算结管:是清结算的处理能力
- 对:就是对账,确保数据的一致性
支付系统核心流程
各业务终端通过收银台或者开放API接入支付核心,发起支付业务请求,通过支付核心完成自己的支付业务,支付核心主要由支付处理核心、支付风控、支付路由、支付网关等4个核心部分组成。
我们把支付核心主流程抽象出11个环节,可以根据实际的业务需要,对该图的环节进行增加或者删减,但大同小异。这11个环节可以再次划分成客户端支付请求处理、支付核心请求报文处理、请求渠道发起支付、支付应答处理等4个阶段。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性