更新时间：2026年10月15日

退款进度页先回答四件事：本次退多少钱、退到哪里、现在由谁处理、用户是否需要操作。把申请已提交、商户已处理、渠道处理中和已获得的最终结果分别表达；没有到账证据时，不把“已发起退款”写成“钱已到账”。失败或等待补充资料时，给出对应动作和可追踪记录。

下面用一笔包含保温杯和杯套的订单设计售后页面，两个商品分开退款。可以通过原型页面连接与演示把订单入口、退款详情、异常说明串起来，检查用户从通知返回时能否找到正确的那一笔退款。

先分清订单、商品和本次退款

演示订单实付138元，其中保温杯分摊118元，杯套分摊20元，不另计运费。顾客先为保温杯申请退款，杯套继续保留。详情主标题下写“本次退款118元”，旁边显示保温杯名称和退款单编号；订单实付138元放在明细中。若把138元做成页面上最大的数字，用户容易误以为整单都在退。

“订单状态”和“退款状态”也不能共用一个标签。保温杯退款完成后，订单可以显示“部分退款”，该退款单显示自己的处理结果。之后若杯套也申请20元退款，应新增一条有独立编号的记录；第二笔在处理中时，第一笔仍保留已完成结果。

实际订单还可能涉及优惠分摊、运费或多种支付方式，应读取业务系统给出的本次可退明细。页面不应让用户通过手算原价来猜退款金额；更不能在用户查看旧退款记录时，用后来变化的商品售价替换历史金额。

时间线写清发生了什么，而不只是点亮步骤

一条有用的时间线可以是“申请已提交—商户同意并发起—支付渠道处理中—退款结果已返回”。每个节点需要说明对象和时间来源。商户同意是售后决定，渠道受理是资金处理进展，两者之间可能还有等待，因此不要把它们压成一个模糊的“退款成功”。

对已经发生的节点显示实际时间，对当前节点显示明确说明，对尚未发生的节点不预填完成时间。如果业务能够提供预计时间，可以同时说明从哪一刻开始计算；没有可用估计时，展示“渠道处理中”和最近查询时间，比倒计时结束后重新计时更诚实。

例如Stripe退款文档区分多笔部分退款、等待处理、失败和需要补充操作等情况，退款结果与用户银行侧的呈现也需要分别理解。不同支付渠道提供的状态不完全相同，界面应与实际接入字段对应，而不是照搬一套统一的到账天数。

“原路退回”可以作为摘要，但不能是全部说明。能取得支付方式时，应显示方式名称和适当掩码，例如“原支付银行卡，尾号1234”；通过钱包余额支付则说明对应余额账户。不要展示完整卡号，也不要仅用用户不认识的渠道代码。

如果一笔退款分到多个原支付来源，按来源拆成几行，让各部分金额能够相加。总额已经成功但其中一条去向仍显示处理中，会造成矛盾；设计需与研发约定总体状态如何从分项结果得出。无法查询某个分项时，应表达未知范围，不把其他已确定结果一起清空。

可用的退款参考号应有字段名称和复制动作，并说明用于向谁查询。内部退款单号、订单号和渠道参考号不是同一个号码，不能全部命名为“流水号”。某渠道不提供参考号时，直接保留商户退款记录和客服入口，不制造一串看似真实的查询凭证。

退款异常不能一律放一个“重试”按钮。若商户尚未完成处理，顾客的下一步可能是查看说明或联系商户；若渠道需要补资料，才展示经过业务确认的资料入口；如果暂时取不到结果，先重查已有退款，不应引导顾客再次发起一笔。

错误原因还需要从内部术语翻成用户能够行动的文字。“下游返回异常”没有说明谁在处理；“暂时无法获取渠道结果，已保留退款记录”则交代了当前边界。不要凭一个技术错误码推测银行卡已经注销，也不要在用户页面展示服务端敏感信息。

在Pixso中制作订单售后列表、退款R01详情和退款R02详情三个画板。列表显示两个商品与各自金额；R01使用完成后的记录，R02使用渠道处理中状态。再给R02补一个“查询失败但保留上次状态”的画板，把通知入口直接连到R02，避免所有售后通知都落到最近一笔记录。

评审时从订单进入R01，再从通知进入R02，最后从R02返回订单。三次切换中，商品、金额、退款单号和去向应始终一致。让另一位评审者只看页面回答“哪笔已经处理完，哪笔还需等待”，如果必须向设计师口头确认，说明层级或文案还需要调整。

交付时分别为R01和R02标明金额来源、最近确认状态、查询时间及可执行动作。客服拿到“尚未收到款”的咨询后，应能从同一退款单找到去向和可用凭证；查询暂时失败时，原记录仍能帮助继续处理。