정산도 직접 해주나요?

핵심 요약

플랫폼 정산의 본질은 단순한 송금이 아니라 '누가 자금의 주도권을 갖는가'와 '누가 법적 책임을 지는가'를 결정하는 설계 작업이에요.
모델 선택의 1순위 기준은 전자금융거래법상 자금 보관 리스크예요. 면허가 없는 중개 플랫폼이 고객 돈을 자기 계좌에 두는 행위는 불법 소지가 크므로 반드시 분리정산이나 에스크로 구조를 우선 검토해야 해요.
초기 팀이라면 직접 정산의 운영 부하를 과소평가해서는 안 돼요. 월 거래 100건만 넘어가도 환불 차감, 수수료 계산, 세금계산서 발행 등에 매달 최소 8시간 이상의 수기 작업이 발생하므로 정산 자동화를 전제로 설계해야 해요.

1우리 서비스에 맞는 정산 모델 선택 가이드

플랫폼 정산은 단순히 돈을 전달하는 과정이 아니라, 서비스의 법적 지위와 운영 효율을 결정하는 설계 작업이에요. 아래 3가지 모델 중 우리 팀의 현재 역량과 서비스 성격에 맞는 것을 골라야 해요.

모델 1: 수취 후 지급 (직접 정산)

플랫폼이 결제 대금을 전부 자기 계좌로 받아서 수수료를 떼고 판매자에게 직접 송금하는 방식이에요.

돈의 흐름

상세 설명: 플랫폼이 자금을 직접 핸들링하므로 자금 운용의 유연성이 가장 높아요. 정산 주기를 플랫폼 마음대로(예: 익일 정산, 월 단위 정산) 정할 수 있고, 판매자와의 계약 조건에 따라 정산일을 다르게 가져가기도 쉬워요.
리스크: 가장 큰 문제는 전자금융거래법상 '자금 보관 리스크'예요. 결제 대행 면허가 없는 플랫폼이 남의 돈을 보관하고 있다가 전달하는 행위는 법적 제재 대상이 될 수 있어요. 또한 정산 담당자분이 매일 입금 내역을 확인하고 수백 명의 판매자 계좌로 일일이 송금해야 하는 운영 부하가 매우 커요.

모델 2: 분리정산 (PG 대행 정산)

PG사가 결제 시점에 수수료를 제외한 금액을 플랫폼(수수료)과 판매자(상품 대금)에게 각각 나누어 입금해주는 방식이에요.

돈의 흐름

상세 설명: 플랫폼 계좌를 거치지 않고 PG사가 돈을 쪼개서 보내줘요. 플랫폼 입장에서는 자금 보관 리스크에서 완전히 자유로워져요. 정산 시스템을 직접 만들 필요가 없으므로 개발 공수와 운영 인력이 거의 들지 않아요.
하위 가맹점 등록 절차: 분리정산을 쓰려면 각 판매자가 PG사의 '하위 가맹점'으로 등록되어야 해요. 플랫폼이 판매자로부터 사업자등록증, 통장사본 등 서류를 받아 PG사에 제출하고 심사를 받는 과정이 필요해요. 판매자 수가 많으면 이 등록 절차 자체가 운영 부담이 될 수 있으므로, 판매자 온보딩 프로세스를 미리 설계해둬야 해요.
정산 주기 제약: PG사 시스템의 정산 주기(보통 D+N일 또는 주 단위)를 따르게 돼요. 판매자별로 정산 주기를 다르게 가져가거나 실시간 정산을 하고 싶다면 분리정산만으로는 한계가 있어요.

모델 3: 에스크로 (안전거래)

구매자가 물건을 받고 '구매 확정'을 해야만 결제 대금이 판매자에게 지급되는 구조예요.

돈의 흐름

상세 설명: 결제 대금을 제3의 신뢰할 수 있는 기관이 보관해요. 중고거래나 고단가의 커스텀 제작 서비스처럼 구매자와 판매자 간의 불신이 존재할 수 있는 도메인에서 필수적이에요.
단점: 판매자 입장에서는 정산 주기가 구매 확정 시점에 묶이므로 자금 회전이 늦어질 수 있어요. 플랫폼은 구매 확정 프로세스를 UI/UX적으로 꼼꼼하게 설계해야 정산 민원을 줄일 수 있어요.
에스크로 확인증: PG 계약 과정에서 에스크로 확인증이 필요할 수 있는데, 이는 가맹점이 별도 기관에서 발급받는 것이 아니라 PG사가 발급해줘요.

2모델별 비교표 및 규모별 선택 기준

3대 정산 모델 비교

비교 항목	수취 후 지급 (직접)	분리정산 (PG 대행)	에스크로 (안전)
자금 주도권	매우 높음 (플랫폼 통제)	낮음 (PG사 통제)	중간 (구매자 통제)
법적 리스크	높음 (전금법 위반 소지)	매우 낮음 (안전)	매우 낮음 (안전)
운영 인력	많이 필요 (수기 송금)	거의 없음 (자동)	중간 (구매확정 관리)
구축 난이도	높음 (시스템 구축 필요)	낮음 (API 연동)	중간 (프로세스 설계)
판매자 등록	플랫폼 자체 관리	PG사 심사 필요	PG사 심사 필요

거래 규모별 추천 분기

이론적인 비교보다 중요한 것은 '지금 우리 팀이 감당 가능한가'예요.

월 거래 100건 미만 (추천: 분리정산): 정산 업무를 위해 별도 인력을 뽑기에는 규모가 작아요. 직접 정산을 하면 송금 수수료와 엑셀 작업 시간에 더 많은 기회비용을 쓰게 돼요. 법적 리스크를 안고 갈 이유가 전혀 없는 구간이에요.
월 100 ~ 1,000건 (추천: 분리정산 + 자동화): 정산 오류가 발생하기 시작하는 구간이에요. 엑셀 수식이 한 줄만 틀려도 판매자 정산액이 꼬이고, 이는 곧 서비스 신뢰도로 이어져요. 정산 담당자분이 매달 최소 8시간 이상을 엑셀과 입금 확인에 쓰게 되는데, 이 비용을 기술로 해결하는 편이 훨씬 효율적이에요.
월 1,000건 이상 (추천: 직접 정산 시스템 구축): 수수료 수익 최적화와 자금 운용의 필요성이 생겨요. 이 단계에서는 전담 정산 담당자분이 있어야 하며, PG사와 협의하여 정산 대행 구조를 고도화하거나 직접 결제 대행 면허(PG 면허) 취득을 검토해야 해요.

3서비스 유형별 정산 시나리오

배달 및 퀵서비스 플랫폼

주문 건수가 많고 단가가 낮아요. 건당 송금 수수료(보통 500원)가 정산 수익보다 커질 수 있어요. 따라서 플랫폼 계좌로 모아서 보내는 직접 정산보다는, PG사의 분리정산 기능을 활용해 시스템적으로 자동 입금되도록 설계하는 것이 운영 효율 면에서 유리해요.

배달 플랫폼은 취소 비율도 높아요. 조리 시작 전 취소, 배달 중 취소, 수령 후 불만 등 단계별로 취소/환불 기준이 달라야 해요. 이걸 정산 로직에 반영하지 않으면, 판매자와 배달 기사분 양쪽에서 정산 민원이 쏟아져요.

추천 구조: 분리정산 — 건수가 많을수록 자동화가 필수예요.

클래스 및 레슨 마켓

판매자(강사)가 법인이 아닌 개인인 경우가 많아요. 이 경우 플랫폼은 정산 시 3.3% 사업소득세를 떼는 원천징수 의무를 지게 돼요. 정산액 산정 로직에 세금 차감 계산식이 반드시 들어가야 하며, 매달 국세청 신고를 위한 데이터를 추출할 수 있어야 해요.

또 하나 빠뜨리기 쉬운 것은 노쇼(no-show)와 수업 취소 처리예요. 강사가 수업을 취소하면 고객에게 전액 환불해야 하고, 고객이 노쇼하면 강사에게 정산해야 해요. 이 양방향 취소/환불 기준을 약관에 명시하지 않으면 CS 부담이 급격히 늘어나요.

추천 구조: 분리정산 + 원천징수 자동화 — 세무 리스크를 시스템으로 잡아야 해요.

크라우드펀딩

결제(펀딩)와 지급(프로젝트 종료) 사이의 시차가 짧게는 한 달, 길게는 수개월까지 벌어져요. 자금 보관 리스크가 가장 큰 업종이에요. 플랫폼이 직접 돈을 들고 있으면 사고 위험이 크므로, 반드시 에스크로 구조를 도입하거나 PG사의 예약 정산 기능을 활용해야 해요.

크라우드펀딩은 일부 PG사에서 고위험 업종으로 분류해요. 금융위 등록 여부를 먼저 확인하고, 취급 가능한 PG사를 골라야 해요. 프로젝트 실패 시 전액 환불 처리를 어떻게 할지도 미리 정해둬야 해요.

추천 구조: 에스크로 — 자금 보관 기간이 긴 만큼 법적으로 가장 안전한 구조가 필수예요.

중고거래 플랫폼

개인 간 거래가 주를 이루며 사기 거래 리스크가 핵심이에요. 정산 모델 자체보다는 에스크로(안전거래)가 비즈니스의 핵심 신뢰 장치가 돼요. 구매자가 '구매 확정' 버튼을 누르기 전까지는 절대 판매자에게 돈이 가지 않도록 프로세스를 강제해야 해요.

판매자가 거의 전원 개인이므로 원천징수 의무도 따라와요. 다만 건당 금액이 작고 거래 빈도가 낮은 판매자가 많다면, 일정 금액 이하 소액 정산을 모아서 처리하는 방식도 검토할 수 있어요. 이 경우에도 세무 전문가의 확인이 필요해요.

추천 구조: 에스크로 — 신뢰가 거래의 전제 조건인 도메인이에요.

유형별 빠른 판단

서비스 유형	추천 모델	핵심 고려 사항
배달/퀵서비스	분리정산	건수 많고 단가 낮음, 자동화 필수
클래스/레슨	분리정산 + 원천징수	개인 강사 세무 처리
크라우드펀딩	에스크로	장기 자금 보관, 고위험 업종
중고거래	에스크로	사기 방지, 개인 간 신뢰
직매입 이커머스	수취 후 지급	자금 통제 필요, 면허 전제

4정산 설계 시 놓치면 2주 밀리는 삽질 포인트

기획자가 정산 로직을 짤 때 개발자분과 미리 합의하지 않으면, 나중에 데이터가 꼬여서 전체 정산을 수동으로 검증해야 하는 상황이 발생해요.

1) '취소'와 '환불' 발생 시 정산금 차감 정책

카드 결제는 시스템적으로 취소가 되지만, 이미 정산이 완료된 후에 고객이 반품을 요청하면 플랫폼은 판매자에게 줄 다음 정산금에서 그만큼을 차감해야 해요.

발생 원인: 보통 정산 주기는 '배송 완료 후 1일'인데, 반품 가능 기간은 '배송 완료 후 7일'이기 때문에 발생해요. 이미 판매자 지갑으로 돈이 들어갔는데 물건이 돌아오는 경우예요.
구체적 수치 예시:
1. 3월 15일: 고객이 10,000원 결제
2. 3월 17일: 정산 완료 (판매자에게 9,000원 입금, 플랫폼 수수료 1,000원)
3. 3월 20일: 고객이 단순 변심으로 반품 요청
4. 3월 21일: 카드 결제 취소 완료 (고객은 10,000원 돌려받음)
5. 3월 말 정산: 판매자의 다른 매출 20,000원에서 이전 취소분 9,000원을 차감하고 11,000원만 정산.
해결안: 화면 기획 단계에서 정산 대상 금액 = (구매 확정 건 합계) - (기 정산 건 중 당기 취소/환불액)이라는 로직을 명시하고, 마이너스 정산이 발생할 경우 다음 달로 이월할지 판매자에게 직접 청구할지도 정해야 해요.

2) 세금계산서 발행 주체와 원천징수

중개 플랫폼은 전체 결제 금액이 아니라 플랫폼이 가져가는 수수료에 대해서만 판매자에게 세금계산서를 발행해요.

올바른 기준: 10,000원 결제 시 수수료가 1,000원이라면, 플랫폼은 1,000원에 대한 증빙만 책임져요. 나머지 9,000원에 대한 증빙은 판매자가 고객에게 직접(또는 PG사 영수증으로) 처리하도록 약관에 명시해야 해요.
원천징수 의무: 판매자가 개인(비사업자)이라면 플랫폼이 정산 시 3.3%를 떼고 지급해야 해요. "우리는 중개만 하니까 판매자가 알아서 세금 내겠지"라고 생각했다가 나중에 플랫폼이 가산세 폭탄을 맞는 경우가 많아요. 개인 판매자가 포함된다면 반드시 세무 전문가와 원천징수 프로세스를 협의해야 해요.

3) 하위 가맹점 등록 절차를 과소평가하는 경우

분리정산을 선택한 플랫폼이 가장 많이 당하는 삽질이에요. 분리정산 자체는 빠르게 연동할 수 있지만, 각 판매자를 PG사 하위 가맹점으로 등록하는 과정에서 병목이 생겨요.

원인: 판매자에게 사업자등록증, 통장사본, 대표자 신분증 등을 수집해야 하는데, 판매자가 서류를 늦게 제출하거나 이름 불일치, 계좌 오류 등으로 반려가 반복돼요.
실제 소요 시간: 판매자 1명 등록에 빠르면 2~3일, 서류 보완이 있으면 1~2주. 판매자 20명을 동시에 등록하면 전체 일정이 가장 늦은 판매자에 맞춰져요.
예방법: 판매자 온보딩 단계에서 '정산 등록 가이드'를 미리 제공하고, 서류 수집을 자동화하는 폼을 만들어두면 보완 왕복을 줄일 수 있어요. 최소 2주 전에 서류 수집을 시작해야 오픈 일정에 맞출 수 있어요.

5정산 정책 설계 템플릿 (빈칸 채우기)

담당자는 아래 항목을 채워서 개발팀 및 법무/세무 담당자분과 논의를 시작하면 돼요.

선택한 정산 모델: (예: 분리정산 / 직접 정산 / 에스크로)
정산 대상 확정 기준: (예: 배송 완료 시점 / 구매 확정 시점 / 결제 완료 시점)
정산 주기: (예: 매주 금요일 / 익일 정산 / 월 1회 말일 정산)
기본 수수료율: (예: 카테고리 무관 10% / 카테고리별 차등 적용)
취소/환불 차감 방식: (예: 다음 정산금에서 자동 차감 / 별도 가상계좌 입금 요청)
증빙 발행: (예: 수수료에 대해서만 플랫폼이 역발행 / 판매자가 직접 발행)

[체크리스트] 정산 도입 전 최종 점검

팀 안에서 이 리스트를 복사해 담당자를 지정하고 점검해요.

정책 체크리스트

우리 서비스 업종이 직접 자금을 보관해도 법적으로 문제가 없는지 확인했는가? (변호사/세무사 자문 필수)
판매자에게 적용할 수수료율이 상품 카테고리별 또는 판매자 등급별로 확정되었는가?
이용약관에 정산 주기와 환불 시 차감 기준(마이너스 정산 처리)이 명시되어 있는가?
판매자가 개인일 경우, 원천징수(3.3%)를 누가 어떻게 신고할지 프로세스를 정했는가?
플랫폼이 발행하는 세금계산서의 범위가 '전체 금액'이 아닌 '수수료'로 한정되어 있는가?

구현 체크리스트

PG사로부터 분리정산(하위 가맹점 정산) API 권한을 부여받았는가?
정산 데이터 생성을 위한 '구매 확정' 또는 '정산 확정' 상태값이 DB에 정의되었는가?
취소/환불 발생 시 해당 주문의 정산 상태를 '차감 대기'로 변경하고 다음 정산에 반영하는 로직이 있는가?
판매자용 대시보드에서 '정산 예정 금액'과 '지급 완료 금액'을 구분하여 보여주는가?
정산 내역서(CSV/Excel) 다운로드 기능을 통해 판매자가 정산 근거를 확인할 수 있게 했는가?

다음 단계

정산 모델을 대략 잡았다면, 다음은 돈의 흐름과 정산 주기를 운영 기준까지 내려서 설계해야 해요.

실제 연동할 때

정산 모델을 정했다면 코드는 다음 순서로 들어가요.

B2B 마켓플레이스 이해하기 — 그룹·한도·정산 집계 모델
그룹 정산 집계 — 정산 주기별 거래 집계 API
주문 이해하기 — 주문·취소·환불 흐름

바로 참고할 문서

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

주의: 이 가이드는 일반적인 정보를 제공하기 위한 목적으로 작성되었으며, 실제 서비스 도입 시 반드시 법률 및 세무 전문가의 개별 자문을 받아야 해요.