H7.03.2all-in price before confirm设计研究
最终价格需在确认前完整呈现
别名: 应付总额 · 全包价 · all-in price · total due
概念解释
人按下「确认支付」之前，屏幕上必须出现一笔应付总额：货价、已确定的附加费、已减的优惠，加总后的那一个数字，以及币种。完整呈现不是「费用出现得早」——早出现的可能仍是估计——而是在不可逆扣款前，数字已经闭合，没有「到账后再补」。这条也不管分期的利息怎么展开，那是下一层；这里只要扣款金额与人看见的总额一致。
机制
确认动作把注意从比较转到执行，工作记忆里只留得下一个数字。若总额被拆在折叠区、小字、或跳转到支付机构后才出现，人按下的是未闭合的承诺。支付机构页如果另加手续费而本站摘要没写，人会以为两套系统在争，事后对账失败。完整意味着三件事同时在场：构成（可展开）、合计（主数字）、与按钮文案一致（「支付 ¥X」而不是只写「支付」）。少任何一项，人要么不敢按，要么按完才发现差额。
怎么研究
在确认前操纵总额的完整度：合计可见但构成折叠、构成可见但合计不突出、跳转后才出最终数字。
自变量：合计是否在按钮旁、构成默认展开还是折叠、跳转支付机构后数字是否与本站一致。 因变量：确认前能否复述应付额、支付后争议、因「对不上」取消。
眼动可以看合计是否被注视，但注视不等于理解构成。让人在按按钮前用自己的话写出将扣多少，比满意度更硬。不要用「有价格明细就算透明」——明细很长时人只读合计，合计错了明细帮不上忙。
边界
拍卖、出价、浮动汇率在确认时仍可能是「大约」，必须标明将按成交或扣款瞬间的汇率结算，并给出上限。订阅的首次扣款和后续周期金额不同，确认前要两笔都写，不能只写第一期。货到付款的应付发生在收货，确认页仍需给出将收取的总额。多币种显示若只是换算参考，要标明扣款币种，避免两套数字都被当成应付。
怎么落地
- 确认支付的视口内固定展示应付总额，与按钮文案中的金额一致；构成用列表可展开，默认至少看到货价、附加、优惠、合计四行。
- 跳转第三方支付前把同一总额写入摘要；机构页若会再加费，先在本站计入合计，否则不要跳。
- 总额变化（改地址、改券）必须立刻重算并阻断用旧额提交。
- 验证：在按钮前遮住除合计和按钮以外的区域，问将扣多少；再对账支付成功页与渠道账单。三处数字不一致即失败。