두 수수료의 정체
계산 예시
표면 요율이 낮은 자사몰이라도 고객 유입을 위한 광고나 운영 작업이 추가된다면 판매 전체의 부담은 달라질 수 있습니다
계약 조건과 비교하기 위한 설명용 예시입니다.오픈마켓 수수료 PG수수료 차이의 첫 확인입니다. 판매 수수료와 결제 비용의 범위를 맞춥니다. 오픈마켓 판매 수수료에는 결제 외에 판매 채널이 제공하는 기능이 함께 반영될 수 있습니다. 자사몰 PG 비용과 비교할 때는 광고 · 운영 · 플랫폼 · 배송 관련 비용까지 비교 범위를 맞춰야 선택의 의미가 분명해집니다. 채널별 판매 수수료와 광고 · 운영 비용, PG · 빌더 이용료, 거래액 · 건수를 정리합니다. 같은 품목과 기간을 기준으로 반복 비용과 유입 확보에 필요한 비용을 나눠 비교합니다. 전체 흐름은 쇼핑몰 PG수수료 안내에서 함께 볼 수 있습니다.
표면 요율이 낮은 자사몰이라도 고객 유입을 위한 광고나 운영 작업이 추가된다면 판매 전체의 부담은 달라질 수 있습니다. 채널을 바꾼 뒤에도 필요한 고객 확보 · 주문 관리 업무가 빠져 있지 않은지 검토합니다. 서로 제공 범위가 다른 비용을 결제 수수료 한 항목으로만 비교해 어느 채널이 항상 유리하다고 결론내리지 않습니다. 여러 판매 채널을 병행하면 주문번호와 결제 식별값이 각 시스템에서 따로 만들어질 수 있습니다. 고객이 문의할 때 어느 채널에서 구매했는지와 실제 결제 기록을 연결할 수 있어야 조회와 환불이 쉬워집니다.
- 채널별 판매 수수료와 광고 · 운영 비용, PG · 빌더 이용료, 거래액 · 건수를 정리합니다.
- 같은 품목과 기간을 기준으로 반복 비용과 유입 확보에 필요한 비용을 나눠 비교합니다.
- 채널을 바꾼 뒤에도 필요한 고객 확보 · 주문 관리 업무가 빠져 있지 않은지 검토합니다.
오픈마켓 판매 수수료 구조
계산 예시
플랫폼이 제공하던 자동 알림이나 환불 관리가 자사몰에서는 별도 작업일 수 있어 이전 전에 담당 역할을 정하면 좋습니다
계약 조건과 비교하기 위한 설명용 예시입니다.플랫폼 판매와 직접 판매의 책임을 나눕니다. 교육 · 콘텐츠나 상품을 플랫폼에서 판매하는 방식과 자체 사이트에서 직접 판매하는 방식은 결제 · 고객 안내 · 정산을 누가 관리하는지가 다를 수 있습니다. 같은 상품이라도 사업자가 준비할 범위가 달라집니다. 채널별 판매 주체와 결제 처리 · 환불 · 정산 담당 범위를 정리합니다. 직접 판매에서 새로 준비해야 하는 고객 정책과 주문 · 결제 관리 기능을 확인합니다. 고객에게 표시한 판매 책임 · 문의 창구와 실제 정산 구조가 같은지 점검합니다.
플랫폼이 제공하던 자동 알림이나 환불 관리가 자사몰에서는 별도 작업일 수 있어 이전 전에 담당 역할을 정하면 좋습니다. 고객에게 보이는 판매자 정보와 실제 계약 · 문의 창구가 일치하는지 점검합니다. 플랫폼에서 판매했다는 이력만으로 자체 사이트의 PG 계약 · 심사가 자동 완료된다고 보지 않습니다. 사업자가 직접 상품을 판매하는지, 다른 판매자의 거래를 연결하고 대금을 처리하는지에 따라 계약 · 정산과 고객 책임이 달라질 수 있습니다. 단순 쇼핑몰이라는 이름보다 실제 판매 주체와 대금 전달 구조를 설명해야 합니다.
| 확인할 것 | 준비 · 확인 방법 | 판단 기준 |
|---|---|---|
| 자료 | 채널별 판매 주체와 결제 처리 · 환불 · 정산 담당 범위를 정리합니다 | 판매자와 구매자, 상품 제공자와 대금 수취 · 분배의 흐름을 정리합니다 |
| 진행 | 직접 판매에서 새로 준비해야 하는 고객 정책과 주문 · 결제 관리 기능을 확인합니다 | 직접 판매와 중개 · 대행에 해당하는 부분을 나누어 필요한 계약 범위를 확인합니다 |
| 결과 | 고객에게 보이는 판매자 정보와 실제 계약 · 문의 창구가 일치하는지 점검합니다 | 고객에게 표시한 판매 책임 · 문의 창구와 실제 정산 구조가 같은지 점검합니다 |
- 채널별 판매 주체와 결제 처리 · 환불 · 정산 담당 범위를 정리합니다.
- 직접 판매에서 새로 준비해야 하는 고객 정책과 주문 · 결제 관리 기능을 확인합니다.
- 고객에게 보이는 판매자 정보와 실제 계약 · 문의 창구가 일치하는지 점검합니다.

자사몰 결제 수수료 구조
계산 예시
플랫폼 프로모션으로 가입비가 줄어도 요금제 기간이나 대상 PG 조건이 붙을 수 있어 전체 계약의 반복 비용을 확인하는 편이 좋습니다
계약 조건과 비교하기 위한 설명용 예시입니다.빌더 비용과 PG 비용은 별도 줄로 비교합니다. 쇼핑몰 이용료와 결제대행 수수료는 제공하는 기능과 부과 주체가 다를 수 있습니다. 기본 제공 PG와 직접 계약을 비교할 때는 플랫폼 요금제, 앱 비용과 연결 지원 범위를 포함해 실제 운영 구성을 함께 봅니다. 빌더 요금제와 앱 청구서, PG 견적과 지원되는 신청 경로를 준비합니다. 현재 구성과 변경 구성을 같은 기간으로 계산하고 초기 이전 · 연동 작업도 따로 적습니다. 기능을 끈 뒤 주문 · 고객 안내 · 정산 업무에 빠지는 부분이 없는지 확인합니다.
플랫폼 프로모션으로 가입비가 줄어도 요금제 기간이나 대상 PG 조건이 붙을 수 있어 전체 계약의 반복 비용을 확인하는 편이 좋습니다. 직접 계약이 실제 지원되는지와 바뀌는 기능 · 문의 창구를 확인합니다. 직접 계약이 항상 더 저렴하거나 빌더의 모든 서비스를 유지할 수 있다고 단정하지 않습니다. 문자 알림 · 플러그인 · 관리 기능 등은 결제 요율 외의 비용을 만들 수 있습니다. 필요한 업무를 줄이는 기능인지와 매달 얼마나 발생하는지 함께 확인하면 기본 계약과 추가 서비스의 부담을 구분할 수 있습니다.
- 빌더 요금제와 앱 청구서, PG 견적과 지원되는 신청 경로를 준비합니다.
- 현재 구성과 변경 구성을 같은 기간으로 계산하고 초기 이전 · 연동 작업도 따로 적습니다.
- 직접 계약이 실제 지원되는지와 바뀌는 기능 · 문의 창구를 확인합니다.
같은 매출 비교
계산 예시
카드 비중이 높은 가정과 계좌 비중이 높은 가정을 별도로 계산하면 수단 구성에 따라 유리한 조건이 바뀌는지 볼 수 있습니다
계약 조건과 비교하기 위한 설명용 예시입니다.같은 거래 가정으로 다시 계산합니다. 비교 대상의 요율과 비용 구조가 다르면 동일한 매출 · 건수 · 수단 비율을 넣어야 차이가 보입니다. 서로 다른 규모의 예시를 나란히 두면 비용 구조의 차이인지 거래량 차이인지 알기 어렵습니다. 공통 거래액과 건수 · 객단가, 수단 구성과 세금 기준을 정합니다. 각 견적의 실제 산식으로 계산하고 초기 · 반복 비용을 나눠 표시합니다. 비용 합계와 함께 지급 시점 · 유보처럼 합계에 바로 더하지 않는 조건도 별도로 표시합니다.
카드 비중이 높은 가정과 계좌 비중이 높은 가정을 별도로 계산하면 수단 구성에 따라 유리한 조건이 바뀌는지 볼 수 있습니다. 차액이 어떤 항목에서 생겼는지와 확인되지 않은 조건이 없는지 검토합니다. 계산 예시를 업체별 실제 가격이나 모든 사업자에게 적용되는 순위로 표현하지 않습니다. 여러 조건을 동시에 바꾸면 결과가 왜 달라졌는지 읽기 어렵습니다. 동일한 매출과 수단 구성에서 요율만 바꾼 경우, 고정비를 더한 경우와 정산 조건이 달라진 경우를 따로 놓으면 비용의 원인을 볼 수 있습니다.
- 공통 거래액과 건수 · 객단가, 수단 구성과 세금 기준을 정합니다.
- 각 견적의 실제 산식으로 계산하고 초기 · 반복 비용을 나눠 표시합니다.
- 차액이 어떤 항목에서 생겼는지와 확인되지 않은 조건이 없는지 검토합니다.
두 채널 병행 계산
계산 예시
오픈마켓과 자사몰을 같이 운영한다면 이름과 금액이 같은 주문이 있어도 채널 · 거래번호로 찾아야 잘못 취소하는 일을 줄일 수 있습니다
계약 조건과 비교하기 위한 설명용 예시입니다.같은 상품도 채널별 주문번호를 구분합니다. 여러 판매 채널을 병행하면 주문번호와 결제 식별값이 각 시스템에서 따로 만들어질 수 있습니다. 고객이 문의할 때 어느 채널에서 구매했는지와 실제 결제 기록을 연결할 수 있어야 조회와 환불이 쉬워집니다. 판매 채널과 주문번호 체계, 가맹점 정보와 고객 문의 경로를 정리합니다. 채널별 거래를 구분해 보관하고 공통 보고서에는 출처를 표시합니다. 월별 합계에 중복 · 누락이 없고 계약 종료 뒤 남는 거래의 담당이 정해졌는지 확인합니다.
오픈마켓과 자사몰을 같이 운영한다면 이름과 금액이 같은 주문이 있어도 채널 · 거래번호로 찾아야 잘못 취소하는 일을 줄일 수 있습니다. 같은 상품이 다른 채널에서 판매되어도 취소 · 정산을 원거래 경로로 처리하는지 확인합니다. 한 채널의 주문 이력을 다른 채널의 실제 결제처럼 기록하거나 다른 사업자의 매출과 섞지 않습니다. 기존 PG와 신규 PG를 병행하거나 채널별 계약을 쓰는 경우에는 각 계약의 거래 · 정산 · 취소 범위를 구분해야 합니다. 같은 계좌나 관리자 이름이 있어도 실제 처리 주체가 다를 수 있어 문서로 연결해 두는 것이 좋습니다.
- 판매 채널과 주문번호 체계, 가맹점 정보와 고객 문의 경로를 정리합니다.
- 채널별 거래를 구분해 보관하고 공통 보고서에는 출처를 표시합니다.
- 같은 상품이 다른 채널에서 판매되어도 취소 · 정산을 원거래 경로로 처리하는지 확인합니다.
자사몰로 옮길 때
계산 예시
빌더를 옮길 때 같은 PG사를 계속 쓰더라도 새 플랫폼에서 기존 가맹점 연결을 지원하는지 별도로 확인해야 합니다
계약 조건과 비교하기 위한 설명용 예시입니다.판매 채널 변경은 운영 기록까지 함께 옮깁니다. 사이트 제작 도구나 판매 채널을 바꾸면 화면뿐 아니라 주문 상태, 결제 계약과 취소 · 정산 업무가 영향을 받을 수 있습니다. 기존에 처리한 거래와 앞으로 받을 거래를 구분해 이전 범위를 계획합니다. 기존 주문과 계약 정보, 새 플랫폼의 지원 범위, 도메인 · 결과 수신 주소를 정리합니다. 새 환경의 신청 · 설정을 검증한 뒤 이전 거래 조회와 취소 창구를 유지할 방법을 마련합니다. 새 주문과 과거 거래의 조회 · 취소 · 정산 경로가 각자 유지되는지 검증합니다.
빌더를 옮길 때 같은 PG사를 계속 쓰더라도 새 플랫폼에서 기존 가맹점 연결을 지원하는지 별도로 확인해야 합니다. 전환 전후 주문이 각각 맞는 계약으로 처리되고 담당자가 구분해 조회할 수 있는지 확인합니다. 서비스 이름이 같다는 이유만으로 계약 · 빌링키 · 이력의 자동 이전이 가능하다고 가정하지 않습니다. 쇼핑몰 데이터를 새 빌더로 옮기는 작업과 결제 계약을 새 환경에 연결하는 작업은 별개일 수 있습니다. 기존 계약의 재사용 지원 여부, 주문 · 정기결제 이력과 취소 · 정산 업무가 어떻게 이어지는지 확인합니다.
| 확인할 것 | 준비 · 확인 방법 | 판단 기준 |
|---|---|---|
| 자료 | 기존 주문과 계약 정보, 새 플랫폼의 지원 범위, 도메인 · 결과 수신 주소를 정리합니다 | 기존 · 신규 플랫폼과 계약 정보, 도메인 · 주문 데이터 및 남은 거래를 정리합니다 |
| 진행 | 새 환경의 신청 · 설정을 검증한 뒤 이전 거래 조회와 취소 창구를 유지할 방법을 마련합니다 | 새 플랫폼의 지원 경로로 연결 가능 여부를 확인하고 필요하면 신규 신청을 진행합니다 |
| 결과 | 전환 전후 주문이 각각 맞는 계약으로 처리되고 담당자가 구분해 조회할 수 있는지 확인합니다 | 새 주문과 과거 거래의 조회 · 취소 · 정산 경로가 각자 유지되는지 검증합니다 |
- 기존 주문과 계약 정보, 새 플랫폼의 지원 범위, 도메인 · 결과 수신 주소를 정리합니다.
- 새 환경의 신청 · 설정을 검증한 뒤 이전 거래 조회와 취소 창구를 유지할 방법을 마련합니다.
- 전환 전후 주문이 각각 맞는 계약으로 처리되고 담당자가 구분해 조회할 수 있는지 확인합니다.

