Can You Reject a Coupang Exchange? Only Two Reasons

No. Coupang’s documented seller-side exchange-rejection operation recognizes only two conditions: the exchange item is sold out (SOLDOUT) or the customer has withdrawn the exchange request (WITHDRAW). Wanting to refund instead, waiting for replenishment, or protecting margin is not a third rejection reason; if neither documented condition is true, keep the request in the normal exchange workflow.

That distinction matters because a rejection code is an operational record. It tells the workflow why the requested replacement did not proceed; it is not a general-purpose button for the seller’s preferred commercial outcome. Sending the wrong code can leave customer-service notes, inventory actions, and fulfillment decisions describing a stockout or buyer withdrawal that never happened.

The two rejection reasons are factual conditions

Seller-side rejection is narrower than seller dissatisfaction. The two codes answer a factual question: why can the requested exchange no longer proceed? They do not answer a commercial question such as which resolution would cost less or require less handling.

That distinction is the core control. If the record says SOLDOUT, a reviewer should be able to understand that the replacement could not be supplied. If it says WITHDRAW, the record should point to a customer decision. Neither code should be selected simply because a refund is the cleaner outcome for the seller.

An exchange-rejection reason and a refund or return outcome are separate decisions. A particular case may still require a different platform action or a separate review under applicable Korean rules. The safe practice is to record the event that actually occurred first, then decide the next customer-facing step through the correct workflow.

Use this decision rule before rejecting an exchange

Apply the rule to the exchange request that is already open—not to what you would have preferred the customer to request:

1. Did the customer actually withdraw the exchange request? If yes, use WITHDRAW. Actual means a confirmed customer action; do not infer withdrawal from silence, delay, or a seller-side cancellation.
2. If not, is the requested exchange item genuinely unavailable? If yes, use SOLDOUT. Check the exact exchange item or variant, not only the broader product family.
3. If neither is true, do not use the seller-side rejection operation. Keep the request in the normal exchange workflow and resolve it through the appropriate Korean-capable customer-service and fulfillment process.
4. If the records conflict, verify before acting. For example, a customer message may suggest a change of mind while the exchange request remains active, or inventory systems may disagree. Do not choose a code because it produces the refund outcome the seller wants.

The two tests describe different causes. A stockout says the replacement could not be supplied. A withdrawal says the customer ended the exchange request. If both facts appear in the same case, do not invent a priority from the desired commercial result; check the current Coupang workflow or support guidance for that implementation detail.

When SOLDOUT is the correct route

Use SOLDOUT only when the exchange item is genuinely unavailable. Focus on the replacement the customer requested: can the brand supply that exact item through the exchange process? If the answer is no because the relevant stock is actually unavailable, the code describes the operational fact.

The check should be specific to the requested option. A product family may still be available while the particular size, color, model, or bundle requested for exchange is not. Conversely, a team’s internal decision not to allocate available stock is not automatically the same as the item being sold out. The code should not hide that distinction.

Separate these situations before taking action:

• Genuine unavailability: there is no relevant item available to supply the requested exchange.
• Internal reluctance: stock exists, but the exchange is inconvenient, less profitable, or not the outcome the brand wants.
• Slow replenishment: the team expects stock later but does not want to continue the exchange process now.

The first situation is the clearest match for SOLDOUT. The latter two, by themselves, are not enough. Slow replenishment can create a real service problem, but it does not give the seller a new rejection reason. If the facts are unclear, verify how the current Coupang operation treats the item rather than converting a timing problem into a stockout record.

A practical internal check is simple: identify the exact replacement item, confirm its current availability, and preserve the inventory check that supports the decision. That record is an operating control, not a claim that Coupang requires a particular evidence format. It gives customer service, inventory, and integration teams the same factual basis.

Consider three examples:

• A customer requests an exchange for a specific variant, and the team confirms that no unit of that variant is available to supply. This is the fact pattern for which SOLDOUT is intended.
• A unit is available, but the brand would rather issue a refund because the exchange has poor margins. That is a commercial preference, not the documented stockout condition.
• Inventory records disagree about whether the replacement can be supplied. The right response is to resolve the discrepancy first, not to select SOLDOUT as a temporary way to close the request.

When WITHDRAW is the correct route

WITHDRAW belongs to customer action. Use it when the customer has actually withdrawn the exchange request through the supported platform flow or through a clear customer-service confirmation. The seller cannot create a withdrawal merely by deciding that a refund is easier.

Silence is not withdrawal. A customer who has not replied, a seller who cancels the request internally, or a customer who expresses dissatisfaction has not automatically created the documented withdrawal condition. Those facts may require follow-up, but they do not authorize the team to rewrite the record as buyer-initiated.

A customer message asking whether a refund is possible also deserves care. It may be a request to change the outcome, but it is not automatically proof that the existing exchange request has been withdrawn. Confirm what the customer has actually chosen, then handle the resulting return or refund route separately. Do not map a general refund requested value to WITHDRAW without a confirmed customer withdrawal.

Even when the customer has genuinely withdrawn, WITHDRAW only addresses the exchange-rejection reason. It does not, by itself, decide whether a refund, return, shipping-cost treatment, or other customer-service step is required. Those questions belong to the applicable platform workflow and the relevant Korean rules.

What to do when neither reason applies

The most important negative rule is also the easiest to skip: if there is no genuine stockout and no confirmed customer withdrawal, do not reject the exchange through this operation. Keep the request in its normal workflow instead of forcing it into one of two inaccurate codes.

A practical handoff looks like this:

1. Keep the exchange request active in the normal operational queue.
2. Confirm the requested replacement and the current inventory state for that exact item or option.
3. Clarify the customer’s desired outcome through Korean-capable customer service if the request has changed. Do not tell the customer the exchange was withdrawn unless the customer actually withdrew it.
4. Keep fulfillment records aligned with the exchange workflow. If the separate issue is replacement tracking, Coupang Exchange Tracking Number: Return Receipt First explains why tracking the replacement is its own operational step.
5. Verify uncovered edge cases against current Coupang official developer documentation or support guidance rather than sending a code that misstates the reason.

Do not collapse platform fulfillment and seller decision-making into one step. Where Rocket Growth is involved, Who Handles Returns Under Coupang Rocket Growth? helps separate customer-facing fulfillment activity from the seller’s inventory and return-disposition responsibilities. The platform also does not remove seller-side customer-service duties; Can Coupang Handle Every Korean Buyer Inquiry? No—Seller Duties covers that boundary.

This is also where integrations need a clear data model. Do not map generic values such as refund requested, seller prefers refund, no response, or restock delay to either rejection code. Those values describe a desired outcome or an internal state. Code selection should depend on a verified event: the customer withdrew, or the exchange item was genuinely unavailable.

Common questions about Coupang exchange rejection

Can I reject the exchange because a refund is easier?

No. A preferred refund is not one of the documented seller-side exchange-rejection conditions. If the customer did not withdraw and the exchange item is not genuinely sold out, keep the request in the normal workflow and process any later refund decision through the correct route.

Is slow replenishment the same as SOLDOUT?

Not automatically. The relevant distinction is genuine unavailability of the exchange item, not simply a desire to avoid waiting for replenishment. Verify the exact item and the current Coupang operation before selecting the code.

Can I use WITHDRAW if the customer stopped responding?

No. Lack of response is not the same as an actual customer withdrawal. Without a confirmed withdrawal, do not record the case as buyer-initiated merely because the conversation has gone quiet.

What if the customer asks for a refund instead of an exchange?

Treat that as a request that may need clarification, not as an automatic WITHDRAW event. Confirm whether the customer has actually withdrawn the exchange, then assess the separate return or refund route under the applicable platform process and Korean rules.

Does either code settle the customer’s Korean legal rights?

No. The codes describe a platform operation. They do not replace a review of return, refund, or consumer-protection duties under current Korean law. Use Coupang’s official developer documentation for the platform operation and the Korean Law Information Center (law.go.kr) for current statute text when the question goes beyond the status code.

What should an integration validate?

It should require a verified factual trigger before sending either code: confirmed customer withdrawal for WITHDRAW, or genuine unavailability of the exchange item for SOLDOUT. A generic seller preference such as refund requested should remain a customer-service or return-workflow value, not an exchange-rejection reason.