마켓플레이스 정산, 수수료, 판매자 지급: 자금 처리 레이어 설계 방법

이 가이드는 멀티벤더 마켓플레이스의 CTO, 제품 책임자, 재무 담당자를 위한 것입니다. 결제를 벤더, 카탈로그, 주문과 함께 배치하는 마켓플레이스 플랫폼 아키텍처 가이드보다 한 단계 더 깊이 들어가며, 여기서는 결제 이후의 자금만을 다룹니다. 커스텀 플랫폼이 정당화되는 시점에 대해서는 커스텀 이커머스 플랫폼 가이드를 참고하십시오.

이 가이드의 내용

• 세 가지 레이어: 제공업체, 원장, 지급 엔진
• 수수료 모델과 각 모델의 적합한 상황
• 판매자 원장
• 정산 타이밍 및 출시 규칙
• 환불, 차지백 및 마이너스 잔액
• 지급 운영 및 실패
• 세금 및 보고 의무
• 대사(Reconciliation)
• 구축, 구매 또는 구성: 대안 및 선택 기준
• 마켓플레이스 정산에서의 AI
• 존재하는 납품 실적 및 존재하지 않는 것
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

세 가지 레이어: 제공업체, 원장, 지급 엔진

대부분의 정산 문제는 세 가지 역할을 혼동하는 데서 발생합니다.

• 결제 제공업체는 구매자에게 청구하고, 규제된 자금을 보유하며, 판매자를 인증하고 은행 계좌로 송금합니다. Stripe Connect, Adyen for Platforms 같은 마켓플레이스 상품은 판매자 온보딩, 결제 분배, 지급 관리를 처리합니다.
• 원장은 각 금액이 누구에게 귀속되는지 이유를 기록합니다. 주문 항목, 수수료, 요금, 할인, 환불, 유보금, 조정이 이에 해당합니다. 판매자 명세서, 재무 보고서, 지원 답변의 출처가 됩니다.
• 지급 엔진은 잔액을 언제 해제할지 결정하고 제공업체에 이동을 요청한 뒤 결과를 기록합니다.

제공업체의 잔액은 오늘 이동할 수 있는 금액을 보여줄 뿐, 판매자가 예상보다 적게 받은 이유나 환불이 지난달 수수료에 어떤 영향을 미쳤는지는 설명하지 않습니다. 그것은 원장의 역할이며, 스프레드시트의 역할이 아닙니다.

수수료 모델과 각 모델의 적합한 상황

어떤 모델이든 수수료 규칙은 코드가 아닌 데이터로 작성하십시오. 판매자, 카테고리, 날짜를 키로 하는 요율 테이블에 모든 변경 사항에 유효 시작일을 기록합니다. 각 주문 항목에 적용된 요율을 저장하십시오. 3개월 후 환불 시 오늘의 요율이 아닌 당시 청구된 수수료를 역산해야 하기 때문입니다.

판매자 원장

자금 이동을 회계사처럼 처리하십시오. Martin Fowler의 회계 패턴은 이를 잘 설명합니다. 잔액은 항목에서 나오며, 실수는 기존 항목을 수정하는 것이 아니라 새로운 조정 또는 역산 항목으로 수정합니다. 마켓플레이스의 경우 이는 다음을 의미합니다.

• 이벤트당 하나의 항목. 주문 항목 결제, 수수료 청구, 제공업체 수수료 배분, 환불 발행, 차지백 수령, 유보금 적립, 유보금 해제, 지급 발송, 지급 반환.
• 복식부기. 각 항목은 구매자 자금에서 판매자 대기로, 또는 판매자 대기에서 플랫폼 수수료로와 같이 두 계정 간에 금액을 이동시키므로 총합은 항상 영(zero)으로 균형을 유지합니다.
• 세 가지 상태의 판매자별 잔액. 대기(납품 또는 반품 기간 내에 획득), 가용(다음 실행 시 지급 가능), 유보(환불 및 분쟁에 대비해 보류). Stripe는 연결 계좌의 대기 및 가용 잔액을 동일한 용어로 설명합니다.
• 출처 연결. 모든 항목에는 해당 주문, 항목, 환불 또는 분쟁과 제공업체의 거래 참조가 포함됩니다.

이러한 원장은 지급 이유, 공제 이유, 아직 미지급 금액을 몇 분 내에 답변합니다.

환불, 차지백 및 마이너스 잔액

환불과 분쟁은 자금이 이동한 후에 발생하므로 출시 전에 규칙을 마련해야 합니다.

• 판매자 항목별 환불. 환불은 해당 항목의 판매자 몫을 역산하고, 정책에 따라 수수료도 역산합니다. 장바구니의 다른 판매자는 영향을 받지 않습니다.
• 차지백. 제공업체는 청구가 이루어진 계좌에서 분쟁 금액을 회수합니다. 판매자가 이미 지급받은 경우, 플랫폼은 판매자의 잔액이 충당될 때까지 부족분을 부담합니다.
• 마이너스 잔액은 정상입니다. 판매자에게 금액, 이유, 날짜를 표시하고, 미래 수익에서 자동으로 상쇄하며, 잔액이 오래된 경우에만 에스컬레이션합니다. Stripe는 마이너스 잔액이 있는 연결 계좌는 잔액이 플러스로 전환될 때까지 지급을 받지 못하며, 플랫폼의 자체 잔액이 책임 있는 계좌를 충당하기 위해 유보될 수 있다고 명시합니다.
• 손실 부담자를 결정하십시오. 각 제공업체 설정에서 판매자의 마이너스 잔액에 대해 제공업체 또는 플랫폼이 책임을 지는지 결정하고, 그 결정을 고려하여 수수료를 책정하십시오.

지급 운영 및 실패

비정상적인 경우를 대비하여 지급을 계획하십시오.

• 은행 정보 변경. 지급 정보의 모든 변경을 위험 이벤트로 처리하십시오. 확인하고, 다음 지급을 잠시 보류하며, 변경자와 변경 내용을 기록합니다.
• 반환된 지급. 거부된 은행 이체는 판매자의 가용 잔액으로 금액을 반환하고, 판매자가 정보를 수정할 작업을 생성합니다.
• 통화. 주문 통화, 정산 통화, 각 환전에 사용된 환율을 기록하여 명세서가 은행에 입금된 금액과 일치하도록 합니다.
• 명세서. 각 판매자에게 지급별 다운로드 가능한 명세서를 제공하십시오. 주문, 수수료, 요금, 환불, 유보금, 조정이 지급 금액과 합산되어야 합니다.

세금 및 보고 의무

판매자의 소득을 처리하는 플랫폼은 여러 지역에서 보고 의무를 집니다. EU에서는 DAC7이 디지털 플랫폼 운영자에게 판매자 정보를 수집·인증하고 세무 당국에 보고하도록 요구합니다. 미국에서는 제3자 정산 기관으로 활동하는 온라인 마켓플레이스가 IRS 신고 기준 이상의 판매자에 대해 Form 1099-K를 제출합니다. 온보딩 시 판매자 데이터를 수집하고 원장에 판매자별, 연도별 지급 총액을 기록하여 보고가 쿼리로 처리될 수 있도록 하십시오. 현재 기준은 세무사에게 확인하십시오.

대사(Reconciliation)

매일 세 가지 뷰를 대사하십시오. 원장, 제공업체의 잔액 거래, 은행. 각 지급을 원장 항목 및 은행 입금과 대조하고, 차이를 표시하며, 미대조 항목에 담당자가 지정된 경우에만 해당 일을 마감하십시오. 요약 항목을 재무 시스템에 전기하십시오. 저희의 ERP, CRM 및 이커머스 통합 가이드에서 해당 연결을 다룹니다. 출시 전 테스트에는 여러 판매자, 부분 환불, 지급 후 차지백, 반환된 지급, 통화 환전이 포함된 생성된 장바구니가 포함되어야 하며, 모두 원장이 영(zero)으로 균형을 이루는 것으로 끝나야 합니다.

구축, 구매 또는 구성: 대안 및 선택 기준

네 가지 기준이 결정합니다. 수수료 및 유보 규칙이 얼마나 독특한지, 정산하는 통화와 국가의 수, 분쟁 손실 부담자, 매월 재무에 필요한 보고 범위입니다. Netbase는 WooCommerce, Magento 2, Laravel 및 headless commerce 기반의 커머스 플랫폼을 납품했으며, 커스텀 개발에서는 클라이언트가 이를 위해 생성된 IP를 소유합니다. 대부분의 Netbase 프로젝트는 디스커버리 후 고정가 계약으로 납품됩니다. 풀 빌드의 상업적 제안은 이커머스 마켓플레이스 솔루션이며, 이커머스 개발을 통해 납품됩니다.

소프트웨어 에이전트가 주문을 배치하는 경우에도 모든 자동화된 환불에는 추적 가능한 항목이 필요합니다. 에이전틱 커머스 준비도 가이드를 참조하십시오.

존재하는 납품 실적 및 존재하지 않는 것

• RB Marketplace. 서아프리카 및 디아스포라를 위한 Laravel 멀티벤더 마켓플레이스로, 판매자는 수익, 수수료 공제, 지급 요청을 확인할 수 있으며 관리자는 수수료와 지급을 제어합니다 (RB Marketplace 실적).
• EU 패션 테크 마켓플레이스. Netbase는 익명의 EU 클라이언트를 위해 Stripe Connect로 분할 결제와 판매자 지급을 처리하는 멀티벤더 마켓플레이스를 구축했습니다 (EU 마켓플레이스 사례).
• 클래식 마켓플레이스 외부의 멀티벤더 모듈. 두바이의 로열티 및 리워드 기업을 위해 Netbase는 멀티벤더 모듈, 주문 처리 라우팅 및 포인트+현금 결제를 갖춘 리워드 쇼핑 플랫폼을 납품했습니다 (로열티 리워드 쇼핑 실적).

존재하지 않는 것. 공개된 Netbase 실적 중 커스텀 정산 엔진, 유보 정책 또는 세금 보고 구축을 설명하는 것은 없으며, 지급, 대사 또는 분쟁 수치를 공개한 것도 없습니다. 위의 원장, 출시 및 대사 관행은 납품 실무와 인용된 제공업체 문서에서 비롯된 것이며, 측정된 결과에서 나온 것이 아닙니다.

이 가이드의 한계

• 결제, 세금, 소비자 규정은 국가마다 다릅니다. 출처는 설계해야 할 의무의 예시로 인용된 것이며, 완전한 목록이 아닙니다. 법률 및 세무 자문을 받으십시오.
• Stripe와 Adyen은 플랫폼 결제 서비스의 예시로 언급된 것이며, 다른 제공업체보다 추천하는 것이 아닙니다.

다음 단계

수수료 모델, 결제 지역, 지급 일정을 공유해 주시면 원장과 정산 흐름을 설계하기 위한 솔루션 리뷰를 예약하겠습니다. Netbase의 리테일 및 이커머스 분야 활동을 확인하거나 Netbase 인사이트를 더 읽어보실 수도 있습니다.

관련 서비스 및 솔루션