중개서비스는 왜 결제보다 정산이 먼저인가요?

핵심 요약

이 글을 읽고 나면 중개서비스 결제 연동 전에 반드시 챙겨야 할 돈의 흐름(정산 구조)을 설계하고, 지급대행 법적 리스크와 환불 시 정산 차감 정책을 사전에 확정할 수 있어요.
중개형 서비스(마켓플레이스)는 결제창을 띄우는 것보다 '받은 돈을 누구에게, 언제, 어떻게 나눠줄 것인가'라는 정산 구조를 먼저 확정해야 해요.
플랫폼이 정산 대금을 직접 보관하고 송금하는 방식은 현행법상 지급결제업 면허 없이는 불가능하므로, PG사의 '분리 정산' 기능을 활용하는 설계가 필수예요.
환불 발생 시 이미 정산된 금액을 판매자에게 어떻게 차감할지(정산 상계) 정책을 미리 세우지 않으면, 플랫폼이 판매자 대신 환불금을 떠안는 재무 리스크가 발생해요.
돈의 흐름도(Money Flow)를 먼저 그려야 주문 테이블의 컬럼 설계와 관리자 화면(Admin)의 상태 값이 꼬이지 않아요.

이런 상황이라면

오픈마켓 형태의 서비스를 준비하는 3인 팀 PM이 있어요. 입점사들이 상품을 올리고 고객이 결제하는 기능까지는 순조롭게 개발됐어요. 하지만 런칭을 일주일 앞두고 정산 담당자가 질문을 던져요. "고객이 결제한 돈이 우리 통장으로 들어오나? 아니면 판매자한테 바로 가나? 환불해주면 판매자 정산금에서 자동으로 빠지나?"
PM은 당황해요. 결제창 SDK 연동만 신경 썼지, 돈이 나가는 길은 설계하지 않았기 때문이에요. 부랴부랴 PG사에 문의하니 "직접 돈을 나눠주시면 불법 소지가 있어요"라는 답변이 돌아와요. 결국 결제 로직을 다시 뜯어고치느라 오픈 일정이 한 달 뒤로 밀려요.

중개서비스에서 결제 버튼 이전에 그려야 할 돈의 흐름과 정산 설계 포인트를 정리해요.

1결제 버튼보다 먼저 그려야 할 돈의 지도 (Money Flow)

기획자가 돈의 흐름도를 먼저 그려야 주문 테이블의 컬럼 설계가 꼬이지 않고 자동 정산의 기반을 닦을 수 있어요. 중개서비스에서 결제는 '돈이 모이는 지점'일 뿐이에요. 진짜 기획은 그 돈이 흩어지는 '정산'에서 시작돼요. 이를 무시하고 결제부터 붙이면 나중에 DB 구조를 통째로 바꿔야 해요. 아래는 가장 표준적인 분리 정산 모델의 흐름이에요.

이 흐름이 확정되어야 주문 테이블에 판매자 ID, 공급가, 수수료, 정산 예정일 같은 컬럼을 설계할 수 있어요. 이 구조 없이 결제만 받으면, 나중에 엑셀로 일일이 판매자별 금액을 계산해야 하는 '수동 정산의 지옥'에 빠지게 돼요.

2정산 병목을 막는 역할 분장

정산 프로세스를 설계할 때 먼저 결정할 정책과 개발자가 구현할 로직을 명확히 나누어야 런칭 직전의 혼선을 방지해요.

1단계: 정산 기초 데이터 설계

기획자는 판매자별 수수료율(카테고리별 차등 여부 포함)과 정산 주기(D+N일)를 확정해요.
개발자는 주문 발생 시 해당 시점의 수수료율과 정산 예정일을 스냅샷 형태로 주문 테이블에 기록해요. 나중에 수수료율이 변해도 과거 주문에 영향을 주지 않기 위함이에요.

2단계: 상태 전이 설계

기획자는 결제 완료 → 배송 중 → 구매 확정 → 정산 대기 → 정산 완료로 이어지는 상태 값을 정의해요. 특히 '구매 확정'이 정산의 트리거가 됨을 명시해요.
개발자는 구매 확정 이벤트 발생 시 정산 대기 테이블로 데이터를 이관하거나 정산 상태를 업데이트하는 로직을 구현해요.

3단계: 정산 실행 및 검증

기획자는 관리자 화면에서 정산 대상을 확인하고 승인하거나, 자동으로 실행될 조건을 확정해요.
개발자는 PG사 분리 정산 API를 호출하여 실제로 돈이 입금되도록 연동해요.

3플랫폼의 재무 손실을 막는 사후 환불 차감 정책

이미 정산이 끝난 뒤 발생하는 환불에 대해 '정산 상계(Offsetting)' 정책을 미리 세워야 플랫폼이 판매자의 환불금을 대신 떠안는 리스크를 피해요. 중개서비스 기획에서 가장 많이 놓치는 지점이 '이미 정산이 끝난 뒤에 들어온 환불 요청'이에요. 한 디지털 굿즈 중개 서비스는 이 정책이 없어 판매자에게 이미 정산된 금액을 돌려받지 못해 수천만 원의 손실을 보기도 했어요.

취소와 환불의 책임 소재

카드 결제 취소: PG 전산에서 승인 취소되므로 돈이 판매자에게 가기 전이라면 문제가 없어요. 카드로 인한 되돌림은 '취소'예요.
가상계좌 입금 후 환불: 이미 플랫폼이나 판매자에게 돈이 넘어간 상태예요. 이때 고객 계좌로 돈을 돌려주는 주체가 누구인지 명확히 해야 해요. 입금 후의 되돌림은 '환불'이에요.

정산 상계(Offsetting) 정책

이미 판매자에게 판매 대금을 정산해줬는데 고객이 환불을 요청하면, 플랫폼은 다음 정산 주기에서 그 금액만큼을 차감(상계)하고 지급해야 해요.

정책 초안: "반품 완료 시 정산 대기 금액에서 차감해요. 대기 금액이 부족할 경우 판매자가 직접 플랫폼 계좌로 환불금을 입금해야 환불이 완료돼요." 이런 정책이 기획 단계에서 확정되지 않으면 재무 팀은 매달 판매자들과 입금 전쟁을 치러야 해요.

4법적 리스크를 피하고 운영 효율을 높이는 PG 분리 정산

플랫폼이 직접 돈을 보관하고 송금하는 방식의 법적 위험을 파악하고, PG사의 분리 정산 기능을 활용해 정산 업무의 80%를 자동화해요. 플랫폼이 고객 돈을 자기 통장에 받았다가 판매자에게 직접 송금해주는 방식은 가장 직관적이지만 가장 위험해요.

직접 송금의 리스크

현행법상 PG 면허 없이 타인의 자금을 보관하고 전달하는 행위는 '지급결제업' 위반 소지가 있어요. 또한, 이커머스에서는 고객이 물건을 받기 전까지 돈을 보호하는 '에스크로(Escrow)' 의무가 있어요. 직접 송금 구조에서는 에스크로 확인증 발급이 어려워요.

해결책: PG사 분리 정산 활용

PG사의 분리 정산 서비스를 사용해요. PG사가 결제 대금을 들고 있다가, 플랫폼이 정한 수수료를 떼고 판매자에게 직접 정산해주는 방식이에요.

장점: 플랫폼은 정산 업무의 80%를 자동화할 수 있고 법적 리스크도 사라져요. 에스크로 확인증 역시 PG사에서 발급하므로 기획자가 별도로 준비할 필요가 없어요.

5팀 합의를 끌어내기 위한 최종 정산 설계 체크리스트

설계한 정산 흐름이 실무에서 작동하는지 확인하기 위해 아래 리스트를 활용해 기획자와 개발자의 최종 점검을 마쳐요.

정책 체크리스트

PG사의 분리 정산(또는 지급 대행) 기능을 사용할 것인가?
이용약관에 플랫폼과 판매자 간의 정산 주기 및 수수료 기준이 명시되어 있는가?
판매자용 정산 리포트(매출, 수수료, 정산 금액) 화면을 설계했는가?
정산 완료 후 환불 발생 시 '차감 정산' 로직을 재무 팀과 합의했는가?

구현 체크리스트

주문 테이블에 판매자별 정산 기초 데이터(공급가, 수수료율)가 포함되었는가?
PG사로부터 정산 결과 데이터를 수신할 웹훅(Webhook) 또는 API가 준비되었는가?
결제 취소/환불 시 정산 상태 값이 자동으로 업데이트되도록 설계했는가?
가상계좌 입금 확인 시 에스크로 상태와 정산 스케줄이 연동되는가?

다음 단계

돈의 흐름을 그렸다면, 다음은 정산 모델 선택과 결제 완료 기준을 같이 맞춰 실제 운영으로 내려야 해요.

실제 연동할 때

돈의 흐름 설계가 끝났다면 코드는 다음에서 시작해요.

주문 이해하기 — 주문 라이프사이클과 정산 시점
주문 아키텍처 — OrderPre · Order · OrderPurchase 3단 구조 배경
B2B 마켓플레이스 이해하기 — 중개형 정산을 다룰 때의 그룹 모델

바로 참고할 문서

더 복잡한 판단이 필요하다면: 부트페이 도입 문의