[{"data":1,"prerenderedAt":226},["ShallowReactive",2],{"blog-pay-core-model":3},{"id":4,"title":5,"body":6,"category":212,"date":213,"description":15,"extension":214,"meta":215,"navigation":216,"path":217,"seo":218,"stem":219,"tags":220,"__hash__":225},"blog\u002Fblog\u002Fpay-core-model.md","支付系统核心领域模型与交易链路解析",{"type":7,"value":8,"toc":205},"minimark",[9,12,16,19,24,27,54,57,78,82,85,105,110,124,128,135,146,151,154,195,198],[10,11,5],"h1",{"id":5},[13,14,15],"p",{},"在所有的互联网后端系统中，支付系统是对“数据一致性”和“鲁棒性”要求最严苛的领域。一笔资金的流转，往往需要跨越内部的业务线、交易中台、支付网关，以及外部的网联、银联和各大银行。",[13,17,18],{},"构建支付系统的第一步，是理清最基础的业务概念和单据模型。",[20,21,23],"h2",{"id":22},"_1-核心概念支付清算与结算","1. 核心概念：支付、清算与结算",[13,25,26],{},"很多人容易混淆支付、清算和结算的边界。在行业标准中，它们的定义有着严格的先后顺序：",[28,29,30,42,48],"ul",{},[31,32,33,37,38,41],"li",{},[34,35,36],"strong",{},"支付（Payment）："," 资金从付款方到收款方转移的",[34,39,40],{},"指令流转过程","。例如用户在收银台点击确认，支付系统将扣款指令发送给银行。",[31,43,44,47],{},[34,45,46],{},"清算（Clearing）："," 俗称“算账”。算清楚整个支付过程中，各个参与方（业务线、支付公司、渠道方、商户）的应付、应收金额，生成清算对账单。",[31,49,50,53],{},[34,51,52],{},"结算（Settlement）："," 俗称“给钱”。根据清算的结果，完成实际的账户余额变动和资金转移。",[13,55,56],{},"以快捷支付为例，完整的资金流通常伴随着“断直连”后的网联清算体系：",[58,59,60,66,72],"ol",{},[31,61,62,65],{},[34,63,64],{},"用户扣款："," 用户A使用银行卡支付 -> 支付公司上送指令 -> 网联 -> 开户行A扣减余额。",[31,67,68,71],{},[34,69,70],{},"网联清算（资金流）："," 银行A在央行的备付金\u002F清算账户 -> 划拨至支付公司在央行的清算账户（ACS账户）。",[31,73,74,77],{},[34,75,76],{},"商家结算（资金流）："," 支付公司通过网联 -> 划拨至商户B的开户行B账户，完成最终结算。",[20,79,81],{"id":80},"_2-单据数据模型一笔订单的衍生","2. 单据数据模型：一笔订单的衍生",[13,83,84],{},"在支付域，绝对不能用一张表打天下。标准的支付单据模型通常是分层的：",[28,86,87,93,99],{},[31,88,89,92],{},[34,90,91],{},"交易单（Trade Order）："," 面向业务。记录买卖双方的交易信息（谁买了什么，花了多少钱）。",[31,94,95,98],{},[34,96,97],{},"支付单（Payment Order）："," 面向支付核心。记录这笔交易的支付动作（用什么方式，支付了多少钱）。",[31,100,101,104],{},[34,102,103],{},"收款单 \u002F 内部单（Channel Order）："," 面向底层通道。收款单对应外部支付工具（如微信、银行卡），内部单对应内部支付工具（如余额、营销抵扣）。",[13,106,107],{},[34,108,109],{},"它们的关系与演进：",[28,111,112,118],{},[31,113,114,117],{},[34,115,116],{},"1 个交易单 -> N 个支付单："," 因为用户可能会支付失败后重试，或者中途取消更换支付方式。每一次新的收银台拉起动作，都应该生成一张新的支付单。",[31,119,120,123],{},[34,121,122],{},"1 个支付单 -> 1 个收款单 + N 个内部单："," 常见的组合支付场景。例如一笔 100 元的订单，用户使用了 10 元内部余额（内部单） + 90 元银行卡快捷支付（收款单）。",[20,125,127],{"id":126},"_3-核心挑战状态流转与并发控制","3. 核心挑战：状态流转与并发控制",[13,129,130,131,134],{},"单据状态机的设计，是支付系统稳定性的基石。通常的流转方向是自下而上的：",[34,132,133],{},"底层收款单成功 -> 驱动支付单成功 -> 驱动交易单成功","。",[13,136,137,138,141,142,145],{},"线上环境最容易出问题的，是",[34,139,140],{},"超时关单","与",[34,143,144],{},"支付异步回调","发生的并发碰撞。",[13,147,148],{},[34,149,150],{},"场景：网关回调通知支付成功，但此时交易系统发现订单刚好超时。",[13,152,153],{},"为了防止资金损失（用户钱扣了，但订单关闭没发货），支付回调交易的流程必须严格遵循以下校验逻辑：",[58,155,156,162],{},[31,157,158,161],{},[34,159,160],{},"加锁："," 根据交易单号加分布式锁，锁住该笔交易单。",[31,163,164,167],{},[34,165,166],{},"校验交易单状态：",[28,168,169,179,189],{},[31,170,171,174,175,178],{},[34,172,173],{},"情况 A（交易单已成功）："," 对比交易单关联的支付 ID 与当前回调的支付单 ID。如果不一致，说明用户发生了",[34,176,177],{},"重复支付","，立刻触发退款流程；如果一致，则是通道的重复通知，直接忽略并返回成功。",[31,180,181,184,185,188],{},[34,182,183],{},"情况 B（交易单已关单）："," 用户钱已经扣除，但订单已失效。立刻触发",[34,186,187],{},"关单退款","，把钱原路退回给用户。",[31,190,191,194],{},[34,192,193],{},"情况 C（处理中，但已到关单时间）："," 不推进订单状态，直接触发关单退款。",[13,196,197],{},"通过对单据状态机的严格校验和悲观锁控制，才能在极端网络延迟下，守住资金安全的底线。",[13,199,200],{},[201,202,204],"a",{"href":203},"\u002Fblog\u002F","返回博客列表",{"title":206,"searchDepth":207,"depth":207,"links":208},"",2,[209,210,211],{"id":22,"depth":207,"text":23},{"id":80,"depth":207,"text":81},{"id":126,"depth":207,"text":127},"支付架构","2026-03-19","md",{},true,"\u002Fblog\u002Fpay-core-model",{"title":5,"description":15},"blog\u002Fpay-core-model",[221,222,223,224],"支付系统","领域模型","状态机","并发控制","3KOTcH0nfSSRLmkJZL9OGH4nmgrSql4gwQjPxtfkUsU",1779959652909]