쇼핑몰 PG 상담,
주소 하나면 시작됩니다

주문과 고객 정책이 같은 상품을 설명해야 합니다. 쇼핑몰에서 사업자 표시 · 상품 상세 · 주문서와 배송 · 환불 정책이 다른 내용을 담으면 고객과 검토 담당자가 거래를 이해하기 어렵습니다. 공통 문구를 채워 넣기보다 실제 판매 품목과 운영 방식에 맞춰 연결합니다. 대표 상품별 구성과 옵션, 판매 가격 · 추가 비용, 제공 · 배송 안내를 준비합니다.

예약 판매 상품을 일반 즉시 출고 상품과 같이 안내하지 않고 예정 출고일과 변경 시 문의 방법을 구분하면 거래 설명이 분명해집니다. 심사에 보여 주는 화면과 실제 고객에게 판매하는 화면을 다르게 운영하지 않습니다. 고객이 구매하는 순서대로 화면을 따라가며 서로 다른 금액 · 표현 · 일정을 수정합니다. 심사에 전달한 상품과 운영 중 노출되는 상품이 일치하는지 확인합니다. 모바일에서도 필수 안내와 문의 경로를 찾을 수 있는지 확인합니다.

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

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

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

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

승인과 취소를 한 묶음으로 시험합니다. 결제 기능은 성공 화면이 한 번 나타났다고 점검이 끝나지 않습니다. 승인, 취소, 실패, 결과 알림, 주문 상태와 모바일 복귀를 이어서 확인해야 고객이 실제로 사용하는 흐름과 관리자 업무를 함께 점검할 수 있습니다. 날짜 · 시각, 환경, 주문번호와 거래 식별값, 예상 · 실제 결과를 적을 양식을 준비합니다.

승인은 되었는데 주문이 미결제로 남는 경우에는 고객에게 다시 결제하도록 안내하기 전에 원거래 결과를 먼저 조회합니다. 실결제 시험은 실제 돈이 움직이는 거래이므로 담당자 허가와 서비스의 시험 안내에 따라 범위를 정합니다. 시험 환경에서 성공과 실패를 확인한 뒤 승인된 운영 환경에서 안내된 소액 거래를 수행합니다. 수정 후 같은 조건으로 다시 확인한 결과와 처리 담당자를 덧붙입니다. 소액 실거래를 했다면 취소 결과와 주문 상태, 정산 반영 여부까지 확인합니다.

명세는 거래 · 취소 · 비용 · 입금 순서로 읽습니다. 정산 화면마다 열 이름과 기간 선택 방법이 다를 수 있지만 먼저 무엇을 합산하고 무엇을 차감했는지를 찾으면 읽기 쉬워집니다. 원거래와 취소 · 조정 건을 연결한 뒤 실제 지급액을 마지막에 확인합니다. 자료마다 사용하는 날짜 필드와 조회 시간대, 마감 기준을 확인합니다.

한 계좌로 여러 채널의 돈이 들어온다면 날짜만 보고 합치지 말고 가맹점과 정산 회차를 기준으로 나눠 대조합니다. 화면 합계와 내려받은 파일의 기준일이 다를 수 있으므로 같은 조회 조건인지 먼저 확인합니다. 거래 합계를 맞춘 뒤 취소 · 기타 조정을 확인하고 비용 산식을 검토합니다. 원거래를 다음 달 자료와 연결해 중복 집계나 누락이 없는지 대조합니다. 명세의 지급액과 통장 내역이 다른 경우 이월 · 분할 입금 · 다른 가맹점 거래가 섞였는지 살핍니다.

새 환경을 검증한 뒤 기존 결제를 전환합니다. PG 변경에는 신규 계약과 연동 외에도 이전 거래의 정산, 취소 · 환불과 데이터 조회가 연결됩니다. 새 결제창이 뜬다는 이유로 이전 계정을 바로 닫지 말고 전환일 전후 거래를 구분할 계획을 세웁니다. 기존 구독 상태와 다음 청구일, 사용 중인 식별정보와 신규 서비스 지원 범위를 정리합니다.

오전 주문은 기존 PG, 오후 주문은 새 PG에 남을 수 있으므로 주문별 사용 서비스를 저장해 취소 업무를 이어 갑니다. 이전 빌링키나 거래 이력이 자동으로 이전된다고 가정하지 말고 지원 여부와 재동의 필요성을 확인합니다. 새 환경의 시험을 끝낸 뒤 전환 시각과 담당자, 되돌릴 조건을 정해 설정을 변경합니다. 전환 기간에 각 고객이 한 경로에서만 청구되고 해지 요청도 올바르게 반영되는지 시험합니다.

첫 상담은 상황을 좁히는 정보부터 시작합니다. 처음부터 모든 계약 서류를 보내기보다 무엇을 판매하고 어떤 경로로 결제를 받으려는지 설명하면 다음 확인이 빨라집니다. 현재 막힌 단계와 이전 안내가 있다면 사실 그대로 알려 주면 준비 범위를 나누기 좋습니다. 상호 · 업종과 연락 가능한 번호, 운영 사이트 또는 판매 방식의 개요를 정리합니다.

이미 계약 견적을 받았다면 금액만 말하기보다 확인하고 싶은 비용 · 정산 · 지원 항목을 알려 주면 비교할 범위가 구체적이 됩니다. 첫 문의란에는 카드번호 · 비밀번호 · 신분증 같은 자료를 적지 말고 필요한 경우 안내된 안전한 제출 경로를 이용합니다. 현재 상황과 희망 일정을 전달하고 추가 자료가 필요한 항목과 공식 제출 경로를 안내받습니다. 전달한 자료의 접수와 다음 진행 순서를 확인해 기록합니다. 다음 작업의 담당자 · 자료 · 순서를 확인해 상담 뒤에도 이어갈 수 있게 기록합니다.

지원 카드 안내는 현재 범위로 표시합니다. 고객이 사용할 수 있는 카드와 수단은 신청한 서비스와 개통 상태에 따라 확인해야 합니다. 지원되지 않는 수단을 먼저 크게 안내하기보다 실제 가능한 범위를 주문 전에 알 수 있도록 정리합니다. 신청한 수단과 카드사별 검토 상태, 보완 항목과 운영 설정을 준비합니다.

베스트페이 현재 안내에서는 롯데카드를 제외하므로 고객 문의와 상담 과정에서도 같은 기준으로 설명합니다. 카드사별 지원 정책이 달라질 수 있으므로 오래된 화면이나 외부 사례를 현재 개통 상태로 대신하지 않습니다. 노출할 버튼과 안내 문구를 실제 범위에 맞추고 변경 시 관련 화면도 갱신합니다. 주문서 표시와 실제 승인 가능 범위, 고객 문의 안내가 일치하는지 점검합니다. 첫 주문 시험에서 상호 · 금액 · 수단이 맞고 취소까지 조회 가능한지 확인합니다.

구두 안내와 서면 조건을 한 줄씩 맞춥니다. 계약에서 볼 내용은 수단별 비용, 정산 일정, 유보 · 담보, 지원 범위, 계약 기간과 종료 조건입니다. 광고나 상담 중 들은 표현을 기억하는 것보다 실제 서명할 문서에서 같은 조건을 찾는 작업이 중요합니다. 최종 계약서와 약정, 견적 적용 확인 및 변경 합의 자료를 모읍니다.

월 이용료가 없다고 안내받았다면 최소 이용료나 부가 기능 비용도 없는 의미인지 항목을 나누어 확인해 두면 좋습니다. 계약 문구의 효력이나 분쟁에 대한 판단이 필요하면 해당 문서를 바탕으로 전문가 또는 계약 상대방의 확인을 받습니다. 항목별로 금액 · 산식 · 시점 · 예외를 표시하고 문서끼리 다른 곳은 서명 전에 질문합니다. 초안과 달라진 비용 · 기간 · 예외가 있는지 최종본을 다시 대조합니다. 질문에 대한 답이 계약 문서 또는 확인 가능한 서면에 반영되었는지 확인합니다.

지원 수단은 계약과 고객의 사용 흐름으로 고릅니다. 어떤 결제 수단을 먼저 열지는 주로 사용하는 고객 환경, 주문 금액과 입금 확인 업무에 따라 달라집니다. 수단별로 신청과 심사, 취소 · 정산 조건이 다를 수 있으므로 버튼 개수보다 운영할 수 있는 구성을 먼저 정합니다. 주요 고객 환경과 요청 수단, 주문 금액 · 건수 및 관리 인력을 정리합니다.

가상계좌를 도입하면 발급과 입금 완료를 구분해야 하므로 출고 담당자가 두 상태를 혼동하지 않게 표시하는 편이 좋습니다. 베스트페이의 현재 안내에서는 롯데카드가 제외되며 지원 범위와 변경 사항은 실제 신청 시 확인합니다. 계약에서 지원하는 수단과 추가 신청이 필요한 수단을 나눠 도입 순서를 잡습니다. 추가 이후 결제 완료와 취소 · 문의, 정산 관리에 문제가 없는지 점검합니다. 노출한 수단이 실제 승인된 설정과 일치하고 취소 · 정산까지 확인 가능한지 시험합니다.