发卡平台售后跟进，怎样确认已同步给买家

自动发卡平台的售后处理中，卖家容易把“已提交回复”等同于“买家已获知结果”，但接口返回成功、本地记录已存，并不保证售后状态对买家可见。只要平台状态、本地状态与买家可见状态没有对齐，买家仍可能重复提问，或售后长时间停留在原状态。下面只解决一个问题：售后跟进完成后，怎样确认处理结果已准确同步。

先分清三种不同的状态

确认同步前，需要区分三类状态，不能用单一记录判断。第一类是平台售后状态，对应caseState，取值为 submitted、handling、resolved、closed，判断售后单处于哪个阶段必须以平台查询结果为准。第二类是本地跟进状态，即卖家本地记录的“已回复”“已补发”“已关闭”等动作，它只证明本地完成了操作，不能证明买家侧已同步。第三类是买家可见状态，即买家在平台售后单上看到的处理结果和消息，只有它与本地预期一致，跟进才算完成。

例如，卖家调用追加消息接口返回成功，只能确认本次消息已被平台接收，不能推断买家已经看到。此时若只按本地记录关闭售后，买家侧可能仍处于处理中，后续仍会发起咨询。

确认同步的核对顺序

确认同步需按先售后单、再消息、后状态的顺序排查，避免只看一处就下结论。首先，用创建售后时返回的platformCaseRef调用查询售后详情接口，核对返回的caseState是否符合预期。若预期已处理，实际仍处于 handling，说明处理结果尚未同步到平台，需先完成平台侧处理。

其次，核对消息是否完整。追加消息成功后，接口会同步返回新增消息，平台不会通过 aftersale.message.created 推送同一条买家已提交的消息，但商户或平台后续新增的公开回复会通过该事件推送，并携带售后当前状态。因此，仅凭本地发送记录不能确认回复已推送，需对照售后详情接口返回的messages，确认最新一条消息由 authorRole 为 merchant 的角色发出，且body内容与本地一致。

核对状态与消息的具体动作

具体操作分为三步。第一步，取平台售后编号，调用查询售后详情接口，记录caseState、updatedAt和最新revision。第二步，在返回的messages中定位最后一条消息，确认其authorRole为 merchant，format与本地发送一致，body完整，并核对消息的messageRef是否为预期编号。第三步，比较updatedAt与本地完成跟进的时间，若平台时间滞后，说明同步尚未完成，需等待平台处理；若时间已更新且状态符合预期，才算同步完成。

网络重试追加消息时，要继续使用原 clientMessageRef，编号和内容都相同时平台返回原消息，不会重复追加；若编号相同而内容不同，会返回 IDEMPOTENCY_CONFLICT，此时不能判断为同步成功，需核对已有消息内容，避免误判。

同步异常的处理方式

核对后若发现同步异常，优先做只读核对，不要重新创建售后或修改原单。若状态未更新但消息已完整，可再查询一次售后详情，排除本地记录延迟；若两次查询结果一致，再确认平台侧是否需要进一步处理。若消息缺失，先检查clientMessageRef是否重复使用、body是否为合法 HTTPS 地址，再判断是否需要重新追加，而不是直接关闭售后。

例如，卖家追加了一条处理完成的消息，查询售后详情时发现消息已存在，但caseState仍为 handling，此时问题不在消息同步，而是平台售后单尚未完成处理，应保留售后单，等待平台状态变化，而不是在本地提前关闭。

判定同步完成的最终标准

只有同时满足三个条件，售后跟进才算完成：平台售后详情的caseState符合处理预期，最新一条公开消息由商户发出且内容完整，平台返回的updatedAt与完成时间一致。三个条件缺一不可，以平台查询结果为准，本地记录仅作为参考，不能替代买家侧的可见状态。

参考资料：接入指南（2026-09-20）；创建售后（2026-08-31）；查询售后详情（2026-08-31）；追加售后消息（2026-08-31）。具体操作与适用范围以对应文档为准。