쇼핑몰 주문 화면에는 배송 완료로 보이는데 고객은 한 상품만 반품했고, 창고는 입고를 확인했지만 환불 담당자는 아직 그 사실을 모를 수 있습니다. 반품 관리 시스템은 주문을 통째로 취소하는 화면이 아니라 주문 상품별 접수 수량, 실물 검사, 재고 처리, 결제 환불을 각각 기록하고 연결하는 방식으로 설계해야 합니다.

반품 접수 화면에서 먼저 확정할 것

고객은 주문번호로 구매 내역을 조회하고, 반품할 상품과 수량, 사유, 회수 방법을 선택합니다. 한 주문에 상품이 세 개 있어도 한 개만 접수할 수 있어야 합니다. 접수 화면에는 해당 상품의 주문 수량, 이미 환불 완료된 수량, 다른 접수 건에서 처리 중인 수량을 따로 보여줍니다. 같은 상품에 대한 중복 접수를 막는 데 필요한 숫자들입니다.

예를 들어 같은 상품을 3개 샀고 1개는 환불 완료, 1개는 이미 반품 심사 중이면 새로 신청 가능한 수량은 1개입니다. 아래 읽기 전용 SQL은 이 수량 계산을 작은 예시 데이터로 확인합니다. 실제 서비스에서는 주문 상품 ID별로 주문·진행 중인 반품·완료된 환불 수량을 집계하고, 두 상담원이 동시에 접수할 때의 중복도 저장 단계에서 막아야 합니다.

WITH item(order_qty, refunded_qty, pending_qty) AS (VALUES (3, 1, 1))
SELECT order_qty - refunded_qty - pending_qty AS requestable_qty FROM item;
-- 결과: 1

접수 가능 여부는 판매자의 실제 반품 기준과 주문 상태를 반영해야 합니다. 화면의 임의의 ‘7일 이내’ 같은 문구를 모든 상품에 일괄 적용하지 말고, 적용 기준의 버전과 판단 사유를 접수 건에 남기는 편이 좋습니다. 기준 밖 요청도 기록은 남기되 자동 승인하지 않고 담당자가 검토하도록 분리할 수 있습니다.

상담, 창고, 환불 담당자의 화면은 달라야 한다

접수 직후 상태는 ‘검토 대기’입니다. 상담 담당자는 주문 상품과 요청 수량을 확인하고 회수 안내를 보냅니다. 승인하면 ‘회수 대기’, 택배 접수 번호를 받으면 ‘회수 중’으로 넘어갑니다. 고객에게는 현재 상태와 다음 행동만 보이고, 내부 판단 메모는 공개되지 않아야 합니다.

창고 담당자는 운송장이나 반품 접수번호로 들어온 물품을 찾아 실제 입고 수량을 적습니다. 신청 2개 중 1개만 도착했다면 2개 모두 입고 처리하지 않습니다. 포장 훼손, 다른 상품 도착, 구성품 누락처럼 판정이 필요한 경우에는 사진과 검사 결과를 남겨 ‘검사 보류’로 돌립니다. 판매 가능 재고로 되돌릴지, 격리 재고로 둘지, 폐기할지는 환불 여부와 별도의 선택입니다.

검사가 끝나면 환불 담당자는 주문 상품별 결제 금액과 할인 배분, 배송비 조건, 이전 환불 이력을 함께 확인합니다. 예시 SQL의 ‘신청 가능 수량’에 상품 정가를 곱해서 곧바로 환불액을 확정하면 쿠폰이나 묶음 할인이 있는 주문에서 금액이 어긋날 수 있습니다. 환불 승인자와 실행자를 분리할지, 얼마부터 추가 승인을 받을지는 운영자가 정할 수 있게 두되 실제 기준을 화면에 표시해야 합니다.

결제 요청과 환불 완료를 같은 상태로 묶지 않는다

담당자가 ‘환불 요청’ 버튼을 눌렀다고 해서 고객에게 돈이 돌아간 것은 아닙니다. 결제 서비스에 전송한 요청 ID, 요청 금액(원), 응답 상태, 처리 시각을 저장하고 결제 서비스에서 최종 성공 상태를 확인한 뒤 ‘결제사 처리 완료’로 표시합니다. 고객 계좌나 카드 명세서에 반영됐다는 뜻은 아닙니다. 타임아웃이 났다면 무작정 다시 보내기 전에 동일 요청의 처리 결과를 조회해야 중복 환불 위험을 줄일 수 있습니다. 결제 수단에 따라 처리 가능 여부와 반영 시점이 다를 수 있으므로 고객 화면에는 확정되지 않은 시간을 단정하지 않습니다.

취소·반품·교환도 화면에서 구분합니다. 아직 출고되지 않은 주문 취소는 실물 회수가 없고, 배송 후 반품은 입고와 검사를 거칩니다. 교환은 새 상품의 재고 확보와 재출고가 붙습니다. 모든 경우를 주문 상태 ‘취소’ 하나로 저장하면 물류와 결제 이력을 다시 맞추기 어려워집니다.

구축 전에 정할 운영 기준

  • 누가 신청을 승인하고, 누가 실물 검사 결과를 확정하며, 누가 환불을 실행하는가?
  • 부분 입고나 검사 보류 중 고객에게 어떤 상태와 안내 문구를 보여줄 것인가?
  • 원 주문의 할인·배송비·결제 방식별 환불액을 어느 시스템에서 계산할 것인가?
  • 환불 실패와 중복 요청을 어느 화면에서 재조회하고 조치할 것인가?

처음부터 거대한 주문 관리 기능을 다시 만들 필요는 없습니다. 기존 쇼핑몰 주문번호와 상품 ID를 연결하고, 반품 접수번호를 중심으로 상태 변경 이력과 담당자·시각을 남기는 범위부터 정하면 됩니다. 보고 화면은 월별 접수 건수보다 ‘입고됐지만 검사하지 않은 건’, ‘승인됐지만 결제 환불이 끝나지 않은 건’을 먼저 찾을 수 있어야 실제 업무에 쓸모가 있습니다.

소프트모아의 서비스와 포트폴리오는 softmoa.com에서 확인할 수 있습니다.

소프트모아는 해당 시스템을 구축합니다. 문의하기