销售体系子案例 / 支付与清结算让每一笔资金，
让每一笔资金，
可识别、可控制、可追溯。
建设覆盖小订、大定、在线支付、电汇、退款和资金清分的交易能力，并为余额不足、混合支付和超额入账等异常场景建立补救机制。
01
产品模型汽车支付不是
汽车支付不是
接入一个收银台。
支付背后还要处理业务订单、支付渠道、资金账户、退款清分和异常资金流转。
业务订单→支付单 / 电汇子账号→资金账户→退款或清分→资金处理结果
02
小订资金保障退款与清分，
保障退款与清分，
也释放大额资金价值。
用户支付↓银行托管账户↓退款 / 确认门店后清分
资金由银行托管，只能获得约定利息，无法参与集团统一资金运作。
微信 / 支付宝↓D+1 进入结算账户↓集团资金统筹 + 退款清分备付
面对千万至上亿元级资金，在保留退款和清分备付的同时，其余资金进入集团统筹，获得高于固定利息的资金使用价值。
余额达到阈值→自动补充资金→短信 / 邮件 / 企业微信→恢复任务队列
余额不足时，退款与清分进入队列；资金到账后优先执行影响交付的清分任务。
03
大定与电汇让企业转账，
让企业转账，
也能自动识别订单。
通过银行虚拟子账号建立订单与入账的唯一关系，减少人工认款。
银行主账户＋6 位虚拟子账号＝订单专属收款账号
选择电汇并填写付款户名→系统分配子账号→银行入账→自动识别订单与金额
业务订单按业务规则设定有效期
≠支付订单单次有效 2 小时
业务订单有效期内，用户拉起收银台时，若当前支付单距到期不足 10 分钟则创建新支付单；不会在后台持续刷新。
04
退款与清分资金流动前，
资金流动前，
先完成多重校验。
订单 · 门店 · 银行备案 · 金额
业务系统与银行系统进行双重校验，避免资金进入错误账户。
退款接口 ≠ 清分接口
为资金动作赋予明确业务性质，便于财务核对和后续追溯。
交付门店确认→双重校验→发起清分→指定门店收款
05
异常机制标准流程之外，
标准流程之外，
预先设计补救路径。
同一业务订单产生多笔支付时，认定第一笔成功入账的支付单，其余已入账资金原路退回。
退款与清分进入队列，资金补足后恢复执行，并优先处理影响交付的清分任务。
触发企业微信预警，由业务确认退款、补充付款或尾款处理。
提前预警；无法原路退回时，转入清分与订单关闭处理。
项目价值不在于接入三种支付方式，而是让每一笔资金都可识别、可校验、可退款、可清分、可追溯。
本案例中的银行、账户、金额和内部系统信息均已脱敏与抽象，仅用于展示产品设计思路。