惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
G
Google Developers Blog
WordPress大学
WordPress大学
M
MIT News - Artificial intelligence
D
DataBreaches.Net
云风的 BLOG
云风的 BLOG
爱范儿
爱范儿
Microsoft Security Blog
Microsoft Security Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Blog — PlanetScale
Blog — PlanetScale
T
Tailwind CSS Blog
S
SegmentFault 最新的问题
阮一峰的网络日志
阮一峰的网络日志
博客园 - 三生石上(FineUI控件)
酷 壳 – CoolShell
酷 壳 – CoolShell
Recent Announcements
Recent Announcements
T
The Blog of Author Tim Ferriss
I
InfoQ
MyScale Blog
MyScale Blog
V
V2EX
B
Blog
罗磊的独立博客
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
三张图讲清楚支付系统收银台后端服务最核心设计
隐墨星辰 · 2025-02-12 · via 人人都是产品经理

收银核心和支付引擎是支付系统最核心的两个子系统之一。本篇主要讲清楚收银核心的设计与实现,包括收银核心如何渲染可用支付方式,如何做可支付检查,收银台核心的系统架构、领域模型,常见支付方式等。

今天聊下收银台后端服务设计。

收银台并不只是我们在电商购物时看到的那一个简单的页面,背后有很复杂的业务逻辑,比如:如何计算出哪些支付方式可以使用?哪些支付方式放前面?如何推进支付?如何在最短的时间内拿到最多可用的支付方式?

一、收银台与收银核心

收银台是一个很宽的概念,且每个公司的定义都不一样。比如有标准收银台、前置收银台、SDK收银台、APP收银台、PC收银台、H5收银台等,不一而足。

这些说的都是对客展示形式,顾名思义,标准收银台就是收支付平台提供的收银台终端,比如微信支付和支付宝提供的收银台,而前置收银台是电商自己封装收银台,支付平台只提供数据服务。

在更底层,就是收银台核心,负责收银台后端服务的实现。每个公司都提供多种收银台对客展示形式,但是都只有一个收银台核心。

二、收银核心与支付引擎

很多公司把收银核心和支付引擎合二为一,统称为收银支付,也有一些公司是把这两块分开设计。

我个人更倾向于分开。

  • 收银核心:负责支付前的所有工作,比如基础权限校验、可支付检查、支付方式渲染、调用风控、支付结果轮询等。
  • 支付引擎:直接执行支付扣款,比如扣余额、扣营销券、扣外部渠道。

先给一个直观的协同作战的图,有一个整体的印象。

三、收银核心在支付系统中的位置

收银核心是支付系统的门面,负责处理用户的支付请求,核心能力就两个:1)支付方式咨询,告诉用户本次可以使用哪些支付方式。2)提交支付后的各种校验,比如订单是否有效,商户权限,用户身份,风控等。

四、支付咨询

上面的图分别是电商(京东)的收银台,支付平台(微信支付)的收银台。

支付咨询阶段,需要做以下几个工作:

  • 基础检查:可支付检查(有可能订单已经已经被支付),用户检查,商户检查等。
  • 资产咨询:绑卡数据,账户余额,营销(比如满减、红包等)。
  • 渠道咨询:通过币种、金额、渠道开关等。
  • 额度咨询:单笔限额、日累计限额、月累计限额等。
  • 支付方式组装:把上面的资产、渠道等组装成用户方便理解的支付方式。
  • 支付方式排序:把用户可用支付方式做好推荐排序(既要考虑用户体验,又要考虑营销策略)。

最后把支付方式返回给用户,供用户在支付时选择。

五、支付受理

用户选择支付方式后,点击“确认支付”,就到了支付受理阶段。主要做以下几个工作:

在支付咨询阶段的工作全部做一遍。因为用户在支付方式渲染后有可能过了很久才支付,很多数据在后台可能已经发生变化,比如余额变了,或者订单已经过期了等情况。

全部通过后,调用风控进行风险判断。

如果是外部渠道的卡支付,还需要调用渠道路由,选择出一条最优的渠道。

然后是提交支付请求到支付引擎进行真实扣款。

最后是从收单平台轮询交易结果。

特别说明一下:为什么轮询结果是以收单平台为准而不是以支付引擎为准?因为对用户而言,收单的结果代表最终的支付结果。比如用户支付回来后,支付引擎是成功的,但是收单平台因为已经订单过期关闭,就会发起资金退回操作,这样收单平台的订单实际是没有支付成功的。就会类似这样提示用户:“订单已关闭,如果已经扣款,支付款项预计在15个工作日内原路退回。”

六、收银核心系统架构

提供给用户有多种支付方式:卡、余额、网银等。收单产品主要包括:标准收银台,前置收银台,扫码付等。其中标准收银是由支付平台提供,需要跳转到支付平台,而前置收银台是直接嵌入到商户收银台里面完成支付。核心服务包括:支付咨询、支付受理、风控挑战并支付等。外部依赖主要有:会员、商服、卡中心、风控、渠道网关、支付引擎等。

七、收银核心领域模型

有人好奇:为什么收银台连数据库都没有,却也设计模型?不设计行不行?之所以设计设计模型,就是为了更好地理解和体现业务的本质。不设计也是可以的,简单实用,但对于一些复杂的场景或新增的能力,就容易修改出问题。模型最大的好处是把各种要素分门别类好,减少杂乱,能快速评估出需要修改模型的哪个点。

八、常见支付方式

快捷支付

通过在支付系统中提前绑定银行卡信息,快速完成支付交易,不需要每次都填写完整的卡详情。

代扣/协议支付

个人授权商户直接去支付平台或银行进行扣款,不需要用户参与支付过程。比如水电煤代扣,滴滴打车代扣。

卡支付

使用信用卡或借记卡支付。

网银支付

需要跳转到银行提供的支付页面,输入银行账户信息进行支付。

VA支付

Virtual Account。虚拟账户是银行临时生成的一个账户,与用户和订单临时关联。一般在东南亚的支付场景,或者国际收款场景下使用得比较多。东南亚很多人没有银行卡,但又要在线买东西,就可以临时生成一个VA。以支付流程为例:用户选择某个银行的VA支付方式,支付系统调用银行接口,先为用户订单生成一个VA号,用户拿着VA去钱下ATM机转账,银行收到钱后,通知支付系统,支付系统再通知商户,商户给用户发货。

OTC支付

Over-the-Counter。柜台支付。一般指大型连锁线下零售商提供的支付能力,比如7-11或肯德基提供的支付能力。整体流程和VA很像。区别在于VA通常指银行提供的。同样以支付流程为例:用户选择某个OTC服务提供商的OTC支付方式,比如7-11,支付系统调用7-11接口,先为用户订单生成一个OTC码,用户拿着OTC码去钱下7-11柜台拿现金充值,7-11收到钱后,通知支付系统,支付系统再通知商户,商户给用户发货。

第三方钱包支付

非银行机构提供的在线支付服务。比如支付宝、微信支付,国外的PayPal等。

余额支付

使用账户余额进行支付。

正扫

商户生成二维码,用户扫商户二维码。

反扫

消费者生成二维码,商户扫消费者的二维码。

九、结束语

每个公司对于收银核心的设计可能各有不同,但无外乎就是如何为用户计算出可用的支付方式,提交支付后做各种检查,然后调用支付引擎去做真正的支付。这里只讲了收银核心,也就是所谓的后端服务。前端或APP端的渲染也是一门大学问。内容已收录“图解支付系统设计与实现”。

本文由人人都是产品经理作者【隐墨星辰】,微信公众号:【隐墨星辰】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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