CHAPTER 01
빌더 기본 PG vs 직접 계약
쇼핑몰 빌더 PG 신청의 첫 확인입니다. 빌더 선택은 결제 지원까지 포함해 봅니다. 사이트를 새로 만들거나 옮길 때에는 화면 편집 기능 외에 필요한 PG와 결제 수단, 정기결제 · 취소 · 정산 관리 범위를 확인해야 합니다. 제작 이후에 지원되지 않는 기능을 발견하지 않도록 결제 요구사항을 먼저 정리합니다. 필요한 수단 · 청구 방식 · 주문 관리와 현재 계약, 개발 인력 유무를 적습니다. 플랫폼의 최신 지원 안내와 신청 경로를 확인하고 별도 개발 범위를 검토합니다. 전체 흐름은 쇼핑몰 PG 안내에서 함께 볼 수 있습니다.
간단한 소개 사이트와 재고 · 쿠폰 · 부분취소가 필요한 쇼핑몰은 필요한 결제 관리 기능이 다를 수 있습니다. 실제로 필요한 주문 · 취소 · 모바일 흐름을 시험할 수 있는지 확인합니다. 유명한 플랫폼이라는 이유로 모든 PG 계약과 부가 기능을 사용할 수 있다고 가정하지 않습니다. 플랫폼 기본 결제는 신청 · 설정이 연결되어 편리할 수 있고 직접 계약은 지원되는 범위에서 조건을 따로 검토할 수 있습니다. 어느 쪽이 맞는지는 실제 연결 가능성과 운영 담당 범위, 총비용을 같이 놓고 봐야 합니다.
- 필요한 수단 · 청구 방식 · 주문 관리와 현재 계약, 개발 인력 유무를 적습니다.
- 플랫폼의 최신 지원 안내와 신청 경로를 확인하고 별도 개발 범위를 검토합니다.
- 실제로 필요한 주문 · 취소 · 모바일 흐름을 시험할 수 있는지 확인합니다.
빌더 선택은 결제 지원까지 포함해 봅니다다음 장 · 카페24 — 신청 메뉴 · 준비물 ↓
CHAPTER 02
카페24 — 신청 메뉴 · 준비물
신청 메뉴는 사용하는 제품의 공식 안내로 찾습니다. 플랫폼의 전자결제 메뉴는 제품 · 버전 · 관리자 개편에 따라 위치나 이름이 달라질 수 있습니다. 오래된 경로를 그대로 따라가기보다 현재 쓰는 제품을 확인하고 관리자 검색 · 도움말의 전자결제 안내로 찾아갑니다. 빌더 이름과 상품 버전 · 요금제, 현재 관리자 화면을 확인합니다. 관리자 검색에서 PG 또는 전자결제 안내를 찾고 지원되는 신청 경로를 확인합니다. 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다.
카페24의 쇼핑몰과 별도 홈페이지 빌더는 같은 회사라도 신청 경로가 다를 수 있어 제품 이름을 구체적으로 알려 주면 좋습니다. 신청한 서비스와 발급받은 상점 정보가 현재 사이트에 연결되는지 점검합니다. 현재 확인하지 않은 메뉴 경로를 모든 사용자에게 동일하게 적용되는 사실로 게시하지 않습니다. 다른 서비스의 도움말은 용어를 이해하는 데 도움이 될 수 있지만 자신의 계약 조건을 확정하는 근거로 그대로 쓰면 안 됩니다. 현재 쓰는 PG와 플랫폼의 제품 · 버전 · 신청 경로에 맞는 안내를 확인합니다.
| 확인할 것 | 준비 · 확인 방법 | 판단 기준 |
|---|---|---|
| 자료 | 빌더 이름과 상품 버전 · 요금제, 현재 관리자 화면을 확인합니다 | 현재 계약명과 상품 · 버전, 필요한 기능과 공식 도움말 주소를 정리합니다 |
| 진행 | 관리자 검색에서 PG 또는 전자결제 안내를 찾고 지원되는 신청 경로를 확인합니다 | 관련 안내의 적용 대상을 확인하고 다른 부분은 담당자에게 문의합니다 |
| 결과 | 신청한 서비스와 발급받은 상점 정보가 현재 사이트에 연결되는지 점검합니다 | 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다 |
- 빌더 이름과 상품 버전 · 요금제, 현재 관리자 화면을 확인합니다.
- 관리자 검색에서 PG 또는 전자결제 안내를 찾고 지원되는 신청 경로를 확인합니다.
- 신청한 서비스와 발급받은 상점 정보가 현재 사이트에 연결되는지 점검합니다.
신청 메뉴는 사용하는 제품의 공식 안내로 찾습니다

CHAPTER 03
아임웹 · 식스샵
신청 경로가 다르면 연결 조건도 확인합니다. 빌더 안에서 신청하는 계약과 외부에서 직접 신청하는 계약은 지원 기능이나 연결 방식에 차이가 있을 수 있습니다. 이미 진행한 신청이 있다면 중복 계약을 시작하기 전에 현재 상태와 사용하려는 플랫폼을 먼저 확인합니다. 플랫폼 제품명과 신청한 서비스, 접수번호 · 진행 단계와 필요한 결제 기능을 준비합니다. 현재 계약을 연결할 수 있는지와 새 신청이 필요한지를 공식 안내에 맞춰 확인합니다. 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다.
결제 기능이 있는 빌더를 쓰면서 외부 계약도 검토한다면 먼저 외부 가맹점 연결을 지원하는지 확인해 불필요한 신청을 줄일 수 있습니다. 발급된 상점 정보가 실제 사용할 사이트와 같은 계약을 가리키는지 점검합니다. 신청 경로가 다르다는 이유만으로 한쪽 조건이 항상 유리하거나 기능이 같다고 단정하지 않습니다. 다른 서비스의 도움말은 용어를 이해하는 데 도움이 될 수 있지만 자신의 계약 조건을 확정하는 근거로 그대로 쓰면 안 됩니다. 현재 쓰는 PG와 플랫폼의 제품 · 버전 · 신청 경로에 맞는 안내를 확인합니다.
- 플랫폼 제품명과 신청한 서비스, 접수번호 · 진행 단계와 필요한 결제 기능을 준비합니다.
- 현재 계약을 연결할 수 있는지와 새 신청이 필요한지를 공식 안내에 맞춰 확인합니다.
- 발급된 상점 정보가 실제 사용할 사이트와 같은 계약을 가리키는지 점검합니다.
신청 경로가 다르면 연결 조건도 확인합니다다음 장 · 메이크샵 · 고도몰 ↓
CHAPTER 04
메이크샵 · 고도몰
정책 안내는 적용되는 서비스에서 확인합니다. 다른 서비스의 도움말은 용어를 이해하는 데 도움이 될 수 있지만 자신의 계약 조건을 확정하는 근거로 그대로 쓰면 안 됩니다. 현재 쓰는 PG와 플랫폼의 제품 · 버전 · 신청 경로에 맞는 안내를 확인합니다. 현재 계약명과 상품 · 버전, 필요한 기능과 공식 도움말 주소를 정리합니다. 관련 안내의 적용 대상을 확인하고 다른 부분은 담당자에게 문의합니다. 차이가 있으면 본인 계약의 적용 범위와 실제 설정을 기준으로 문서를 갱신합니다.
같은 플랫폼 회사라도 홈페이지 빌더와 쇼핑몰 제품의 PG 신청 메뉴 · 지원사가 다르면 해당 제품의 안내를 따르는 것이 맞습니다. 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다. 외부 자료의 일반 예시를 베스트페이의 확정 수수료나 모든 사업자의 개통 조건으로 옮기지 않습니다. 결제 서비스의 지원 수단과 신청 메뉴, 요금제 · 정산 조건은 바뀔 수 있습니다. 안내를 볼 때 현재 쓰는 제품과 계약에 적용되는지 다시 확인할 수 있도록 자료의 출처와 확인 날짜를 함께 기록하는 편이 좋습니다.
- 현재 계약명과 상품 · 버전, 필요한 기능과 공식 도움말 주소를 정리합니다.
- 관련 안내의 적용 대상을 확인하고 다른 부분은 담당자에게 문의합니다.
- 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다.
정책 안내는 적용되는 서비스에서 확인합니다다음 장 · 설정 뒤 적용 확인 ↓
CHAPTER 05
설정 뒤 적용 확인
신청 정보와 관리자 설정을 대조합니다. 계약에서 확인한 상점 정보가 실제 사이트의 설정과 다르면 승인 오류나 잘못된 상호 표시가 생길 수 있습니다. 사업자 · 가맹점 · 환경 · 수단을 한 번에 대조해 의도한 계약으로 거래가 처리되도록 맞춥니다. 계약 상점 정보와 사이트 주소, 시험 · 운영 설정 및 개통 수단 목록을 준비합니다. 공식 안내에 따라 값을 적용하고 오타 · 환경 혼용 · 이전 주소를 점검합니다. 첫 거래의 상호 표시와 관리자 조회 위치가 의도한 계약과 맞는지 확인합니다.
시험키를 운영 화면에 남기거나 다른 사이트의 상점 정보를 복사하지 않았는지 전환 전에 담당자가 함께 확인할 수 있습니다. 첫 거래를 조회해 올바른 가맹점과 금액 · 수단으로 기록되는지 확인합니다. 설정값이 저장되었다는 결과만으로 개통과 실제 거래 검증이 끝났다고 판단하지 않습니다. 같은 상호로 여러 사이트나 결제 서비스를 운영하면 가맹점 식별값과 관리자 계정을 혼동하기 쉽습니다. 어느 계약의 매출인지, 어떤 사이트가 연결되었는지를 정리해 두면 승인 오류와 정산 대조를 줄일 수 있습니다.
- 계약 상점 정보와 사이트 주소, 시험 · 운영 설정 및 개통 수단 목록을 준비합니다.
- 공식 안내에 따라 값을 적용하고 오타 · 환경 혼용 · 이전 주소를 점검합니다.
- 첫 거래를 조회해 올바른 가맹점과 금액 · 수단으로 기록되는지 확인합니다.
신청 정보와 관리자 설정을 대조합니다다음 장 · 빌더 이전 시 유지 ↓
CHAPTER 06
빌더 이전 시 유지
플랫폼 이전과 PG 계약 이전을 나누어 봅니다. 쇼핑몰 데이터를 새 빌더로 옮기는 작업과 결제 계약을 새 환경에 연결하는 작업은 별개일 수 있습니다. 기존 계약의 재사용 지원 여부, 주문 · 정기결제 이력과 취소 · 정산 업무가 어떻게 이어지는지 확인합니다. 기존 · 신규 플랫폼과 계약 정보, 도메인 · 주문 데이터 및 남은 거래를 정리합니다. 새 플랫폼의 지원 경로로 연결 가능 여부를 확인하고 필요하면 신규 신청을 진행합니다. 전환 전후 주문이 각각 맞는 계약으로 처리되고 담당자가 구분해 조회할 수 있는지 확인합니다.
상품 데이터가 옮겨졌어도 기존 결제의 취소 권한이나 빌링키가 새 관리자에 자동 반영되는 것은 아닐 수 있습니다. 새 주문과 과거 거래의 조회 · 취소 · 정산 경로가 각자 유지되는지 검증합니다. 같은 PG 이름이 보인다는 이유만으로 모든 계약 · 이력 · 기능을 그대로 유지할 수 있다고 가정하지 않습니다. 사이트 제작 도구나 판매 채널을 바꾸면 화면뿐 아니라 주문 상태, 결제 계약과 취소 · 정산 업무가 영향을 받을 수 있습니다. 기존에 처리한 거래와 앞으로 받을 거래를 구분해 이전 범위를 계획합니다.
- 기존 · 신규 플랫폼과 계약 정보, 도메인 · 주문 데이터 및 남은 거래를 정리합니다.
- 새 플랫폼의 지원 경로로 연결 가능 여부를 확인하고 필요하면 신규 신청을 진행합니다.
- 새 주문과 과거 거래의 조회 · 취소 · 정산 경로가 각자 유지되는지 검증합니다.
플랫폼 이전과 PG 계약 이전을 나누어 봅니다

