H7.04.6split tender allocation设计研究
拆分多种方式支付同一订单时金额分配需清晰可核对
别名: 拆分支付 · 组合支付 · split tender
概念解释
一笔订单用余额 + 券 + 卡、或两张卡、或礼品卡加货到付款一起付，叫拆分支付。人必须看见每一腿分摊多少、合计是否等于应付、还差多少。可核对指每一腿有名称、金额、状态，加起来能心算或用计算器对上，而不是只给一个「组合支付」标签。
机制
拆分把一次确认变成多笔授权，工作记忆要同时稳住几条数字。界面若只突出「还差 X」，人不知道 X 会从哪一腿出，也不知道余额够不够。自动填满某一腿（先扣余额）若不展示，人会以为卡会被划走全额。部分成功更危险：余额扣了、卡失败，合计不再等于应付，却仍显示「支付中」。核对失败的后果是重复授权或漏付。每一腿还要把手续费归到自己头上，否则总额对得上、分项对不上。
怎么研究
给必须拆分的金额（余额不足全额），比较「自动分配不展示」「展示每腿金额可改」「只展示还差」。再插入一腿失败。
自变量：分配是否可见、是否可编辑、失败一腿是否冻结已成功腿、合计校验是否在提交前阻断。 因变量：能否复述每腿金额、提交时合计误差、部分成功后的错误重试、客服对账工单。
实验室整数金额会低估对账困难。真实余额有未入账、冻结，要用会变的余额测「显示与可扣不一致」。
边界
有的渠道不允许与别的方式同单拆分，应在选择时拒绝组合，而不是提交后拆失败。订阅续费通常不能拆分授权。现金与发票报销场景可能要求单一方式，拆分会让凭证无法入账。小额一腿低于渠道最低限额时，要提示合并而不是生成一笔注定失败的授权。
怎么落地
- 拆分界面列出每一腿：名称、金额、可改范围；顶部固定「已分配 / 应付 / 差额」，差额非零不能提交。
- 自动填满的规则（先余额后卡）写出来，并允许人改每一腿，改完立即重算。
- 一腿失败时标明哪一腿已扣、哪一腿未扣，已扣腿不要再发起一次。
- 验证：让人用余额 + 卡付一单，遮住帮助文档，写出两腿金额与合计；再让卡腿失败，问已经扣了哪一笔、下一步扣哪里。分项加总不等于应付，或说不清已扣腿，即失败。