온라인 PG 보안,
네 가지 기본만 지키면

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

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

인증서의 갱신과 연결 주소를 같이 관리합니다. 암호화 연결은 고객과 사이트 사이의 통신을 보호하는 기본 조건입니다. 대표 도메인만 접속되는지 살피기보다 결제 결과 주소와 하위 도메인, 모바일 접속 및 인증서 갱신이 유지되는지도 확인합니다. 계정 · 인증서 · 연동 버전과 운영 정책의 관리 담당자를 정리합니다.

대표 도메인을 바꾼 뒤 결제 결과 수신 주소가 이전 주소로 남으면 보안 연결은 되더라도 주문 상태가 반영되지 않을 수 있습니다. SSL 인증서가 있다는 사실만으로 결제 시스템 전체의 보안 수준이나 심사 결과를 단정하지 않습니다. HTTPS로 연결되는 주소를 기준으로 설정하고 혼합 콘텐츠나 리디렉션 오류를 확인합니다. 담당자가 바뀌어도 권한과 문서, 문의 창구가 이어지는지 확인합니다. 만료 전 갱신 뒤에도 주문 · 인증 · 복귀 경로가 정상적으로 동작하는지 시험합니다.

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

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

관리자 권한은 업무 단위로 나눕니다. 결제 관리자에는 매출 · 고객 기록과 환불 등 중요한 기능이 모일 수 있습니다. 모든 직원이 같은 계정을 쓰기보다 조회, 취소 · 환불과 설정 변경의 필요 범위를 나누어 운영하는 편이 기록을 남기기 좋습니다. 사이트 · PG · 플랫폼 관리자 주소와 역할별 계정, 조회할 항목을 목록으로 적습니다.

고객 응대 담당자는 주문 상태 조회가 필요하지만 비밀키 교체나 정산 계좌 변경 권한까지 필요하지 않을 수 있습니다. 서비스별 권한 기능이 다를 수 있어 제공 범위를 확인하고 공유 계정이 불가피하면 관리 책임과 기록 방법을 정합니다. 개별 계정과 최소 권한을 부여하고 지원되는 경우 다중 인증을 설정합니다. 퇴사 · 업체 변경 때 계정 회수와 담당자 교체가 가능한지 확인합니다. 인력 변경 시 접근을 회수하고 취소 · 설정 변경 이력을 정기적으로 확인합니다.

의심 상황에서는 거래 보존과 접근 차단을 나눕니다. 보안 문제가 의심될 때는 원인을 단정하기보다 영향을 받은 기능과 거래를 확인합니다. 필요한 접근을 제한하되 거래 · 로그를 무작정 지워서 조사와 고객 대응에 필요한 근거를 잃지 않도록 순서를 정합니다. 발생 시각 · 환경 · 수단과 오류 문구, 관련 주문 · 결제 식별값을 확보합니다.

오류 화면에 비밀 값이 나타났다면 게시물 삭제만으로 끝내지 않고 해당 값의 폐기 · 재발급 여부를 확인해야 합니다. 개인정보 침해 통지 · 신고 등 법적 대응은 실제 사고 범위와 적용 규정을 확인해 진행합니다. 비밀 정보 노출이나 계정 침해가 의심되면 담당자와 서비스 창구에 알리고 키 · 접근 권한을 조정합니다. 조치 후 해당 흐름을 다시 시험하고 고객 안내와 주문 상태를 맞춥니다. 관련 결제와 환불 상태를 다시 조회하고 복구 후 같은 문제가 재현되는지 점검합니다.

비밀 정보는 서버와 제한된 계정에서 관리합니다. 결제 보안은 HTTPS만 켜는 것으로 끝나지 않습니다. 비밀키 보관, 금액 검증, 관리자 권한과 로그에 남는 정보를 함께 확인해야 개발과 운영 과정에서 민감한 값이 불필요하게 노출되는 일을 줄일 수 있습니다. 자료를 쓰는 목적과 필요한 항목, 공유 대상 · 보관 위치 · 접근 권한을 정합니다.

문의 해결을 위해 화면을 공유할 때에도 비밀키와 고객 개인정보는 가린 뒤 오류 코드와 거래 식별값 중심으로 전달합니다. 노출이 의심되면 화면만 지우고 끝내지 말고 키 폐기 · 재발급과 관련 접근 기록 확인을 함께 진행합니다. 환경 변수나 비밀 저장소로 키를 분리하고 필요한 담당자에게만 권한을 부여합니다. 파일 공유 범위와 보관 종료 시 처리 방법이 운영 기준에 맞는지 확인합니다. 공개 코드 · 기록 · 화면에 비밀 값이 없는지, 퇴사자 권한이 회수됐는지 점검합니다.

운영 자료에는 필요한 정보만 남깁니다. 결제 통계나 오류 확인에 고객의 전체 개인정보가 항상 필요한 것은 아닙니다. 주문 식별자와 상태 · 금액 등 필요한 항목으로 목적을 달성하고 더 자세한 정보는 권한이 있는 담당자만 확인하도록 정리합니다. 누가 어떤 사유로 요구했는지와 공식 제출 방식, 필요한 서류 범위를 확인합니다.

개발사에 오류를 문의할 때에는 고객 이름 · 전화번호 전체보다 거래 식별값과 발생 시각 · 오류 내용이 필요한 경우가 많습니다. 처리 목적과 법적 보관 의무를 확인하지 않은 채 모든 자료를 무기한 저장하거나 공개 링크로 공유하지 않습니다. 외부 전달용 자료에서는 불필요한 개인 식별정보를 줄이고 원자료와 분리해 관리합니다. 접수 결과와 제출한 자료 목록을 기록하고 불필요한 중복 전송을 줄입니다. 파일 공유 범위와 보관 종료 시 처리 방법이 운영 기준에 맞는지 확인합니다.

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

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

필요한 관리자 화면을 역할별로 준비합니다. 결제 설정과 주문 처리, 정산 확인이 서로 다른 관리자에서 이루어질 수 있습니다. 운영자가 어떤 화면에 들어가야 하는지와 각 화면에서 확인할 정보를 정리하면 개통 뒤 문의를 줄이기 좋습니다. 담당자 목록과 필요한 업무, 사용 중인 인증 수단을 정리합니다.

사이트 관리자에는 주문이 보이고 PG 관리자에는 실제 승인이 보인다면 주문번호와 거래 식별값을 연결해 두 화면을 대조할 수 있어야 합니다. 공통 비밀번호를 문서에 그대로 남기거나 불필요한 사람에게 관리자 권한을 공유하지 않습니다. 개별 담당자 권한을 설정하고 승인 · 취소 · 정산 조회 경로를 직접 따라 합니다. 인력 변경 시 접근을 회수하고 취소 · 설정 변경 이력을 정기적으로 확인합니다. 퇴사 · 업체 변경 때 계정 회수와 담당자 교체가 가능한지 확인합니다.

민감 서류는 공식 제출 경로로 전달합니다. 신분증 · 계좌 · 인감 등 자료는 신청에 필요한 경우에도 전달 범위와 보관을 신경 써야 합니다. 일반 상담 단계와 실제 계약 서류 접수를 구분하고 요청 주체 · 항목 · 제출 주소가 맞는지 확인한 뒤 전달합니다. 자료를 쓰는 목적과 필요한 항목, 공유 대상 · 보관 위치 · 접근 권한을 정합니다.

처음 문의할 때는 사업 유형과 필요한 기능만 설명하고 민감 자료는 계약 진행에 필요한 공식 안내를 받은 뒤 제출할 수 있습니다. 비밀번호 · 인증번호 · 비밀키를 계약 확인 서류인 것처럼 요청받으면 공식 담당 창구에서 진위를 확인합니다. 지정된 보안 경로로 제출하고 일반 게시판이나 공개 공유 링크에 자료를 올리지 않습니다. 파일 공유 범위와 보관 종료 시 처리 방법이 운영 기준에 맞는지 확인합니다. 접수 결과와 제출한 자료 목록을 기록하고 불필요한 중복 전송을 줄입니다.