后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载导读本文基于 System Design 101 仓库的支付主题文档完整拆解扫一扫就完成支付背后的两个子流程——商家端生成二维码的 7 个步骤与消费者端扫码付款的 5 个步骤。读完本文你将理解 PSP支付服务提供商、Payment Gateway支付网关、动态二维码、防重复支付与清结算在一条扫码交易链路中的真实分工可用于面试讲解与支付系统设计实践。扫码支付已经是我们习以为常的支付方式无论是 Paypal、Paytm、Venmo 等数字钱包还是微信、支付宝都在收银台前上演着几乎相同的扫一扫。很多人以为这只是把二维码对准摄像头这么简单但在一秒钟之内背后其实串联着收银系统、商户电脑、PSP、支付网关和数据库之间的一连串消息传递。要理解整条链路最有效的方式是把 scan to pay扫码支付拆成两个相对独立的子流程子流程一商家生成二维码并展示在屏幕上子流程二消费者扫描二维码并完成付款。两个子流程共同构成一次完整的扫码交易缺一不可。子流程一商家端生成二维码7 步第一个子流程的职责是把一笔待支付订单转化为一张可被消费者钱包扫描的二维码。整个过程从收银台开始到收银台结束全部发生在商家侧消费者此时还无需介入。Step 1收银台生成订单假设你在超市购物收银员把所有商品录入系统并计算出应付总额例如$123.45。此时收银系统checkout会生成一个唯一的订单号例如SN129803。收银员点击 checkout结账按钮收银系统便持有了这笔订单的订单 ID 应付金额。Step 2收银电脑把订单信息发送给 PSP收银员点击结账后收银员电脑cashiers computer将这笔订单的订单 IDSN129803与金额$123.45发送给 PSPPayment Service Provider支付服务提供商。这里的 PSP 承担的是收单 处理的角色例如 Stripe、Paypal、Paytm 等服务商都具备类似能力。Step 3PSP 落库并生成二维码 URLPSP 收到订单信息后先将订单 ID、金额等数据持久化保存到数据库中随后为这笔订单生成一个二维码 URLQR code URL。这个 URL 是整个扫码支付的关键载体——它通过 URL 的形式把订单信息至少包括订单号与金额编码进二维码内容中后续消费者的钱包正是通过解析这个 URL 来定位这笔待支付订单。Step 4PSP 的支付网关读取二维码 URLPSP 内部的Payment Gateway支付网关服务读取刚才生成的二维码 URL。支付网关是 PSP 面向外部暴露的入口服务负责校验、路由和转发支付相关请求因此二维码 URL 的生成与分发由它统一接管。Step 5支付网关把二维码 URL 返回给商户电脑支付网关将二维码 URL或直接返回二维码图片本身返回给商户的电脑。这一步是信息从 PSP 侧回流到商户侧的转折点。Step 6商户电脑把二维码 URL/图片下发到收银台商户电脑收到二维码 URL 或图片后将其发送到具体的收银台checkout counter。在实际门店中这一步通常经由商户局域网或云端收银服务完成。Step 7收银台展示二维码收银台显示器或扫码盒展示出这张二维码等待消费者扫描。7 步全部完成耗时不到 1 秒。也就是说从点击 checkout 到二维码亮屏消费者几乎无感知这正是扫码即付体验的起点。子流程二消费者端扫码支付5 步二维码亮屏后轮到消费者从自己的数字钱包中完成付款。这个子流程同样只有 5 步但涉及身份校验、金额确认与已支付状态的落库。Step 1消费者打开数字钱包 App 扫码消费者打开自己的数字钱包Paypal、Venmo、Paytm 等对准商家屏幕上的二维码进行扫描。钱包 App 解析二维码内容即 Step 3 生成的二维码 URL识别出订单 ID 与金额。Step 2确认金额后点击 pay 按钮钱包 App 向消费者展示这笔订单的金额$123.45供核对消费者确认无误后点击 pay支付按钮。这一步是用户的显式授权也是后续扣款操作的合法依据。Step 3钱包 App 通知 PSP消费者已为指定二维码付款消费者点击支付后钱包 App 调用 PSP 的接口通知 PSP消费者已针对某个二维码对应订单 SN129803发起了付款。此时 PSP 侧才第一次把消费者与这笔订单关联起来。Step 4PSP 支付网关将二维码标记为已支付并返回成功PSP 的支付网关校验付款请求成功后在数据库中把这张二维码对应订单标记为 paid已支付并向消费者的钱包 App 返回成功消息。这一步是整个链路中最关键的状态转换二维码/订单状态从 pending 变为 paid从机制上杜绝了同一张二维码被再次重复支付。Step 5PSP 通知商户消费者已付款最后PSP 的支付网关向商户系统发出通知告知消费者已为订单 SN129803 支付 $123.45。商户收银系统据此确认收款成功、放行商品或更新订单状态一次扫码支付至此闭环。这次扫码属于四种 QR 支付模式中的哪一种仓库配套文档 4 Ways of QR Code Payment 指出所有 QR 码支付都可以从两个维度组合出2×2 4 种模式谁出示二维码消费者出示、商户扫描consumer-presented / 被扫模式 vs 商户出示、消费者扫描merchant-presented / 主扫模式二维码是否动态静态二维码static vs 动态二维码dynamic。本文拆解的场景——商户收银台实时生成、消费者用钱包扫描——正是merchant-presented商户出示 dynamic动态二维码的组合动态二维码在每次交易时实时生成因此可以承载丰富信息例如应付金额、交易类型、订单号等本例中的 $123.45 与 SN129803 正是被编码进二维码 URL 的信息静态二维码只生成一次、随处复用通常仅包含账户信息无法携带单笔金额也就无法直接支持本例这种按订单金额出码的模式。理解了这四种模式你就知道为什么超市、餐厅的扫码支付绝大多数采用商户出示 动态码——因为金额随订单变化且动态码天然具备更强的防篡改与防重复使用能力。链路背后的核心组件把两个子流程放在一起看整条链路围绕几个关键组件运转这些组件在仓库的支付主题文档中均有印证组件在本流程中的职责收银系统Checkout生成订单 ID 与金额展示二维码子流程一 Step 1、6、7PSP支付服务提供商落库订单信息、生成二维码 URL、维护支付状态Step 2、3、4子流程二 Step 3、4、5Payment Gateway支付网关PSP 的入口服务读取/分发二维码 URL接收付款通知并返回结果数字钱包 App解析二维码、确认金额、发起付款、接收成功结果支付数据库持久化订单、二维码 URL 与已支付状态其中 PSP 与支付网关的关系可对照仓库文档 The Payments Ecosystem 理解在完整的支付生态中商户侧要经过收单银行acquiring bank、卡组织card network、发卡银行issuing bank等多方协作而 PSP 往往将收单与网关能力聚合后向商户提供统一接口——扫码支付正是 PSP 通过支付网关对外暴露的典型收单能力。更宏观地看Payment System 一文展示了点击 Buy 按钮后资金在支付服务、支付执行器、钱包、账本ledger之间的流转支付事件入库、按支付订单执行、调用外部 PSP 完成扣款、更新钱包余额、追加账本记录、日终由 PSP 或银行下发结算文件。扫码支付本质上是这套通用支付流水线在二维码 钱包场景下的具体实例。可靠性设计防重复支付与幂等子流程二 Step 4 中PSP 支付网关把二维码标记为已支付这一动作是扫码支付防重复的核心机制。仓库文档 How to Avoid Double Payment 明确指出支付系统最严重的问题之一就是向客户重复扣款double charge因此在设计时必须保证一笔支付订单被恰好执行一次exactly-once而 exactly-once 可以拆解为至少一次at least once靠重试 至多一次at most once靠幂等校验。对应到扫码支付场景重试Retry消费者点击 pay 后若网络抖动导致请求超时钱包 App 会重发请求保证付款指令至少送达一次幂等Idempotency每次支付请求携带唯一幂等键实践中常用 UUIDStripe、PayPal 等均推荐该做法通过 HTTP 头idempotency-key: key_value传递。PSP 侧对同一个订单/二维码只接受一次有效付款二维码一旦被标记为 paid后续针对它的重复请求将被拒绝或直接返回相同结果从而把重复点击、重试、网络重放都挡在重复扣款之外。二维码状态机pending → paid与幂等键结合正是这条扫码链路在支付可靠性上的两道保险。支付完成后的资金流转信息流与资金流分离需要特别说明的是消费者在钱包里看到扣款成功并不等于真实资金立刻划转到了商户账户。仓库文档 Money Movement 揭示了一个重要事实——信息流information flow与资金流fund flow是分离的交易层与支付清算层属于信息流在这里钱看起来从一个账户扣除、加到另一个账户结算层属于资金流真实的资金移动发生在结算银行settlement bank的备付金账户之间通常在日终end-of-day批量完成中间过程依赖清分clearing与结算settlement清分计算谁该付谁多少钱并对交易进行轧差netting结算才让真实资金在备付金账户间移动。正因如此一笔扫码支付在消费者端的成功与资金真正到账之间存在时间差商户侧需要依赖对账来保证各系统记录一致。仓库文档 Reconciliation in Payment 进一步指出对账是比较不同系统记录、确保金额一致的过程会面临数据格式不统一、数据量巨大、日切时间cut-off time错位等痛点实践中通常需要数据规范化层、批处理或流式处理如 Flink/Hadoop以及临时差错 次日比对机制来兜底。可以说对账系统是扫码支付这类高频交易系统的安全网。总结一张二维码背后的完整链路回顾整条扫码支付链路出码阶段约 1 秒内收银台生成订单SN129803 / $123.45→ 商户电脑送 PSP → PSP 落库并生成二维码 URL → 支付网关读取并回传 → 商户电脑下发 → 收银台亮码付款阶段消费者钱包扫码 → 确认金额点 pay → 钱包通知 PSP → 支付网关标记二维码为 paid 并返回成功 → PSP 通知商户收款完成清算阶段日终/异步支付指令与资金实际划转分离依赖清结算与对账保障最终一致性。下一次你在便利店扫完码、听到收银机滴的一声时可以意识到这一声背后是收银系统、商户电脑、PSP、支付网关、钱包 App、数据库与日终结算系统共同完成的一次精巧协作。理解这张链路图也正是理解支付系统设计的第一步——更多支付主题内容可在仓库的 payment-and-fintech 分类 与 How Scan to Pay Works 原文 中继续深入。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐WeiXinMPSDK 微信支付 V3 Native 扫码支付实战下单、二维码生成与回调验签全流程WeiXinMPSDK 微信支付 V3 Native 扫码支付实战下单、二维码生成与回调验签全流程 本文围绕 WeiXinMPSDKSenparc.Weix后端即时通讯金融科技【限时免费】 yansongda/pay项目中支付宝扫码支付二维码生成问题解析yansongda/pay项目中支付宝扫码支付二维码生成问题解析 在yansongda/pay这个PHP支付SDK项目中开发者在使用支付宝扫码支付功能时可能会后端金融科技WeiXinMPSDK 微信 Native 支付实战指南从付款码 URL 签名、二维码生成到回调统一下单WeiXinMPSDK 微信 Native 支付实战指南从付款码 URL 签名、二维码生成到回调统一下单 Native 支付用于线下或微信环境以外的支付场后端即时通讯金融科技上一篇Diffusers 中的 ConsistencyDecoderScheduler基于一致性模型的两步图像解码调度器详解下一篇Ryujinx Switch模拟器5个简单步骤让您在PC上畅玩任天堂游戏创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考