2024년 티몬·위메프의 판매대금 미정산 사태는 마켓플레이스에서 화면과 주문 기능만큼 정산 구조가 중요하다는 사실을 보여줬습니다.
사건 직후에는 환불과 플랫폼별 정산 주기가 문제였고, 시간이 지나 정책과 플랫폼 조건이 바뀌었습니다. 지금은 카드사·PG사·마켓플레이스 사이의 자금 흐름까지 함께 봐야 합니다.
이 글은 개별 회사의 현재 상태를 예측하지 않습니다. 마켓플레이스를 새로 만들거나 입점할 때 계약서와 시스템에서 확인할 항목을 정리합니다.
- 결제와 정산의 주체
- 판매대금 관리 방식
- 구매확정과 환불 상태
- 판매자별 정산 원장
- 장애와 부도 상황의 대응 절차
법률과 플랫폼 정책은 계약 전에 다시 확인해야 합니다.
쇼핑몰과 마켓플레이스의 돈 흐름은 다르다
자사몰은 일반적으로 한 사업자가 자신의 상품을 판매합니다. 마켓플레이스는 플랫폼 안에서 여러 판매자가 거래하고, 플랫폼이 주문·결제·정산 과정의 일부를 운영합니다.
마켓플레이스의 결제에는 소비자, 판매자, 플랫폼, 카드사, 전자지급결제대행사(PG사)가 관여할 수 있습니다. 계약 구조에 따라 역할과 책임은 달라집니다. 결제 승인이 났다고 판매대금이 특정 회사 계좌에 그대로 예치돼 있다고 단정할 수 없고, PG사가 환불 책임을 항상 대신 지는 것도 아닙니다.
그래서 시스템을 설계하기 전에 다음 계약을 먼저 확인해야 합니다.
- 소비자에게 상품을 판매하는 주체가 누구인가
- PG사와 직접 계약하는 당사자가 누구인가
- 판매대금을 누가 수령하고 관리하는가
- 판매자에게 언제 어떤 조건으로 지급하는가
- 취소·부분환불·차지백 비용을 누가 부담하는가
주문 상태와 자금 상태를 분리한다
주문 화면에는 결제완료, 배송중, 구매확정 같은 상태가 표시됩니다. 정산 시스템에는 이보다 더 많은 자금 상태가 필요합니다.
예를 들어 한 주문이 결제 완료됐더라도 판매자에게 지급할 수 있는 금액은 다음 사유로 달라질 수 있습니다.
- 쿠폰과 포인트 분담
- 플랫폼 수수료와 부가세
- 배송비와 추가 옵션
- 부분 취소
- 반품과 교환
- 분쟁 또는 지급 보류
- 이전 정산의 조정 금액
주문 테이블의 최종 금액만 보고 판매자 정산액을 계산하면 과거 금액이 바뀌거나 근거를 추적하기 어렵습니다. 주문 상태와 별도로 판매자별 정산 원장을 두는 편이 안전합니다.
판매자 정산 원장에 필요한 정보
정산 원장은 돈이 늘고 줄어든 이유를 거래 단위로 남깁니다. 최소한 다음 항목을 추적할 수 있어야 합니다.
- 주문과 주문 항목
- 판매자와 계약 조건
- 결제 승인·취소 식별자
- 판매금액, 할인, 배송비와 수수료
- 정산 가능일
- 지급 보류 사유
- 실제 지급일과 지급 계좌
- 조정 금액과 변경한 담당자
정산 결과만 덮어쓰지 말고 변경 이력을 남겨야 합니다. 특정 주문의 금액이 왜 달라졌는지 소비자 환불, 판매자 정산, 회계 자료에서 같은 근거로 설명할 수 있어야 합니다.
정산 주기는 숫자 하나가 아니다
구매확정 후 7일처럼 기간만 적으면 실제 지급일을 계산하기 어렵습니다. 다음 기준을 함께 정의해야 합니다.
- 시작 시점이 결제일, 배송완료일, 구매확정일 중 무엇인가
- 주말과 공휴일을 어떻게 계산하는가
- 반품 가능 기간 동안 지급을 보류하는가
- 부분 취소가 생기면 해당 주문 전체를 보류하는가
- 최소 지급금액이 있는가
- 판매자 위험도나 상품 유형에 따라 주기가 달라지는가
- 플랫폼 장애나 금융기관 장애가 생기면 어떻게 공지하는가
정산 주기가 짧으면 판매자 현금 흐름에는 유리하지만, 환불과 분쟁이 생겼을 때 플랫폼이 회수해야 할 위험이 커집니다. 반대로 지나치게 긴 주기는 판매자가 플랫폼의 신용위험을 부담하게 합니다. 기간은 경쟁 요소인 동시에 위험 배분 조건입니다.
판매대금은 운영자금과 구분해 관리한다
티메프 사태 뒤 정부는 온라인 중개거래의 정산기한과 판매대금 관리 강화를 위한 제도개선 방향을 발표했습니다. 대한민국 정책브리핑의 티메프 재발방지 법률 개정안 설명에는 일정 규모 이상의 온라인 중개 플랫폼에 정산기한을 두고, 판매대금을 직접 관리할 때 일부를 금융기관에 별도 관리하거나 지급보증보험을 이용하는 방안이 담겼습니다.
다만 발표된 개정안, 국회 의결, 공포와 시행은 서로 다른 단계입니다. 실제 서비스를 준비할 때는 현행 국가법령정보센터와 법률 전문가를 통해 적용 대상과 시행일을 확인해야 합니다.
시스템에서는 법적 최소 조건만 기다리기보다 다음 통제를 먼저 설계할 수 있습니다.
- 판매대금과 회사 운영자금의 계정·계좌 구분
- 출금 권한 분리와 이중 승인
- 일별 정산 예정액과 가용자금 대사
- 정산 지연 자동 경고
- 판매자가 자신의 미정산 내역을 내려받는 기능
- 관리자 수동 조정의 사유와 감사로그
환불은 버튼 하나로 끝나지 않는다
결제 취소 요청이 승인되려면 주문과 자금 상태, PG 계약, 카드사 처리 조건이 맞아야 합니다. 이미 판매자 정산이 끝난 뒤 환불이 발생하면 다음 정산에서 차감하거나 별도 회수 절차가 필요할 수 있습니다.
2024년 당시 정부는 피해 소비자가 카드사와 PG사를 통해 결제 취소·환불 절차를 신청할 수 있도록 지원했습니다. 이는 위기 대응을 위해 관계 기관과 사업자가 협조한 절차였습니다. 모든 마켓플레이스 거래에서 PG사가 소비자에게 자동 환불해 준다는 일반 규칙으로 해석하면 안 됩니다. 당시 대응은 금융위원회 발표에서 확인할 수 있습니다.
마켓플레이스 환불 기능에는 다음 경우를 테스트해야 합니다.
- 전체 취소와 일부 품목 취소
- 쿠폰·포인트를 사용한 주문
- 여러 판매자의 상품을 한 번에 결제한 주문
- 배송비만 환불하거나 추가 청구하는 경우
- 판매자 정산 전과 정산 후의 환불
- PG 취소 실패와 재시도
- 계좌이체·가상계좌·간편결제처럼 수단이 다른 경우
관리자 화면에서 꼭 보여야 할 것
정산 시스템은 배치 작업만 있다고 끝나지 않습니다. 운영자가 이상을 발견하고 멈출 수 있어야 합니다.
일별 대사
PG 승인·취소 내역, 주문 원장, 판매자 정산 원장, 실제 은행 지급액을 비교합니다. 합계가 맞지 않으면 차이가 난 주문을 찾을 수 있어야 합니다.
지급 예정과 보류
판매자별 지급 예정액과 날짜, 보류 사유를 보여줍니다. 운영자가 보류를 해제할 때 권한과 기록을 남깁니다.
위험 경고
예정된 정산액보다 가용자금이 부족하거나 취소율이 갑자기 높아지면 알립니다. 경고만 만들지 말고 신규 출금 중지, 관리자 승인 같은 대응 절차를 연결해야 합니다.
판매자 명세서
판매자가 주문별 판매금액, 수수료, 할인 분담, 환불과 최종 지급액을 확인할 수 있어야 합니다. 엑셀 한 장의 합계보다 거래 단위 명세가 분쟁을 줄입니다.
발주 전에 확인할 체크리스트
마켓플레이스를 개발하거나 솔루션을 도입할 때 다음 질문에 답할 수 있어야 합니다.
- 통신판매의 당사자와 PG 계약자는 누구인가
- 판매대금은 어느 계좌와 원장에 기록되는가
- 정산 가능일과 실제 지급일은 어떻게 계산하는가
- 환불·차지백·분쟁이 생기면 누가 비용을 부담하는가
- 판매자별 계약과 수수료 변경 이력을 보관하는가
- 주문·PG·정산·은행 내역을 어떻게 대사하는가
- 수동 조정과 출금 권한을 누가 갖는가
- 플랫폼 운영이 중단될 때 판매자와 소비자가 자료를 받을 수 있는가
- 현행 법률의 적용 대상과 시행일을 누가 검토하는가
이 질문에 답하지 못한 상태에서 상품 등록과 주문 화면부터 만들면, 나중에 정산 구조를 바꿀 때 주문 데이터 전체를 다시 해석해야 할 수 있습니다.
마켓플레이스의 신뢰는 정산 데이터에서 시작한다
빠른 정산 문구만으로 판매자의 신뢰를 얻기는 어렵습니다. 판매자는 자신의 돈이 언제 지급되는지, 왜 금액이 바뀌었는지, 문제가 생겼을 때 어떤 절차가 작동하는지 알아야 합니다.
마켓플레이스를 준비한다면 결제 화면보다 먼저 계약 당사자, 자금 관리, 정산 원장과 환불 흐름을 정해야 합니다. 정책이 바뀌더라도 원장과 권한 구조가 분리돼 있으면 적용 범위를 찾기 쉽습니다.
쇼핑몰과 마켓플레이스의 기술 선택은 가성비를 기준으로 쇼핑몰 기술 선택하기에서 이어서 볼 수 있습니다.
판매자 정산, 결제와 환불 흐름까지 포함한 마켓플레이스 구축 범위를 검토하려면 프로젝트 문의에 거래 구조와 예상 판매자 수를 알려주세요. 화면 기능과 정산·운영 기능을 나눠 검토해 답하겠습니다.