客户申请退款但商家没有收到通知，应先查申请是否真实提交，再核对子订单归属、处理队列、接收岗位、通知记录及实际待办。没有弹窗不证明没有申请，商家已经看到消息也不等于已处理，更不能把渠道退款成功通知当作最初售后申请通知。

先确认退款申请落在哪一层

客服通过正式受理入口定位申请、原商家子单、提交时间与当前状态，区分保存草稿、提交成功、补充材料和已撤回。客户看到的文字或截图只作线索，缺少记录时交订单及技术负责人查询，不要求顾客不断重提同一申请。

申请已存在时，确认它应由商家直接受理，还是先经平台审核分配。尚未到商家节点与已经分配但未送达是两类问题，不能用统一的“通知延迟”解释。

对照具体断点处理

申请分派到错误店铺或离岗账号，核对原子单和当前岗位安排，由负责人按授权更正接手人，保留原分派与新接手关系。不要把通知广播给所有商家，也不通过共享管理员账号临时处理。

待办已在正确岗位，但外部通知未生成、发送失败或权限条件不满足时，查看所采用渠道和版本的实际记录，由正式支持人员处理；有受控的备用受理方式则接续原申请。通知已发送却未获得确认时，核对接收对象与当前待办，不直接认定商家故意拒绝处理。

商家已处理但顾客仍看到旧状态时，查处理结果与显示更新，避免再次审批或重复退款。若最后确认属于规则中的待补材料，也应让客户知道缺什么、交给谁，而不是只留下“等待商家”。

消息修复与售后接手同时完成

电子商务法第五十九、六十一条涉及投诉处理和平台协助维权。具体处理要求按交易与适用规则确认，不编一个所有申请都通用的自动退款时限，也不让技术故障长期成为无人受理的理由。

凡科杰建云多商户方案可用于评估订单和商家协作，售后分派、站内待办、外部消息、重发及发送记录须按所用版本与渠道核对。功能清单中有客服或通知，不证明每个退款节点都自动覆盖。

恢复后用获准样例复查正常分派和接收失败的路径；原申请另确认由谁接手、已有何种处理及下一步。必要日志按OWASP日志指南理解事件对象和结果，安全日志不替代业务决定，测试不误发真实用户消息或操作真实退款。