온라인 PG 연동 방식,
모듈 · API · 링크 중 하나

빌더는 지원되는 신청 경로부터 확인합니다. 호스팅형 쇼핑몰이나 사이트 빌더는 미리 연결된 결제 기능을 설정하는 방식이 많습니다. 지원 PG와 요금제, 신청 경로가 제품마다 다를 수 있으므로 외부 계약을 먼저 맺기 전에 현재 관리자에서 연결 가능한 범위를 확인합니다. 플랫폼 제품명과 신청한 서비스, 접수번호 · 진행 단계와 필요한 결제 기능을 준비합니다.

같은 회사의 홈페이지 빌더와 쇼핑몰 솔루션도 지원 범위가 다를 수 있으므로 브랜드 이름만 말하기보다 사용 중인 제품을 알려 주세요. 특정 PG와 직접 계약했다고 해서 모든 빌더에 그 계약을 그대로 연결할 수 있는 것은 아닙니다. 관리자의 전자결제 안내를 확인하고 지원되는 서비스인지 문의한 뒤 신청 · 설정을 진행합니다. 발급된 상점 정보가 실제 사용할 사이트와 같은 계약을 가리키는지 점검합니다.

링크 결제도 판매 내용과 계약 확인이 필요합니다. 링크나 청구서 방식은 큰 쇼핑몰을 만들지 않고도 특정 거래의 결제 화면을 안내하는 구성입니다. 누가 무엇을 얼마에 판매하는지와 제공 · 취소 기준은 여전히 필요하며 계약에서 허용된 사용 범위 안에서 운영합니다. 청구 식별자와 품목 · 금액, 유효기간과 재발급 규칙을 정리합니다.

예약 날짜가 확정된 서비스는 예약번호와 연결한 링크를 보내고 결제 확인 후 예약 상태를 바꾸는 식으로 운영할 수 있습니다. 링크의 전달 방식이나 QR 표시가 가능하다는 점이 특정 업종 · 판매 방식의 심사 면제를 뜻하지는 않습니다. 링크 발급 기능의 지원 여부를 확인한 뒤 품목 · 금액 · 유효기간을 입력해 발급합니다. 완료된 청구의 재결제 가능 여부와 만료 후 화면, 실제 승인 기록을 확인합니다. 고객의 입금 메시지 대신 관리 화면의 실제 승인 결과로 결제 완료를 확인합니다.

자료가 완성된 시점부터 다음 단계를 확인합니다. 준비에 걸리는 시간과 기관 · 서비스의 검토 시간은 구분해야 합니다. 사이트가 아직 열리지 않거나 서류 발급이 남았다면 그 작업의 완료가 선행될 수 있어 신청일 하나만으로 전체 일정이 결정되지는 않습니다. 신청 · 계약 · 개발 · 운영 담당자와 연락 경로, 각자가 준비할 자료를 정리합니다.

희망 오픈일이 정해져 있다면 그날 필요한 수단과 기능부터 우선순위를 정해 준비 범위를 구체적으로 상의할 수 있습니다. 공개 안내의 일반적인 소요일을 해당 사업자의 확정 일정으로 사용하지 않습니다. 대기 중 처리할 수 있는 작업과 승인 후에만 진행할 수 있는 일을 나누어 일정표를 만듭니다. 오픈 전에 모든 담당자가 승인 조회 · 취소 · 장애 문의의 흐름을 이해하는지 확인합니다. 담당자에게 단계별 상태와 다음 제출 항목을 확인하고 기록을 갱신합니다.

개발비는 구현할 결과를 기준으로 비교합니다. API 연동 견적은 결제창 표시뿐 아니라 결과 검증 · 주문 상태 · 취소 · 오류 · 운영 인수인계 범위를 포함해 읽어야 합니다. 어느 작업이 빠져 있는지 확인하면 낮은 초기 견적 뒤에 필요한 추가 작업을 파악하기 좋습니다. 관리자 경로와 거래 식별값, 실패 · 취소 · 정산 문의 절차 및 담당 연락처를 정리합니다.

완료 페이지 표시만 포함된 견적이라면 결과 수신과 금액 검증이 별도인지 먼저 물어보고 범위를 맞추는 것이 좋습니다. 개발 기간과 비용은 사이트 환경과 요구 기능에 따라 달라지므로 보편적인 단가나 날짜를 임의로 제시하지 않습니다. 개발 견적에서 구현 범위와 시험 · 수정 · 유지 지원을 나누어 확인합니다. 권한과 문서가 최신 상태이고 퇴사자 · 외주 업체의 불필요한 접근이 회수됐는지 확인합니다. 납품 결과가 실제 승인 · 취소 · 모바일 복귀까지 검증되었는지 확인합니다.

새로운 경로도 실제 거래에 맞아야 합니다. 현재 방식이 맞지 않으면 지원되는 다른 연동 · 청구 방법을 검토할 수 있습니다. 다만 방식 변경은 실제 상품과 판매 책임 · 제공 흐름을 유지하면서 이루어져야 하며 필요한 계약 확인을 함께 진행합니다. 현재 사이트 제작 방식과 개발 인력, 필요한 자동화 수준과 주문량을 적습니다.

개발 인력이 부족해 API 구현이 어렵다면 현재 플랫폼에서 지원되는 설정형 기능이나 청구서 방식의 적합성을 확인할 수 있습니다. 승인 제한을 감추거나 다른 품목으로 결제하는 방식을 대안으로 사용하지 않습니다. 모듈 · API · 링크 등 지원되는 대안의 준비 · 운영 범위를 비교합니다. 시험 결과와 인수인계 자료를 확인한 뒤 실제 지원 범위로 개통합니다. 선택한 방식에서 고객 안내와 취소 · 정산이 관리 가능한지 시험합니다.

서버가 결제 결과를 확인해야 주문이 끝납니다. 개발형 연동은 결제창을 띄우는 코드 외에도 주문 저장, 금액 검증, 승인 결과 확인과 상태 변경을 포함합니다. 고객 화면의 성공 표시만 믿지 않고 서버가 확인한 거래를 기준으로 상품 제공 여부를 결정해야 합니다. 수신 주소와 인증 · 검증 방식, 거래 식별값과 주문 상태 규칙을 정리합니다.

통신이 잠시 끊긴 뒤 고객이 다시 눌러도 이미 처리한 거래를 반복 반영하지 않도록 조회와 중복 처리 방지를 함께 설계합니다. 실제 API 필드와 호출 순서는 선택한 서비스의 공식 문서에 맞춰 구현하며 다른 PG의 코드를 그대로 대입하지 않습니다. 주문 생성부터 결제 요청 · 결과 검증 · 상태 저장을 연결하고 실패 또는 재요청 경로도 구현합니다. 결과가 여러 번 도착하거나 순서가 달라도 주문이 중복 처리되지 않는지 확인합니다.

연동 방식은 유지할 수 있는 범위로 고릅니다. 설정형 모듈, 개발형 API와 링크 청구는 주문 정보가 만들어지고 결과를 관리하는 방식이 다릅니다. 처음 붙이는 비용 외에 담당자가 취소 · 오류 · 변경을 처리할 수 있는지도 함께 보면 선택이 더 분명해집니다. PG 제공 기능과 빌더 · 개발사의 담당 작업, 사업자 운영 업무를 나누어 적습니다.

건별 상담 뒤 대금이 확정되는 서비스는 링크 청구가 맞을 수 있고 재고 · 배송 자동 처리가 중요하면 주문 시스템 연동이 필요할 수 있습니다. 어느 방식이 언제나 저렴하거나 빠르다고 단정하지 않고 현재 환경과 지원되는 조건으로 비교합니다. 각 방식의 신청 · 개발 · 운영 역할을 나누어 누가 무엇을 맡을지 정합니다. 어느 단계도 담당자 없이 빠져 있지 않고 실패 시 문의할 경로가 있는지 확인합니다. 시험 결과와 인수인계 자료를 확인한 뒤 실제 지원 범위로 개통합니다.

신청 경로가 다르면 연결 조건도 확인합니다. 빌더 안에서 신청하는 계약과 외부에서 직접 신청하는 계약은 지원 기능이나 연결 방식에 차이가 있을 수 있습니다. 이미 진행한 신청이 있다면 중복 계약을 시작하기 전에 현재 상태와 사용하려는 플랫폼을 먼저 확인합니다. 현재 계약명과 상품 · 버전, 필요한 기능과 공식 도움말 주소를 정리합니다.

결제 기능이 있는 빌더를 쓰면서 외부 계약도 검토한다면 먼저 외부 가맹점 연결을 지원하는지 확인해 불필요한 신청을 줄일 수 있습니다. 신청 경로가 다르다는 이유만으로 한쪽 조건이 항상 유리하거나 기능이 같다고 단정하지 않습니다. 현재 계약을 연결할 수 있는지와 새 신청이 필요한지를 공식 안내에 맞춰 확인합니다. 받은 답과 실제 설정 · 계약 문서가 같은 범위를 가리키는지 확인합니다. 발급된 상점 정보가 실제 사용할 사이트와 같은 계약을 가리키는지 점검합니다.

설정과 운영 책임을 문서로 넘깁니다. 개발이 끝난 뒤 담당자가 바뀌더라도 결제 운영을 이어갈 수 있어야 합니다. 비밀 값을 문서에 그대로 적는 대신 보관 위치와 접근 권한, 장애 · 취소 · 정산 문의 방법과 변경 절차를 남기는 것이 좋습니다. 관리자 경로와 거래 식별값, 실패 · 취소 · 정산 문의 절차 및 담당 연락처를 정리합니다.

외주 업체가 개발한 경우에도 계약 종료 뒤 도메인 · 서버 · 관리자에 접근할 사람이 누구인지 미리 정해 두면 운영 공백을 줄일 수 있습니다. 인수인계 문서를 공개 저장소에 올리거나 비밀번호 · 비밀키를 평문으로 공유하지 않습니다. 시험 결과와 운영 전환 기록을 전달하고 실제 운영자가 조회 · 취소 작업을 따라 해 보게 합니다. 권한과 문서가 최신 상태이고 퇴사자 · 외주 업체의 불필요한 접근이 회수됐는지 확인합니다. 권한 회수와 키 변경이 필요한 인력 · 업체 변경 시나리오를 확인합니다.

시험용 키와 운영용 키를 분리합니다. 시험 환경의 성공은 실제 가맹점이 모든 결제 수단을 사용할 수 있다는 의미가 아닙니다. 계약 상태와 운영 상점의 권한, 환경별 키와 연결 주소를 구분해야 시험 결과를 운영 판단에 잘못 섞지 않을 수 있습니다. 접속 도메인과 인증서, 키 저장 위치, 관리자 목록과 접근 권한을 확인합니다.

개발자가 시험키로 만든 주문 화면을 넘겼다면 운영키 교체뿐 아니라 결과 수신 주소와 사용 수단도 함께 검토해야 합니다. 비밀키를 화면 코드 · 공개 저장소 · 상담 메시지에 붙이지 말고 노출이 의심되면 폐기 · 재발급 절차를 진행합니다. 브라우저에 공개 가능한 값과 서버에서만 보관할 비밀 값을 공식 문서에 따라 나눠 설정합니다. 공개 코드 · 기록 · 화면에 비밀 값이 없는지, 퇴사자 권한이 회수됐는지 점검합니다. 운영 전환 후 거래가 의도한 가맹점의 관리 화면에 나타나는지 확인합니다.