부분 취소가 정산을 망가뜨리는 이유 — 할인 부담 주체와 역산

문제 상황

고객이 3만원짜리 상품 3개를 담고, 5천원 쿠폰을 쓰고, 배송비 3천원을 더해 8만8천원을 결제했습니다. 그리고 하나만 반품합니다.

얼마를 환불해야 할까요? 그리고 공급자에게는 얼마를 정산해야 할까요? 이 질문에 회사마다 다른 답을 내놓고, 대부분은 규칙이 문서로 없습니다.

왜 단순 차감이 틀리는가

가장 흔한 처리는 "상품가 3만원을 그냥 빼는 것"입니다. 그 순간엔 숫자가 맞아 보입니다. 하지만 두 가지가 어긋납니다.

• ▸쿠폰 5천원이 3개에 걸쳐 있었는데, 1개를 빼면서 쿠폰은 그대로 두면 남은 2개에 5천원 할인이 전부 적용된 셈이 됩니다. 고객이 이득을 봅니다.
• ▸그 쿠폰을 플랫폼이 부담했다면, 공급자 정산액은 원래대로 유지되어야 합니다. 그런데 할인 후 금액 기준으로 정산하고 있었다면 공급자 몫이 틀어집니다.

핵심은 "부담 주체"

할인은 누군가의 돈으로 나갑니다. 플랫폼이 마케팅 비용으로 부담할 수도 있고, 공급자가 자기 마진을 깎아 부담할 수도 있고, 제휴 프로모션 예산에서 나올 수도 있습니다.

이걸 주문 시점에 기록해두지 않으면 취소 시점에 복원할 방법이 없습니다. 그래서 할인은 "금액"이 아니라 "금액 + 부담 주체 + 배분 기준"으로 저장해야 합니다.

역산이 가능한 구조란

정산 원장을 "최종 금액" 하나로 두면 역산이 불가능합니다. 취소가 발생했을 때 무엇을 얼마나 되돌려야 하는지 계산할 근거가 없기 때문입니다.

항목을 쪼개서 남겨야 합니다. 상품가, 할인(부담 주체별), 배송비, 수수료, 부가세가 각각 별도 라인으로 있어야 하고, 각 라인이 어느 주문 항목에 속하는지 연결되어 있어야 합니다.

• ▸주문 항목 단위로 금액 라인을 남긴다 — 주문 전체 합계만 남기면 부분 취소를 계산할 수 없습니다.
• ▸환불은 차감이 아니라 반대 부호의 새 라인으로 기록한다 — 기존 라인을 수정하면 이력이 사라집니다.
• ▸조정(adjustment)은 별도 원장으로 남긴다 — 왜 이 금액이 됐는지 설명할 수 있어야 합니다.

착수 전에 정해야 할 것

개발이 절반 지난 뒤에 이 규칙을 바꾸면, 바꾸는 비용이 처음부터 만드는 비용보다 큽니다. 주문 데이터 구조 자체가 달라지기 때문입니다.

그래서 아래 항목들은 요구사항 정리 단계에서 답을 받아야 합니다.

• ▸부분 취소를 허용하는가
• ▸쿠폰·할인의 부담 주체를 무엇으로 구분하는가
• ▸배송비는 부분 취소 시 어떻게 처리하는가 (전액 유지 / 비례 배분 / 무료배송 조건 재계산)
• ▸정산 완료 후 환불이 발생하면 다음 달 차감인가 즉시 회수인가
• ▸과세·면세가 섞인 주문의 부가세를 어떻게 분리하는가

정리

부분 취소는 기능이 아니라 데이터 구조의 문제입니다. "취소 버튼을 만든다"가 아니라 "취소됐을 때 되돌릴 수 있는 형태로 처음부터 쌓는다"가 맞는 접근입니다.

이걸 안 하면 오픈 두세 달 뒤부터 정산이 조금씩 어긋나기 시작하고, 그때는 이미 데이터가 그 형태로 쌓여 있어 되돌릴 수 없습니다.