Coupang 换货可以拒绝吗？只有两个理由

不可以。根据 Coupang 官方文档，卖家只能因两种情况拒绝换货：换货商品已售罄（SOLDOUT），或客户已撤回换货申请（WITHDRAW）。希望改为退款、等待补货，或出于利润考虑，都不是第三种拒绝理由；如果这两种文档规定的条件都不成立，就应继续按正常换货流程处理。

这一点很重要，因为拒绝代码是一项运营记录。它记录的是该换货请求为何没有继续执行，而不是卖家偏好的商业处理方式。发送错误的代码，可能让客服备注、库存操作和履约决策都错误地写成缺货或买家撤回，尽管这些事实并未发生。

两个拒绝理由都必须有事实依据

卖家不能仅因自己不满意就拒绝换货；这项操作的适用范围更窄。两个代码回答的是一个事实问题：为什么所请求的换货已经无法继续？它们不回答诸如哪种处理方式成本更低或所需操作更少之类的商业问题。

这一区分是最重要的控制点。如果记录为 SOLDOUT，审核人员应能看出替换商品确实无法供应；如果记录为 WITHDRAW，则应能看出这是客户主动做出的决定。不能仅因退款对卖家更省事，就选择其中任一代码。

换货拒绝理由和退款或退货结果是两个独立的决定。某个案件仍可能需要采取不同的平台操作，或根据适用的韩国规则另行审核。稳妥做法是先记录实际发生的事件，再通过正确流程决定下一步面向客户的处理。

拒绝换货前，按这条规则判断

这条规则应针对已经开启的换货申请，而不是针对卖家原本希望客户提出的请求：

1. 客户是否确实撤回了换货申请？ 如果是，使用 WITHDRAW。所谓“确实”，是指已确认的客户操作；不能根据沉默、延迟或卖家侧取消来推断撤回。
2. 如果不是，客户请求的换货商品是否确实无法供应？ 如果是，使用 SOLDOUT。检查具体的换货商品或变体，不要只看更宽泛的产品系列。
3. 如果两者均不成立，不要使用卖家侧拒绝操作。 让申请继续留在正常换货流程中，并通过能够提供韩语服务的客服团队和相应的履约流程处理。
4. 如果记录相互矛盾，先核实再操作。 例如，客户消息可能表明其改变主意，但换货申请仍处于有效状态；或者库存系统之间可能存在不一致。不要因为某个代码会产生卖家希望的退款结果，就选择该代码。

这两项判断对应不同原因。缺货说明无法供应替换商品；撤回说明客户终止了换货申请。如果同一案件同时出现这两个事实，不要根据期望的商业结果自行设定优先级；应查阅当前 Coupang 流程或支持指引，确认具体实现要求。

何时应使用 SOLDOUT

仅在换货商品确实无法供应时使用 SOLDOUT。重点是客户请求的那件替换商品：品牌能否通过换货流程提供这件具体商品？如果不能，且确实是因为相关库存不可用，那么 SOLDOUT 才准确反映实际情况。

检查应针对客户请求的具体选项。一个产品系列可能仍有库存，但用于换货的具体尺码、颜色、型号或套装可能没有。反过来，团队内部决定不分配现有库存，也不自动等同于商品已售罄。代码不应掩盖这一差异。

在采取行动前，应区分以下情况：

• 确实无法供应： 没有可用于满足所请求换货的相关商品。
• 内部不愿处理： 有库存，但换货不便、利润较低，或不是品牌希望的结果。
• 补货较慢： 团队预计之后会有库存，但目前不希望继续换货流程。

第一种情况最符合 SOLDOUT 的适用条件。仅有后两种情况都不足以使用该代码。补货延迟可能造成真实的服务问题，但不能把这一时间问题记成缺货。如果事实不清，应核实当前 Coupang 操作如何处理该商品，而不是为了结案把时间问题写成缺货记录。

实用的内部核查很简单：找出客户请求的那件替换商品，确认其当前可用性，并保留支持该决定的库存核查记录。该记录是运营控制措施，并不意味着 Coupang 要求采用某种特定证据格式。它能让客服、库存和集成团队基于同一事实依据开展工作。

请看以下三个例子：

• 客户申请更换某一具体变体，团队确认没有任何该变体的库存可供换货。这正是 SOLDOUT 所针对的事实情形。
• 某件商品有库存，但品牌更愿意因为换货利润较低而退款。这是商业偏好，而不是文档规定的缺货条件。
• 库存记录对于是否能够供应替换商品存在冲突。正确做法是先解决这一差异，而不是暂时选择 SOLDOUT 来结案。

何时应使用 WITHDRAW

WITHDRAW 对应客户行为。只有当客户通过受支持的平台流程实际撤回换货申请，或通过清晰的客服确认表明客户已撤回时，才使用该代码。卖家不能仅仅因为退款更方便，就自行将其记录为客户撤回。

沉默不等于撤回。客户未回复、卖家在内部取消申请，或客户表达不满，都不会自动构成文档规定的撤回条件。这些情况可能需要跟进，但不能据此把记录改写成买家主动撤回换货申请。

客户发消息询问能否退款，也需要谨慎处理。它可能是在请求改变处理结果，但并不自动证明现有换货申请已经撤回。应确认客户实际选择了什么，然后分别处理由此产生的退货或退款路径。未经确认客户撤回，不要将一般性的 refund requested 值映射为 WITHDRAW。

即使客户确实撤回，WITHDRAW 也只处理换货拒绝理由。它本身并不决定是否需要退款、退货、运费承担方式或其他客服步骤。这些问题属于适用的平台流程和相关韩国规则。

当两个理由都不适用时怎么办

最重要的是：如果既没有真实缺货，也没有确认的客户撤回，就不要通过此操作拒绝换货。应让申请继续走正常流程，而不是强行套用两个不准确的代码之一。

实际交接可以按以下方式进行：

1. 让换货申请保持有效，继续处于正常运营队列中。
2. 确认客户请求的替换商品，以及该具体商品或选项的当前库存状态。
3. 如果客户的要求已发生变化，通过能够提供韩语服务的客服团队确认客户希望的结果。 除非客户确实撤回，否则不要告诉客户换货已被撤回。
4. 让履约记录与换货流程保持一致。 如果单独的问题是替换商品的跟踪，Coupang 换货跟踪号：先确认退货收件 解释了为什么追踪替换商品是一个独立的运营步骤。
5. 对未覆盖的边界情况进行核实，依据当前 Coupang 官方开发者文档或支持指引处理，不要发送会错误陈述原因的代码。

不要把平台履约和卖家决策合并为一步。在涉及 Rocket Growth 时，Coupang Rocket Growth 下谁负责处理退货？ 有助于区分面向客户的履约活动与卖家的库存及退货处置责任。平台也不会免除卖家侧的客户服务义务；Coupang 能处理韩国买家的所有咨询吗？不能——卖家责任 介绍了这一边界。

这也说明集成系统需要建立清晰的数据模型。不要将通用值（如 refund requested、seller prefers refund、no response 或 restock delay）映射为任一拒绝代码。这些值描述的是期望结果或内部状态。代码选择应取决于已核实的事件：客户已撤回，或换货商品确实无法供应。

关于 Coupang 换货拒绝的常见问题

我可以因为退款更容易处理而拒绝换货吗？

不可以。卖家偏好的退款处理不属于文档规定的卖家侧换货拒绝条件。如果客户没有撤回，且换货商品并非确实售罄，就应让申请继续走正常流程，任何后续退款决定都应通过正确路径处理。

补货较慢等同于 SOLDOUT 吗？

不一定。关键区别在于换货商品是否确实无法供应，而不只是卖家不想等待补货。选择代码前，应核实具体商品和当前 Coupang 操作。

如果客户停止回复，我可以使用 WITHDRAW 吗？

不可以。未回复不等于客户实际撤回。在没有确认撤回的情况下，不要仅因对话陷入沉默，就把案件记录为买家主动撤回。

如果客户要求退款而不是换货怎么办？

将其视为可能需要进一步确认的请求，而不是自动发生的 WITHDRAW 事件。确认客户是否确实撤回了换货，然后根据适用的平台流程和韩国规则，另行评估退货或退款路径。

任一代码能否确定客户在韩国法律下的权利？

不能。这些代码描述的是平台操作，并不能替代根据现行韩国法律审查退货、退款或消费者保护义务。当问题超出状态代码范围时，平台操作应参考 Coupang 官方开发者文档，现行法条文本则应查阅韩国法令信息中心（law.go.kr）。

集成系统应验证什么？

在发送任一代码前，应要求存在已核实的事实触发条件：WITHDRAW 需要确认客户撤回，SOLDOUT 需要换货商品确实无法供应。诸如 refund requested 之类的通用值，应保留为客服或退货流程中的状态值，不应作为换货拒绝理由。