자체 쇼핑몰 PG 연동,
모듈이든 API 든 같습니다

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

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

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

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

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

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

청구액은 서버의 주문 금액과 맞춥니다. 고객 화면에서 전달된 금액은 조작되거나 오래된 값일 수 있어 서버가 보관한 최종 주문 금액과 대조해야 합니다. 할인 · 배송비 계산과 재고 · 옵션을 확정한 뒤 승인 결과를 검증해 실제 주문에 반영합니다. 주문번호, 상품 구성, 최종 청구액, 결제 식별값과 상태를 저장할 항목을 정합니다.

주문서가 열린 동안 상품 가격이나 쿠폰 조건이 바뀌었다면 최종 확정 금액을 고객에게 보여 주고 동일한 값으로 처리해야 합니다. URL이나 브라우저의 성공 표시만 믿고 금액 검증 없이 상품을 제공하지 않습니다. 서버에 보관한 주문과 결제 요청 · 결과의 금액을 비교하고 불일치는 승인 · 제공 흐름에서 분리합니다. 같은 주문의 중복 요청, 금액 불일치와 이미 취소된 거래가 걸러지는지 시험합니다. 같은 주문의 반복 요청과 가격 변경 후 재시도에서도 검증이 유지되는지 시험합니다.

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

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

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

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

결과 수신과 주문 상태 변경을 함께 검증합니다. PG에서 승인 결과를 받는 것과 사이트의 주문을 완료로 바꾸는 것은 연결된 별도 작업입니다. 결과를 검증하고 거래를 저장한 뒤 고객 · 운영자가 같은 상태를 볼 수 있도록 처리해야 합니다. 이벤트 종류, 수신 주소, 거래 조회 방법과 재처리 기준을 정리합니다.

승인 알림은 왔는데 주문이 대기로 남았다면 수신 로그와 저장 · 상태 변경 과정에서 멈춘 지점을 찾아볼 수 있습니다. 수신 메시지가 있다는 사실만으로 내용을 신뢰하지 않고 해당 서비스의 검증 · 조회 절차를 따릅니다. 공식 SDK · API의 결과 처리 안내에 맞춰 서버에서 검증 · 저장 · 상태 변경을 수행합니다. 가상계좌 입금처럼 시간이 지난 뒤 들어오는 결과도 주문 상태에 반영되는지 확인합니다. 결과가 여러 번 도착하거나 순서가 달라도 주문이 중복 처리되지 않는지 확인합니다.

주문번호와 결제 식별값을 연결해 둡니다. 주문은 고객이 무엇을 사기로 했는지에 대한 기록이고 결제는 그 대금이 처리된 기록입니다. 한 주문에 재시도나 부분 취소가 붙을 수 있으므로 번호 하나만으로 두 기록을 같은 것으로 취급하지 않는 것이 좋습니다. 옵션별 구성과 추가 금액, 배송 · 설치 등 부대 비용과 최종 합계를 정리합니다.

고객이 뒤로 가기를 누른 뒤 재결제한 경우에도 각 시도와 최종 유효 거래를 구분하면 문의 대응이 쉬워집니다. 카드번호와 비밀번호를 주문 정보에 직접 저장하는 방식 대신 승인된 결제 서비스가 제공하는 식별자를 사용합니다. 할인 · 배송비 계산이 끝난 금액을 서버에 보관하고 승인 요청과 결과를 그 주문에 연결합니다. 결제 결과에 저장된 금액과 주문 구성, 고객에게 보이는 설명이 맞는지 시험합니다. 같은 주문의 중복 요청, 금액 불일치와 이미 취소된 거래가 걸러지는지 시험합니다.

완료 페이지는 확인된 주문 상태를 보여 줍니다. 결제창이 닫힌 뒤 고객이 무엇을 샀고 결제가 어떤 상태인지 이해할 수 있어야 합니다. 완료 페이지는 결제를 승인하는 수단 자체가 아니므로 서버에서 확인한 결과와 주문 정보를 가져와 안내하도록 구성합니다. 승인 · 입금 대기 · 취소 접수 · 취소 완료 등 운영 상태별 안내 문구를 준비합니다.

가상계좌가 발급된 단계에서는 결제 완료라고 표시하기보다 입금 대기와 기한을 안내해 출고 판단을 구분합니다. URL에 성공이라는 값이 들어 있다는 이유만으로 상품을 제공하지 말고 서버에 저장된 상태를 기준으로 처리합니다. 주문번호와 결제 상태를 보여 주고 배송 · 예약 등 다음 행동을 실제 상품 흐름에 맞춰 안내합니다. 안내 시점의 상태와 실제 관리자 기록, 고객 조회 화면이 같은지 대조합니다. 새로고침하거나 주소를 다시 열어도 같은 주문이 중복 생성되지 않는지 확인합니다.

업데이트 후 결제 흐름을 다시 확인합니다. 빌더 · 플러그인 · SDK가 바뀌면 화면은 같아 보여도 인증 · 복귀 · 결과 처리에 영향이 있을 수 있습니다. 공식 지원 버전과 변경 내용을 확인하고 운영 전후에 중요한 거래 흐름을 시험할 계획을 세웁니다. 계정 · 인증서 · 연동 버전과 운영 정책의 관리 담당자를 정리합니다.

워드프레스 등에서 여러 플러그인을 함께 쓰면 결제 기능과 충돌하는지 실제 주문서에서 확인해야 합니다. 확인하지 않은 외부 스크립트나 플러그인을 추가해 결제 데이터를 불필요하게 전달하지 않습니다. 시험 환경에서 업데이트를 검토하고 승인 · 취소 · 모바일 복귀가 정상인지 확인한 뒤 적용합니다. 담당자가 바뀌어도 권한과 문서, 문의 창구가 이어지는지 확인합니다. 변경 뒤 첫 거래와 오류 기록을 점검하고 필요하면 안내된 방법으로 조치합니다.