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

推荐订阅源

T
Threatpost
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
T
The Blog of Author Tim Ferriss
S
SegmentFault 最新的问题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 司徒正美
T
Tailwind CSS Blog
The Cloudflare Blog
The Last Watchdog
The Last Watchdog
PCI Perspectives
PCI Perspectives
博客园 - 聂微东
Stack Overflow Blog
Stack Overflow Blog
TaoSecurity Blog
TaoSecurity Blog
云风的 BLOG
云风的 BLOG
C
Cybersecurity and Infrastructure Security Agency CISA
O
OpenAI News
Recorded Future
Recorded Future
GbyAI
GbyAI
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Y
Y Combinator Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
量子位
博客园 - 叶小钗
V
Vulnerabilities – Threatpost
F
Full Disclosure
Recent Announcements
Recent Announcements
Vercel News
Vercel News
S
Schneier on Security
H
Heimdal Security Blog
Cisco Talos Blog
Cisco Talos Blog
V2EX - 技术
V2EX - 技术
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
B
Blog RSS Feed
宝玉的分享
宝玉的分享
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
P
Privacy & Cybersecurity Law Blog
T
Threat Research - Cisco Blogs
G
Google Developers Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
爱范儿
爱范儿
IT之家
IT之家
大猫的无限游戏
大猫的无限游戏
C
Check Point Blog
N
Netflix TechBlog - Medium
S
Security @ Cisco Blogs
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Microsoft Azure Blog
Microsoft Azure Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Cyberwarzone
Cyberwarzone

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
银行侧支付系统,“接入网联”设计解析
陈天宇宙 · 2023-11-02 · via 人人都是产品经理

网联平台的建设,支付市场进入了崭新的时代,支付行业的发展提供了更加公平、公正、透明的市场环境,赢得喜爱。下面这篇文章是笔者自身想要重点介绍断直连以后的行内支付系统的相关内容,大家一起来看看吧!

断直连以后支付机构接入网联,与各银行信息通信,我们已经清楚了支付机构与网联之间的链接,那么银行侧是如何与网联链接呢?本文重点介绍断直连以后的行内支付系统。

一、网联平台建设的背景

网联平台全称为“非银行支付机构网络支付清算平台”,网联平台的建设背景是网络支付市场高速发展多年,形成了支付机构与银行间多头直连模式,随之带来了违规清算、资金挪用、标准不资源浪费等多重风险。

这种模式使得第三方支付机构可以绕过银联,单独一家第三方支付机构就能连接过百家银行,成为事实上的“网上银联”。这种状况下,不仅接口重复,而且开设多个备付金账户,关联关系复杂且透明度低,第三方支付机构相当于各自构建了支付清算体系,游离于现有清算系统之外。

为了解决上述问题,网联平台应运而生。它的建设自此拉开序幕,“断直连”和“备付金集中存管”两大任务也随之启动,支付市场正式进入了一个崭新的时代。作为最年轻的国家金融基础设施,网联平台致力于提供公共统一的转接清算服务,努力实现资金清算的集中化、透明化、规范化。

二、网联平台建设的目的

网联平台的建设目的不仅在于规范网络支付市场,提高交易透明度和安全性,更重要的是通过集中化、透明化和规范化的清算服务。加强了对客户备付金的监管,确保了客户资金的安全和合法使用。

此外,网联平台还旨在促进支付市场的创新和发展,通过公共统一的转接清算服务,降低了支付机构的运营成本,提高了支付效率。为支付行业的发展提供了更加公平、公正、透明的市场环境。

三、对接模式的转变

在“断直连”之前,支付机构和银行都是要一家家地去对接,形成了一个很大的关系网,存在对接流程复杂、技术规范不统一、客户备付金监管不透明等一系列风险。

而在“断直连”之后,支付机构与银行都是统一对接到网联平台,由网联平台负责交易流程串接以及资金清算,既统一了对接标准和技术标准,又使得客户备付金接受央行的监管,保障了客户资金的安全以及合法使用。

四、网联平台提供的主要功能

1. 快捷支付

快捷支付是指用户在支付机构APP或网页上绑定银行卡后,后续可以直接使用已绑定银行卡直接支付的一种交易类型,无需在每次支付时都录入银行卡卡号。

例如在淘宝上购物后使用支付宝进行支付,以及其他的生活服务消费等应用场景。

1)快捷支付签约流程

2)快捷支付流程

2. 付款业务

付款业务是指用户在支付机构APP或网站发起的钱包余额提现到银行卡、商户资金结算(包括预付卡商户结算)、信用卡还款等入账类的场景。

3. 代收

代收业务是指经付款人同意,收款人委托代收机构按照约定的频率、额度等条件,从付款人开户机构扣划付款人账户资金给收款人,且付款人开户机构不再与付款人逐笔进行交易确认的支付业务。

例如,在微信APP的生活缴费页面,签订的定期从银行卡代扣电费的业务。

1)代收业务签约流程

2)代收业务流程

4. 网关支付

网关支付是指用户在线上消费场景下,从支付机构跳转至银行网关页面完成支付的一类业务。比如使用支付宝网页版支付时,在收银台界面,选择某个银行后跳转至银行H5网关页面,再选择对应银行卡进行支付的场景。

5. 退款

退款交易是对已发生的快捷支付、代收、网关支付等交易进行反向处理,将用户资金退回原有的银行账户。

例如用户在淘宝上选定商品并使用支付宝支付后,觉得商品不合适,这时发起了退款请求将资金退回原有的银行账户。

五、银行侧支付系统

1. 总体架构

网联银行侧系统常见的架构设计思路可按照四个层次进行划分,分别是应用服务层、公共服务层、通讯前置层、基础服务层。

  • 应用服务层:以网联平台所支持的交易类型为基础来设计对应的服务,服务与服务之间相互独立,可根据业务诉求、交易流程、性能等方面的需要独立扩展,以满足灵活多变的业务需求;
  • 公共服务层:提供了应用服务层所需依赖的业务服务组件,可减少应用服务层重复造轮子;以协议管理服务为例,主要是对快捷支付协议以及代收协议进行管理,支持协议签订、协议解约、协议查询等子功能,并支持从行内的其他系统或网联平台发起的协议变更处理;同样的,交易限额一般有单笔限额、日累计限额、月累计限额等维度,可提供交易限额扣减、回滚、查询等子功能。而风控、反洗钱检查服务,一般行内都有风控中心或反洗钱中心提供相关服务,按照其提供的服务规范及业务部门规则进行校验即可;
  • 通讯前置层:直接对应网联平台,提供了报文签名验签、敏感字段加解密、报文拆拼、格式转换、通讯组件等服务,这类服务变化较少,独立运行可保持系统的稳定性;如签名验签、加解密模块,网联平台有相应的安全信息规范,加密算法支持国密及国际算法,一般是采用硬件加解密,国内的产商有提供整套的解决方案,根据其API封装对应的服务即可;而像报文拆拼服务,由于网联平台的规范是XML报文,且每个交易类型都有不同的报文字段,可抽象出XML报文的拆拼包服务,专门处理处理报文的拼接和拆解;
  • 基础服务层:提供了数据库、消息中间件、缓存组件、配置管理、任务调度等服务,实际按各家银行的技术架构进行设计。

2. 快捷支付

快捷支付交易涉及的角色包含用户、支付机构、网联平台、银行,用户在支付机构发起交易请求后,经网联平台发送至用户银行卡所在银行(简称发卡行),发卡行经校验、账户扣款后返回交易结果。

在银行支付系统的交易流程中,有几个流程节点需要特别注意。

  • 交易信息登记,可以理解为将交易订单信息存储至数据库,其关键交易要素包含交易日期、交易时间、支付机构编号、支付系统流水号、快捷支付协议号(标识着某张银行卡绑定了某个支付机构,用一串唯一的ID表示)、账户类型(如借记卡、贷记卡、公司结算账户)、网联平台流水号(标识唯一一笔交易,由网联平台生成)、网联平台场次号(标识着某个小时内的交易,由网联平台生成,是一串字母+日期+数字的组合)、付款方账户编号、付款方账户名称、收款方账户编号、收款方账户名称、交易金额、业务种类等,交易订单信息登记后,后续可提供相应报表给业务人员查询;
  • 快捷支付协议检查,该流程主要是校验快捷支付报文中的协议号(标识着某张银行卡绑定了某个支付机构,用一串唯一的ID表示,由银行支付系统生成)在银行支付系统是否存在记录,存在记录的话是否协议状态是正常的,如果都不符合则拒绝交易请求,校验通过后则可获取协议信息中的签约人银行账户、名称等信息,用于后续环节从指定账户扣款;
  • 交易限额扣减,如果是客户有在银行系统设置了银行卡所在支付机构的单笔限额、日累计限额、月累计限额,则会在扣款前进行交易限额扣减,以降低因盗刷等原因造成的资金损失风险,如交易最终失败,需将交易限额进行回滚处理,否则会导致交易限额虚减;

最后,流程的第七、八步不同银行有不同的校验规则、控制策略,这里只列出通用的处理流程。每年的京东618、淘宝天猫双11、双12都有快捷支付交易的保障要求,交易性能要求非常高,交易设计时需尽可能减少与外系统的交互环节,同时做好技术优化,才能使交易有足够高的性能来顶住电商大促活动带来的流量冲击。

3. 付款业务

付款业务交易是用户从支付机构端发起,经网联平台发送至用户用户银行卡所在银行(简称发卡行)进行入账处理。

在银行支付系统中,需要注意的流程节点有以下几个。

  • 交易信息登记,与快捷支付一样,只是相比于快捷支付的信息登记,付款业务的信息登记不需要“快捷支付协议号”
  • 账户信息校验,银行账户一般分借记卡(储蓄卡)、信用卡、对公结算账户,借记卡又分为Ⅰ类户、Ⅱ类户、Ⅲ类户,不同的账户类型有不同校验规则,像借记卡一般是校验卡状态、账户属性即可,而信用卡除了校验卡状态,还要校验CVV2、有效期、账户支持的币种等信息;
  • 银行账户入账,如账户类型是借记卡的话,入账处理就比较简单,直接调用银行核心系统服务即可;如果账户类型是信用卡,还需考虑账户币种问题,假设账户是美元账户,需按照当天的汇率、手续费进行购汇处理(指当用户需要支付外币时,用人民币去购买外币的行为)。

4. 网关支付

网关支付交易需要注意的流程节点有以下几点

  • 跳转至银行网关页面,该网关页面地址是由银行提供,网联平台提前配置,支付机构发起网关支付请求时,网联平台再返回该地址给支付机构;
  • 提交支付,用户在银行网关页面发起支付时会有类似在银行个人/对公网银系统的相关校验,比如交易密码验证、KEY盾、U盾、动态口令、数字证书、指纹识别、人脸识别等校验方式。

目前网关支付,主要是面向企业用户,因为企业用户涉及商品交易金额较大,所有更注重交易安全性。而个人用户已经很少使用了,因为其操作流程较为复杂,所以更多的是使用快捷支付。

5. 退款

退款交易需要注意的流程节点有以下几点

  • 交易信息登记,可以理解为将交易订单信息存储至数据库,其关键交易要素包含交易日期、交易时间、支付机构编号、支付系统流水号、账户类型、网联平台场次号、网联平台流水号、网联平台流水号、付款方账户编号、付款方账户名称、收款方账户编号、收款方账户名称、交易金额、原交易金额、业务种类等,交易订单信息登记后,后续可提供相应报表给业务人员查询;
  • 加载原交易信息,这里指的是通过退款报文中的原网联流水号加载原支付交易信息,来获取待退款账户的相关信息,以便后面进行退款入账处理;
  • 核实退款请求,会存在某个用户多次退款的场景,例如在淘宝买了多样商品后一次性支付,后续发现有几个商品不合适发起了退款请求,这时支付宝会逐笔发起退款报文,但报文中的原网联流水号是一样的;所以遇到此类场景,需保证多次退款的合计金额不能超过原支付交易金额,防止恶意退款造成的银行短款。

6. 对账

在完成支付交易后,必须进行对账处理,做好对账模块的设计可防止误差和欺诈行为、确保账务的准确性、满足外部法规和监管的规定的要求。

在银行支付系统对账模块的设计中,一般会涉及多个对账主体,以网联平台为例,这些对账主体包含银行支付系统、银行核心系统、网联平台,需要对这三方的交易数据进行对账才能及时发现账务问题。

对账的方式包含汇总对账以及明细对账,对账要素又包含交易类型、金额、状态、笔数等等,对账数据来源主要是文件,网联平台每小时提供的对账文件,银行核心系统每天提供的记账明细文件。

一般对账模块的设计思路是,银行支付系统先与网联平台进行对账,包含汇总对账及明细对账,以网联平台的对账文件数据为准与银行支付系统的交易数据进行比对,双方交易状态、金额完全一致的交易数据记为对平,不一致则记为不平,对账不平数据需登记至对账不平报表。

接着将支付系统的交易数据与银行核心系统的交易数据进行比对,以记账状态、金额完全相同为标准,标识出对账不平的数据登记至对账不平报表。

最后,银行内部人员可在对账不平报表查询记录,核对对账不平原因,确认不平后可发起差错调账处理。

1)汇总对账结果示例

2)明细对账结果示例

六、总结归纳

网联银行侧支付系统的设计,一般是以网联平台所支持的功能为基础,结合银行自身支付体系、技术架构、以及关联系统提供的服务,设计出扩展性强、容错性高、性能优越的支付系统。

网联的交易都有各自的特点。

像快捷支付、付款业务有性能要求,设计上需注意交易流程的简洁性、性能调优。

像网关支付交互流程较多,需注重异常设计,即使流程节点的中断也需要能需跑流程。

最后加上对账差错作为兜底手段,以确保资金的安全性。

专栏作家

陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!

本文原创发布于人人都是产品经理,未经许可,禁止转载。

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。