本文讨论支付系统设计，不构成法律、会计或合规意见。具体规则应以合同、账单、银行证明和有效监管文件为准。
支付接口返回 success，只说明某个系统接受或完成了这次请求。它无法单独证明业务已经履约、内部账户已经正确记账，也无法证明通道已经完成资金转移。这些结果要由后续记录确认。
可信的支付系统要同时维护三类事实：业务系统记录交易为什么发生，内部账户与会计账记录机构如何确认债权债务，银行或支付通道证明真实资金发生了什么。三类记录持续核对一致，才能支撑退款、结算、审计和差错处理。
一笔支付涉及五层记录
支付从业务意图开始，经过处理、记账和多方金额计算，再进入真实资金结算。按职责可分为五层：
| 层次 | 主要对象 | 需要回答的问题 |
| 交易层 | 商品、订单、参与方、合同、业务规则 | 这笔钱为什么发生，权利义务属于谁 |
| 支付处理层 | 支付单、支付请求、支付方式、路由、通道 | 如何把业务意图变成可执行的支付指令 |
| 账户层 | 余额、冻结、扣减、入账、科目 | 机构内部如何记录余额变化和债权债务 |
| 清分与清算层 | 应收应付、手续费、分账、轧差 | 各参与方应收多少、应付多少 |
| 最终结算层 | 银行账户、备付金账户、清算账户 | 真实资金是否完成转移 |
不同机构对「清算」和「结算」的定义并不完全一致。设计系统时，应明确指令经过哪些主体、资金实际在哪个账户，以及每套账在什么时间改变。
三类记录的生命周期、状态来源和责任主体不同，应分别保存并建立关联。合并成一张大表虽然方便短期查询，却很难解释异步结果和历史差异。
订单、账单、支付单和支付请求各有职责
一笔业务通常涉及业务订单、账单、支付单、支付请求和外部通道流水号。
业务订单描述商品或服务，账单描述应付关系，支付单代表一次支付任务，支付请求记录每次执行尝试，外部流水用于和通道核对。一次支付单可能因为超时、换通道或重新提交产生多次支付请求，但业务订单并没有因此重复创建。
这些对象共用一个编号时，初版流程仍可能正常运行。一旦发生重试、部分退款、合单支付或通道补单，系统就无法准确回答某次请求属于哪笔业务、哪次尝试已经扣款，以及哪个外部结果可以推进内部状态。
父子订单和拆单同样需要明确归属规则。商品、优惠、税费、支付、退款、履约和结算分别挂在父单还是子单，应采用一致规则。否则前端虽然完成下单，后端仍无法解释资金属于哪个对象。
支付方式、通道和能力是三类对象
支付方式是付款方看到的选择，比如银行卡、钱包余额、积分或虚拟卡。支付通道是系统实际接入的银行、支付机构或网络，同一种支付方式可以配置多条通道。支付能力则是业务可以调用的结果，包括收款、付款、退款、代扣、分账和合单。
分开建模后，三类变化可以各自处理。产品增加一种展示方式，不必改动所有通道适配器；某条通道不可用时，路由可以选择同类替代通道；业务只依赖「退款」能力，无需理解每家通道的参数差异。
路由根据可用性、成功率、成本、额度、地区、风险和流动性选择通道。支付核心负责参数校验、幂等控制、账户预处理、选路、通道请求、结果查询、异步通知、超时处理和状态推进。业务系统无需分别维护这些判断。
状态机要保留「结果未知」
外部系统无法保证同步返回最终结果。请求超时有两种可能：通道没有收到请求，或者通道已经扣款但响应在网络中丢失。把超时直接记为支付失败，重新发起时就可能重复扣款。
支付状态至少包括待处理、处理中、成功、失败、关闭和待人工确认。同步响应、主动查询、异步通知和事后对账都可能推进状态，每个结果入口都要经过幂等与状态转换规则。
支付请求还应保留当时使用的通道、请求标识、金额、币种和响应摘要。外部状态晚于内部状态到达时，系统才能判断这是重复通知、迟到结果，还是需要补偿的新事实。
清分计算权利义务，结算转移真实资金
清分处理的是金额归属。一笔付款可能同时包含商户货款、平台手续费、渠道成本、税费、补贴和分账金额，系统需要根据合同、费率和业务规则计算每一方的应收与应付。
会员等级、商户类型或骑手等级可能影响费率。相应业务领域提供可追溯的规则版本和计算依据，清分结果记录本次计算采用的事实，无需复制各领域的全部字段。这样才能在费率变化后解释历史金额。
结算确定付款时点和付款方式。系统按商户、产品与结算周期聚合清分结果，扣除结算手续费，检查最低结算金额和退款预留，再生成结算单与打款申请。工作日、节假日、自动或自主发起、结算到户或到卡，都会改变资金到达时间。
分账也存在两种资金性质不同的实现。一种是在付款时按订单直接进入各收款方账户，另一种是先进入平台或监管账户，再按内部账进行分配。产品界面都可以显示为「分账」，合同关系、账户控制和合规责任却不相同。
业务账户、会计账和银行账户各有职责
业务账户服务于产品操作，记录可用余额、冻结金额、欠款和额度。会计账通过借贷与科目表达经济含义。银行账户或通道账户保存真实资金。三者可以由同一笔业务驱动，但不能用其中一套代替另外两套。
会计记录至少要支持从原始单据追到记账凭证、明细账、总账和科目余额，也要支持从某个余额反查构成它的业务流水。具体借贷方向取决于账户主体和科目性质，不能脱离会计定义复制固定模板。
余额不足也要形成明确事实。商户资金已经结算后再发生退款，平台可能先垫资并形成商户欠款，也可能拒绝退款。选择取决于合同和资金制度。若允许垫资，欠款账户还要配合额度、暂停服务、追偿和坏账处理；负余额被记录下来，不代表风险已经消失。
每个系统边界都要对账
对账覆盖业务与支付、支付与通道、清分与账户、账户与会计、内部资金账与银行账。每个边界都可能产生单边记录、状态差异和时间差。
核对过程先用稳定标识匹配双方记录，再比较金额、币种、方向、状态、时间和手续费。结果至少要区分双方一致、我方单边、对方单边、金额或状态不一致，以及由处理时点造成的暂时差异。
余额核对还要解释两个期末数字之间的差异。平台已经扣账但尚未提交银行，或者银行已经处理但平台尚未入账，都会形成在途项。余额调节关系需要包含期初余额、本期发生额、在途调整和期末余额：
期初余额 + 本期收入 - 本期支出 + 在途调整 = 期末余额
每个差异应转成可处理的任务，记录责任人、证据、处理动作和关闭结果。差异报表还要跟踪处理进度，直到相关账务恢复一致。
退款依赖完整的原交易记录
退款沿着原交易反向处理，会同时影响支付单、订单、账单、支付请求、清分结果、商户结算、优惠、积分、库存、税务和资金账户。原交易停留得越靠后，逆向动作越多。
一个原支付单可以产生多次部分退款。系统要保留原支付关系、退款单、每次退款请求和通道流水，并控制累计退款金额不超过可退金额。退款与支付共用同一套状态和流水字段时，很容易丢失原交易关系，也难以解释多次尝试。
组合支付、合单支付、分次支付和分期支付需要不同的账务与退款规则。组合支付同时使用多种资金来源；合单支付把多笔订单合为一次付款；分次支付把金额分多次完成；分期支付还带有授信或贷款属性。
新支付轨道沿用同一套资金约束
跨境支付会增加本地支付网络、收单机构、合作银行、代理行账户、外汇处理、时区和不同结算周期。接入一家聚合服务商后，后端仍要处理多条资金路径。支付汇率、退款汇率、结算汇率及其承担方，中间行费用、制裁筛查和各账户流动性都要单独管理。
稳定币增加了一条支持 7×24 小时转移、链上可验证的支付与结算轨道。企业还要处理法币出入金、资产托管、会计、税务、KYC、KYT、制裁筛查和流动性。选择基础设施时，要确认托管方式、密钥恢复、热冷钱包组合、多人审批、额度策略和审计记录。
AI Agent 与虚拟信用卡（VCC）改变了付款发起者和交互方式。一次性卡、独立钱包或受限支付凭证可以为 Agent 设置预算、商户范围、有效期和撤销条件。系统必须记录授权主体、损失责任、人工审批条件、异常阻断和完整操作记录。
接入新轨道时，交易单据、内部账、真实资金和监管责任都要纳入统一的支付单、状态机、账户、对账和审计流程。
用业务指标检验系统效果
评估支付系统要持续跟踪支付成功率、转化率、退款完成率、结算时效、差错率、坏账率和人工处理成本。
这些指标要按业务维度拆分。成功率要区分地区、支付方式、通道和失败原因，结算时效要区分合同周期与实际到账，差错率要追到具体系统边界。成功率下降或结算变慢时，拆分后的指标可以定位对应的市场、通道和系统边界。
