중개 플랫폼 수수료·정산 설계: 원장·환불·대사 기준 [2026]
중개 플랫폼 정산을 주문 항목·결제·수수료·지급·환불 사건 원장으로 설계하는 법을 정리했습니다. 정책 버전, 부분 환불, 음수 잔액, 4자 대사와 재마감 기준을 확인하세요.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
중개 플랫폼 수수료·정산 설계는 주문 금액에 수수료율을 곱하는 화면이 아니라 주문 항목·결제·공급자 귀속액·지급·환불·분쟁·조정의 모든 돈 사건을 버전 있는 원장으로 연결하는 일입니다. 현재 잔액만 저장하면 지급 뒤 부분 환불이나 수수료 정책 변경이 발생했을 때 누가 얼마를 부담하는지 재현할 수 없습니다.
정산에서 주문, 승인, 매입, 지급은 같은 시점에 끝나지 않습니다. 한 주문 안에서도 공급자·세율·쿠폰 부담 주체가 다르고, 부분 취소와 분쟁은 지급 이후에 도착할 수 있습니다. 따라서 주문 총액 하나를 정산의 원천으로 삼지 말고 금액의 생성·귀속·이동·취소를 사건으로 남겨야 합니다.
좋은 정산 시스템의 완료 기준은 지급 파일이 만들어졌다는 사실이 아닙니다. 결제사 자료, 내부 원장, 공급자 명세서와 실제 은행 지급을 같은 식별자로 대사하고, 차이가 생기면 영향 범위를 조회해 보류·조정·재처리·재마감을 할 수 있어야 합니다.
잔액보다 돈 객체와 사건의 계보를 먼저 설계한다#
금액을 덮어쓰지 않고 원인 사건과 반대 사건을 연결해야 과거 명세서를 다시 계산할 수 있습니다.
| 객체 | 고유 식별자 | 원천과 관계 | 실패 시 증거 |
|---|---|---|---|
| 주문 항목 | order_line_id | 상품·공급자·수량·세금 | 주문 스냅샷 |
| 결제 사건 | payment_event_id | 승인·매입·취소·분쟁 | 결제사 거래 ID |
| 귀속·수수료 | entitlement_id | 항목·정책 버전·부담 주체 | 계산 입력과 결과 |
| 지급·조정 | payout_or_adjustment_id | 정산 기간·수취인·원인 사건 | 지급 파일·대사 상태 |
수수료 계산을 시행일이 있는 계약으로 고정한다#
요율만 저장하면 반올림·쿠폰·세금·부분 취소에서 서로 다른 답이 나옵니다.
| 규칙 | 반드시 정할 값 | 버전 조건 | 검증 표본 |
|---|---|---|---|
| 계산 기준 | 상품가·배송비·할인 전후·세금 포함 여부 | 거래 시점 기준 | 단일·묶음 주문 |
| 요율·고정액 | 공급자·카테고리·채널별 적용 순서 | 시행·종료 시각 | 경계 시각 주문 |
| 배분·반올림 | 항목 배분·최소 단위·잔여액 귀속 | 계산 엔진 버전 | 부분 수량 취소 |
| 보류·준비금 | 지급 가능일·분쟁·음수 잔액 정책 | 계약·위험 등급 | 지급 뒤 환불 |
실무 시나리오: 지급 완료 뒤 부분 환불이 들어온다#
공급자에게 1차 지급을 마친 뒤 주문 두 항목 중 하나가 환불되고 결제 분쟁까지 이어지는 경우를 가정합니다.
| 단계 | 판단 질문 | 처리 | 완료 증거 |
|---|---|---|---|
| 탐지 | 어떤 항목·지급·수수료가 영향받나 | 사건 연결·추가 지급 보류 | 영향 그래프 |
| 귀속 | 플랫폼·공급자·쿠폰 부담은 얼마인가 | 원 정책 버전으로 역산 | 취소 계산 명세 |
| 회수 | 준비금으로 상계할지 다음 지급에서 조정할지 | 조정 원장·음수 한도 적용 | 공급자 명세 반영 |
| 마감 | 결제사·원장·명세·은행이 일치하나 | 차이 큐 해소·기간 재마감 | 4자 대사 결과 |
결제 흐름과 손실 책임은 사용 중인 계약에서 확인한다#
Stripe Connect 공식 문서는 charge 유형에 따라 플랫폼·연결 계정·결제사 사이의 자금 이동과 환불·차지백 시 차감되는 잔액이 달라진다고 설명합니다. 이 문서는 사건·잔액·책임을 분리해야 한다는 제품 사례이며 국내 PG·카드사·은행·세무 기준을 대신하지 않습니다. 실제 구현은 현재 계약과 거래 구조를 법무·회계·세무 담당자가 함께 확인해야 합니다.
- Stripe Connect charge types: 결제 유형별 자금 흐름과 환불·차지백 차감 주체
- Stripe Connect risk management: 환불·분쟁으로 인한 음수 잔액과 손실 책임의 제품별 조건
- Stripe Connect disputes: 분쟁 사건과 플랫폼 통합 유형별 처리 방식
불변 원장·멱등성·대사 큐·마감 재개를 운영한다#
정산 사건에는 주문 항목, 공급자, 원 결제, 원 지급, 정책 버전, 발생 시각, 회계 기간, 통화, 금액, 원인 사건을 기록합니다. 수정은 기존 행을 바꾸지 말고 취소·조정 사건을 추가해 어느 시점의 명세서도 같은 입력으로 재현되게 하세요.
결제 웹훅과 배치 재실행에는 외부 사건 ID와 내부 멱등 키를 사용합니다. 중복 사건, 순서가 뒤바뀐 사건, 알 수 없는 공급자, 지급 계좌 오류는 삭제하지 말고 이유·소유자·재처리 상태를 가진 격리 큐로 보냅니다.
매일 결제사 거래와 내부 결제 원장을, 정산일에는 공급자 귀속액·지급 파일·은행 결과를 대사합니다. 마감 이후 사건은 다음 기간에 숨기지 말고 원 기간과 현재 조정 기간을 함께 연결하며, 재마감 권한과 승인 로그를 남깁니다.
플랫폼 전체 기능 경계는 마켓플레이스 개발 가이드에서 정리합니다. 승인·취소 연동 기준은 결제 연동 개발과 함께 확인합니다. PG 자료 대사 관점은 PG·간편결제 정산을 참고하세요.
대표 거래와 실패 거래를 재현한 뒤 승인한다#
단일·다중 공급자 주문, 배송비, 플랫폼·공급자 쿠폰, 수량 부분 취소, 지급 전·후 환불, 중복 웹훅, 분쟁, 음수 잔액, 지급 계좌 실패, 정책 시행 경계 시각을 표본으로 고정합니다.
운영자가 주문 ID 하나로 결제부터 귀속·지급·취소·조정의 계보를 조회하고, 같은 정책 버전으로 명세서를 재생성하며, 결제사·내부 원장·공급자 명세·은행 결과의 차이를 목표 시간 안에 해소해야 승인합니다.
핵심 요약
- ✓주문 총액이 아니라 주문 항목·결제·귀속·수수료·지급·환불·분쟁 사건을 연결한다
- ✓계산 기준·부담 주체·배분·반올림·시행일을 수수료 정책 버전에 기록한다
- ✓지급 뒤 부분 환불과 음수 잔액을 준비금·다음 지급 조정·대사 절차로 시험한다
- ✓외부 사건 ID와 멱등 키, 불변 원장, 격리 큐로 중복과 순서 역전을 복구한다
- ✓결제사·내부 원장·공급자 명세·은행 지급의 4자 대사를 완료 기준으로 삼는다
자주 묻는 질문