PG 직접 계약 vs 쇼핑몰 솔루션 결제｜계약·수수료·이전 5가지 차이

쇼핑몰 솔루션 안에서 PG를 신청하는 방식과 독립적으로 PG를 연동하는 방식은 ‘누구와 계약하느냐’ 하나로 나뉘지 않습니다.

신청 경로·기술 연동·PG 계약/MID·정산·이전 가능성을 분리해 보면 어떤 방식이 내 쇼핑몰에 맞는지 판단할 수 있습니다.

쇼핑몰 결제를 고를 때 가장 먼저 생기는 오해가 있습니다. ‘솔루션 내장결제’와 ‘PG 직접 계약’을 완전히 반대되는 두 계약 구조라고 생각하는 것입니다.

실제로는 쇼핑몰 관리자 안에서 PG를 신청하더라도 PG사가 별도 심사하고 해당 상점의 MID(상점 ID)를 발급하는 방식이 있습니다. 반대로 결제 연동 서비스가 신청 과정을 도와줘도 실제 PG 계약 상태는 별도로 존재할 수 있습니다.

따라서 이름보다 실제 구조를 봐야 합니다. 신청을 어디서 하는지, 누가 결제 모듈을 관리하는지, PG 계약과 MID가 어떻게 발급되는지, 정산·취소를 어디서 처리하는지, 다른 쇼핑몰로 옮길 때 무엇을 다시 해야 하는지를 확인하는 것이 핵심입니다.

먼저 결론: ‘직접 계약’보다 ‘누가 무엇을 맡는 구조인가’를 비교하세요

개발 부담을 줄이고 현재 쇼핑몰 솔루션이 필요한 결제수단과 기능을 지원한다면 솔루션 안에서 PG를 신청·연동하는 방식이 대체로 편합니다.

반대로 현재 솔루션이 필요한 결제 흐름을 지원하지 않거나, 자체 주문·정산 시스템과 깊게 연결해야 하거나, 기술 구조를 직접 관리할 필요가 크다면 독립적인 PG 계약·연동을 검토할 이유가 생깁니다.

다만 ‘솔루션 결제는 플랫폼과만 계약한다’, ‘직접 PG 계약은 항상 수수료가 더 싸다’처럼 단순화하면 안 됩니다. 실제 계약서·PG 관리자·MID·정산 내역을 확인해야 정확한 구조를 알 수 있습니다.

1. ‘내장결제’라는 말은 네 층으로 나눠서 보세요

결제 구조는 다음 네 층으로 나누면 빠르게 이해됩니다.

① 신청 경로

쇼핑몰 관리자에서 PG를 신청하는지, PG사나 외부 결제 연동 서비스에서 신청하는지입니다.

② 기술 연동

쇼핑몰 솔루션이 이미 구현한 결제 모듈을 켜는지, 개발자가 SDK·API를 직접 연동하는지입니다.

③ PG 계약과 MID

어느 PG의 심사를 받고 어떤 상점 ID(MID)가 발급되는지입니다. 신청 화면이 쇼핑몰 안에 있다고 해서 이 층까지 쇼핑몰 솔루션이 대신한다고 단정할 수는 없습니다.

④ 정산과 운영

판매대금 정산을 어디서 확인하고, 취소·환불·장애 대응을 어느 관리자와 고객센터에서 처리하는지입니다.

토스페이먼츠는 호스팅 서비스로 만든 임대형 쇼핑몰은 호스팅사를 통해 PG를 신청할 수 있고, 직접 만든 독립몰은 PG를 직접 연동하는 방식으로 설명합니다. 카페24와 NHN커머스의 안내를 보면 솔루션 관리자에서 신청하더라도 PG사의 심사·계약·상점 설정이 이어지는 사례를 확인할 수 있습니다.

즉 ‘내장’은 우선 신청·연동 경험을 설명하는 말입니다. 계약·정산 구조까지 같은 의미라고 가정하지 않는 편이 안전합니다.

30초 만에 내 결제 구조 확인하기

1. PG 계약서 또는 계약 안내 메일에 적힌 상대 회사는 어디인가?
2. PG 관리자에서 내 상점의 MID를 확인할 수 있는가?
3. 정산 내역의 최종 확인 화면은 어디인가?
4. 취소·환불은 쇼핑몰 관리자에서 끝나는가, PG 관리자까지 들어가야 하는가?

한 화면에서 모든 것을 관리한다고 해서 계약과 정산 주체도 그 화면의 운영사라고 단정할 수는 없습니다.

2. 실제 차이는 개발 부담과 통제 범위에서 커집니다

쇼핑몰 솔루션이 지원하는 PG를 사용하면 결제 모듈과 주문 상태 연결이 이미 구현되어 있는 경우가 많아 신청·승인 후 관리자 설정에 집중할 수 있습니다.

독립적으로 PG를 연동하면 테스트·라이브 키, 결제 요청과 승인, 취소·환불, 오류 처리 등 결제 흐름을 직접 구현하고 검증해야 합니다. 토스페이먼츠 개발자 문서도 계약 전 테스트와 계약 후 상점별 키를 구분하고, 테스트 연동과 카드사 심사를 별도 과정으로 안내합니다.

따라서 통제 범위가 넓어지는 대신 개발과 유지보수 부담도 커집니다.

판단항목	솔루션 지원 PG 신청·연동	독립 PG 계약·자체 연동
초기 구축	관리자 중심이라 상대적으로 단순	개발·테스트·심사 대응 필요
PG 선택	솔루션 지원 범위의 영향을 받음	기술·계약 조건에 맞춰 직접 검토 가능
결제 기능	솔루션 구현 범위의 영향을 받음	계약 기능을 직접 구현 가능, 개발 필요
실제 계약	PG와 별도 계약하는 모델도 있음	PG와 직접 계약
운영	솔루션+PG 관리자로 역할이 나뉠 수 있음	자체 시스템/API+PG 운영 구조
변경·이전	솔루션별 MID·연동 정책 확인 필수	플랫폼 종속은 줄일 수 있으나 재개발 가능

오른쪽이 항상 상위 선택지는 아닙니다. 표준 결제만 필요한 소규모 쇼핑몰이라면 직접 연동의 추가 복잡성이 실익보다 클 수 있습니다.

3. 수수료는 ‘직접 vs 솔루션’만으로 결정되지 않습니다

직접 PG 계약을 검토하는 가장 흔한 이유는 수수료지만, 경로 하나로 최종 비용을 예측하면 안 됩니다.

쇼핑몰 솔루션은 제휴 PG 조건이나 프로모션을 제공할 수 있고, PG사는 사업자의 업종·매출·결제수단 등에 따라 조건을 다르게 제시할 수 있습니다. 금융위원회도 영세·중소 PG 하위가맹점이 우대수수료 적용 대상에 포함될 수 있으며 실제 적용 수수료는 이용 중인 PG를 통해 확인하도록 안내합니다.

따라서 대표 광고 요율이 아니라 내 사업자에게 실제 적용되는 조건을 맞춰 비교합니다.

• 결제수단별 실제 수수료
• 가입비·연 관리비 등 고정비
• 정산 주기와 보류 조건
• 필요한 부가서비스 비용
• 보증보험 등 추가 조건
• 부가세 포함 여부

독립 연동을 선택한다면 개발·유지보수 비용도 함께 넣어야 합니다. 수수료가 조금 낮아도 개발과 운영 부담이 더 크면 총비용은 오히려 늘 수 있습니다.

수수료·가입비·정산주기를 깊게 비교하는 문제는 별도 PG 총비용 비교 글의 범위입니다. 여기서는 ‘결제 경로 자체가 수수료를 자동 결정하지 않는다’는 점만 기억하면 됩니다.

4. 운영은 ‘어디서 취소하고 어디서 정산을 확인하는지’가 중요합니다

솔루션에서 결제를 신청했다고 모든 업무가 솔루션 관리자에서 끝나는 것은 아닙니다.

카페24 AI 홈페이지 빌더의 KCP 연동 안내에서는 결제 내역을 빌더에서 볼 수 있지만 취소·환불과 정산 확인은 KCP 관리자에서 처리하도록 안내합니다. 한 결제 구조 안에서도 쇼핑몰 관리자와 PG 관리자의 역할이 나뉠 수 있다는 뜻입니다.

계약 전에 아래 업무의 담당 위치를 각각 적어두면 좋습니다.

• 결제 승인·실패 확인
• 전체·부분 취소
• 환불 상태 확인
• 정산 내역과 실제 입금 확인
• 결제 장애 기술지원
• 계약·수수료·정산 문의

이 책임 지도가 명확하면 문제가 생겼을 때 쇼핑몰 솔루션과 PG사 사이에서 문의가 반복되는 일을 줄일 수 있습니다.

5. 특히 놓치기 쉬운 것이 ‘이전 가능성’입니다

일반적인 PG 비교 글에서 자주 빠지는 부분입니다.

카페24의 쇼핑몰 이전 안내에는 기존 솔루션에서 사용하던 PG 상점 ID를 그대로 사용할 수 없어 카페24에 맞는 PG를 새로 신청해야 하는 사례가 나옵니다. 이전 전 쇼핑몰에서 발생한 주문의 취소 등은 기존 PG 상점 ID에서 처리해야 한다고 안내합니다.

NHN커머스는 PG 변경 시 기존 PG를 유지한 채 새 PG를 신청하고, 심사가 끝난 뒤 솔루션 설정을 새 PG로 전환하는 방식을 안내합니다.

두 사례를 모든 쇼핑몰에 그대로 적용할 수는 없습니다. 대신 ‘지금 편한가’와 함께 ‘나중에 옮길 수 있는가’를 계약 전에 확인해야 한다는 점은 분명합니다.

1. 현재 MID를 다른 쇼핑몰 솔루션에서도 사용할 수 있는가?
2. 솔루션 변경 시 신규 PG 신청이나 재심사가 필요한가?
3. 이전 전 주문의 취소·환불은 어느 관리자에서 처리하는가?
4. 정기결제 등 별도 계약 서비스는 변경 시 어떻게 처리하는가?
5. PG만 바꿀 때 결제 중단을 줄이는 전환 절차가 있는가?

정기결제나 저장형 결제수단처럼 별도 계약·보안 요건이 있는 기능은 일반 결제보다 이전 조건이 복잡할 수 있으므로 해당 PG와 솔루션의 현재 정책을 별도로 확인합니다.

어떤 쪽이 맞는지 5문항으로 결정하세요

1. 현재 솔루션이 필요한 결제수단과 기능을 지원하나요?

지원한다면 굳이 독립 연동할 이유가 하나 줄어듭니다. 지원하지 않는다면 독립 연동 또는 다른 솔루션을 검토합니다.

2. 결제 개발과 유지보수를 담당할 인력이 있나요?

없다면 솔루션 지원 PG의 운영 편의성이 중요합니다. 있다면 다음 질문으로 넘어갑니다.

3. 솔루션 기본 기능을 넘어서는 결제·정산 요구가 실제로 있나요?

없다면 독립 연동의 복잡성이 실익보다 클 수 있습니다. 있다면 그 기능을 현재 솔루션이 지원하는지, PG 계약과 별도 개발이 필요한지 확인합니다.

4. 앞으로 쇼핑몰 솔루션을 바꿀 가능성이 있나요?

있다면 수수료보다 MID 사용 가능 여부, 기존 주문 취소, 정기결제, 데이터 이전 조건을 먼저 확인합니다.

5. 실제 견적 차이가 개발·운영 부담을 감수할 만큼 큰가요?

광고 요율이 아니라 동일한 결제수단과 정산조건을 놓고 실제 견적을 비교합니다. 비용 차이가 작고 표준 기능으로 충분하다면 솔루션 지원 PG를 유지하는 편이 합리적일 수 있습니다.

계약 전에 솔루션사와 PG사에 같이 물어볼 8가지

1. 실제 전자결제 계약 상대는 누구인가요?
2. 제 상점에 발급되는 PG 상점 ID(MID)는 무엇인가요?
3. 판매대금은 누가 어떤 주기로 정산하나요?
4. 제 사업자에게 적용되는 실제 수수료는 어디에서 확인하나요?
5. 전체·부분 취소와 환불은 어느 관리자에서 처리하나요?
6. 결제·정산 데이터를 API 또는 파일로 받을 수 있나요?
7. 다른 쇼핑몰 솔루션으로 옮길 때 같은 MID를 사용할 수 있나요?
8. 변경·해지 후 기존 주문·환불·정기결제는 어디에서 처리하나요?

양쪽 답변을 같은 표에 적어보면 ‘내장결제’라는 이름보다 실제 구조가 훨씬 명확하게 보입니다.

정리

초기 구축과 표준 결제가 우선이라면 쇼핑몰 솔루션이 지원하는 PG를 활용하는 방식이 효율적인 경우가 많습니다. 반대로 현재 솔루션의 기능 한계가 명확하고 자체 주문·정산 구조가 필요하다면 독립적인 PG 연동을 검토할 가치가 커집니다.

다만 ‘솔루션 결제 = 플랫폼과 계약’, ‘PG 직접 계약 = 무조건 저렴’처럼 단순화하지 않습니다.

먼저 신청 경로, PG 계약/MID, 정산·취소 처리 위치, 이전 가능성을 확인하고 그다음 실제 견적과 개발 부담을 비교하는 순서가 안전합니다.

공식 참고자료

• 토스페이먼츠 전자결제서비스 신청 가이드
• 토스페이먼츠 결제제품·연동 가이드
• 토스페이먼츠 API 키 가이드
• 카페24 통합결제(PG) 이전·신청 가이드
• 카페24 PG 연동 관리
• NHN커머스 전자결제(PG)
• 금융위원회 영세·중소가맹점 우대수수료 안내