PG 심사 거절·반려됐을 때｜원인 확인·보완·재심사 6단계

PG 심사가 반려되면 바로 다른 PG부터 찾지 마세요. 먼저 반려 문구를 ‘서류·정보 / 사이트·상품 / URL·결제창 / 업종·사업모델 / 카드사별 결과’로 분류합니다. 그다음 통지된 원인만 고치고 수정 전후 증거를 남긴 뒤 재심사를 요청합니다. 업종·사업모델 자체가 현재 결제경로의 심사범위를 벗어난 경우에는 추가 조건이나 다른 결제경로를 검토합니다.

반려는 하나의 상태처럼 보이지만 해결법은 하나가 아닙니다.

사업자 정보가 틀린 문제를 상품페이지 수정으로 해결할 수 없고, 카드사별 심사 결과를 PG 전체 거절로 보면 불필요한 재신청을 할 수 있습니다. 반대로 업종·거래구조 문제를 푸터 문구만 고쳐서 해결하려 해도 같은 결과가 반복될 수 있습니다.

이 글은 신청 전 체크리스트를 다시 만드는 글이 아닙니다. 이미 반려 통지를 받은 뒤 무엇을 확인하고, 어디를 고치고, 어떤 증거를 남겨 재심사할지를 정리합니다.

30초 진단 — 반려 문구를 먼저 5개 유형으로 나누세요

1) 신청정보·서류

예: 사업자 정보 불일치, 서류 누락, 추가서류 요청.

확인: 신청서 ↔ 사업자등록증 ↔ 사이트 사업자 정보 ↔ 요청된 첨부서류.

다음 행동: 불일치 항목만 맞추고 새로 제출한 파일을 기록합니다.

2) 쇼핑몰·상품·소비자 안내

예: 판매상품 확인 불가, 상세정보 부족, 배송·교환·환불 안내 부족, 사이트 하단(푸터) 정보 부족.

확인: 심사 담당자가 실제 판매 상품과 구매조건을 확인할 수 있는지 봅니다.

다음 행동: 통지된 페이지를 고치고 수정 URL과 전후 화면을 남깁니다.

3) URL·결제창·기술 접근

예: 심사 URL 접속 불가, 도메인 변경, 테스트·샘플 화면, 결제창 미노출.

확인: 심사에 제출한 주소에서 상품→주문→결제창까지 실제로 확인되는지 봅니다.

다음 행동: 주소·접근조건·결제창을 복구하고 담당자가 확인할 정확한 경로를 적습니다.

4) 업종·상품·사업모델

예: 제한 업종, 환금성·선불성, 긴 이행기간, 플랫폼·중개 구조 등에 대한 추가 확인.

확인: 단순 문구 문제가 아니라 실제 거래구조가 무엇인지 정리합니다.

다음 행동: 판매방식과 이행·환불 구조를 사실대로 설명하고 추가조건·추가서류로 재검토 가능한지 묻습니다.

5) 카드사·결제수단별 결과

예: PG의 기본 절차는 진행됐지만 일부 카드사 또는 특정 결제수단 심사에서 추가 보완이나 제한이 생긴 경우.

확인: ‘PG 단계’인지 ‘카드사별 단계’인지 상태를 나눠 봅니다.

다음 행동: 해당 카드사·결제수단의 보완 항목만 확인합니다.

포트원 공식 안내처럼 카드사는 개별적으로 심사할 수 있어 결과 시점이 서로 다를 수 있습니다. 따라서 “카드사 하나의 반려 = PG 전체 거절”로 단정하지 않습니다.

1단계 — 사이트를 고치기 전에 반려 통지를 보존하세요

먼저 아래 여덟 칸을 채웁니다.

1. 신청한 PG·결제상품
2. 신청번호나 MID(상점 ID) 등 식별값
3. 통지 날짜
4. 반려 문구 원문
5. PG 단계 / 카드사 단계 / 특정 결제수단 단계 중 어디인지
6. 심사 대상 URL
7. 당시 화면 캡처
8. 추가서류·추가답변 요청 여부

이 기록은 모든 PG가 요구하는 공식 제출양식이 아닙니다. 수정 전 원인을 잃어버리지 않기 위한 실무 기록입니다.

한 통지에 원인이 세 개 적혀 있다면 세 줄로 분리합니다. 각 원인이 모두 닫혀야 재심사 때 같은 항목이 반복되는 일을 줄일 수 있습니다.

2단계 — 원인마다 ‘수정할 것 + 확인 증거’를 1:1로 붙이세요

A. 사업자 정보·서류 불일치

수정할 것: 반려 통지에 적힌 상호·대표자·주소·사업자번호·사업자 형태별 요청서류 등.

남길 증거: 수정된 신청 화면, 사업자등록증, 새로 올린 서류명, 수정된 푸터 화면.

사업자 정보는 단순한 심사용 장식이 아닙니다. 현행 전자상거래법 제10조는 사이버몰 운영자가 상호·대표자, 주소, 전화번호·전자우편주소, 사업자등록번호, 이용약관 등 정해진 정보를 소비자가 쉽게 알 수 있도록 표시하도록 규정합니다. 시행규칙은 초기 화면에서의 표시방법도 정합니다.

다만 ‘법에 표시해야 한다’와 ‘모든 PG가 완전히 같은 심사 항목을 쓴다’는 다른 말입니다. 법적 표시의무는 지키되, 재심사에서는 현재 PG가 지적한 불일치 항목을 기준으로 보완합니다.

B. 상품·배송·환불·사이트 정보 미비

수정할 것: 반려된 상품·정책 페이지에서 실제 판매내용과 구매조건이 확인되도록 합니다.

남길 증거: 실제 상품명·가격·상세정보가 보이는 URL, 배송 또는 서비스 제공 안내, 교환·환불 안내, 수정 전후 캡처.

토스페이먼츠의 현재 계약 가이드는 자체 심사에서 판매 가능한 상품 1개 이상, 사이트 하단 사업자 정보, 선택한 결제수단의 결제창을 확인하도록 안내합니다. 품절·샘플 상품은 해당 경로의 요구를 충족하지 않는다고도 명시합니다.

중요한 점은 이 숫자를 모든 PG의 공통 규칙으로 확대하지 않는 것입니다. 현재 신청한 PG와 플랫폼의 안내를 기준으로 봅니다.

C. URL·결제창 문제

수정할 것: 심사 URL, 접근조건, 주문흐름, 결제창 노출.

남길 증거: 담당자가 바로 열 수 있는 최종 URL, 상품→주문→결제창까지의 화면.

식스샵의 토스페이먼츠 보완 가이드는 신청 후 임시 도메인이 바뀌어 심사 URL이 달라진 경우 변경된 주소를 적어 재심사를 요청하도록 안내합니다. 토스페이먼츠 개발자 안내도 선택한 결제수단의 결제창이 뜨는지 확인하도록 합니다.

D. 업종·사업모델 문제

수정할 것: ‘문구’가 아니라 PG가 확인하려는 실제 거래구조의 설명과 요청자료.

남길 증거: 상품·서비스 설명, 결제 시점, 배송·서비스 제공 시점, 환불 흐름, 입점자·중개 구조가 있다면 역할 설명, 요청받은 증빙.

여기서는 인터넷의 ‘PG 불가업종 리스트’ 하나를 모든 회사에 그대로 적용하지 않습니다. PG·카드사·결제상품마다 취급범위와 추가조건이 다를 수 있기 때문입니다. 같은 이유로 업종을 숨기거나 실제와 다른 상품명으로 심사를 우회하는 방식도 해결책이 아닙니다.

E. 카드사별 결과

수정할 것: 해당 카드사 또는 결제수단이 지적한 항목.

남길 증거: 카드사별 심사상태, 추가요청 문구, 보완 제출내역.

포트원은 카드사 심사가 카드사별로 개별 진행되고, 기존과 다른 서비스나 결제방식을 운영하면 카드사 재심사가 필요할 수 있다고 안내합니다.

3단계 — ‘많이 수정’보다 ‘반려 사유 닫기’를 목표로 하세요

재심사 전에 각 반려 사유 옆에 세 칸만 만듭니다.

• 원문: 무엇이 문제라고 적혔는가
• 수정: 정확히 무엇을 바꿨는가
• 증거: 어디에서 확인할 수 있는가

예시 1

원문: 사이트 하단 사업자 정보 불일치

수정: 사업자등록증 기준으로 상호·대표자·주소 정정

증거: 푸터 URL + 수정 화면

예시 2

원문: 상품·배송 정보 확인 불가

수정: 실제 판매 상품 상세페이지에 가격·상품설명·배송·환불 안내 반영

증거: 상품 상세 URL + 전후 화면

예시 3

원문: 심사 URL 접속 불가

수정: 변경된 도메인을 심사 경로에 반영

증거: 새 URL + 접속 화면

업종·사업모델 문제라면 ‘수정’ 칸이 사이트 편집이 아니라 ‘추가 설명·추가조건 확인’이 될 수 있습니다. 이 차이를 구분하는 것이 핵심입니다.

4단계 — 재심사 증거팩은 7개만 묶으세요

다음은 공식 의무양식이 아니라 누락을 줄이기 위한 실무용 패킷입니다.

1. 반려 사유 원문
2. 사유별 수정내용 한 줄
3. 수정된 정확한 URL
4. 수정 전·후 화면
5. 새로 제출한 서류와 파일명
6. 필요한 경우 상품 판매·배송/서비스 제공·환불 흐름
7. PG에 남아 있는 확인 질문

핵심은 “수정했습니다”라고만 쓰지 않는 것입니다. 담당자가 어디를 보면 해결됐는지 바로 찾을 수 있게 만듭니다.

5단계 — 새 신청 전에 ‘현재 건에서 재심사 가능한지’ 확인하세요

일부 플랫폼·PG 경로는 기존 신청에서 바로 보완·재심사하도록 설계돼 있습니다.

식스샵의 토스페이먼츠 보완 절차는 미비사항을 수정한 뒤 기존 알림 경로에서 재심사를 요청하도록 안내합니다. 카페24의 일부 PG 신청 흐름도 ‘심사 반려’ 상태에서 신청서를 수정한 뒤 다시 신청하도록 안내합니다. Codemshop 역시 반려 사유 확인 → 사이트 보완 → PG 고객센터를 통한 재심사 요청을 안내합니다.

따라서 먼저 네 가지를 확인합니다.

• 기존 신청번호·MID를 유지한 채 수정 가능한가
• 추가서류 업로드 위치가 있는가
• 재심사 요청 버튼 또는 담당자 회신 경로가 있는가
• 새 신청이 필요한 경우인지 PG가 명시했는가

기간은 서비스별로 다릅니다. 식스샵의 해당 토스페이먼츠 보완 페이지는 재심사 요청 후 약 1~3영업일을 안내하지만, 이 숫자를 모든 PG·카드사 재심사 기간으로 쓰지 않습니다.

6단계 — 다시 반려되면 3가지 결론 중 하나를 선택하세요

결론 1. 수정 가능한 미비

조건: 서류 누락, 정보 불일치, 상품·정책 미비, URL·결제창 문제처럼 구체적인 보완항목이 남아 있습니다.

행동: 같은 원인→수정→증거 구조로 다시 닫고 재심사합니다.

결론 2. 추가조건을 확인해야 하는 심사

조건: 업종·상품·서비스 제공기간·거래구조 때문에 추가서류, 보증, 한도, 정산조건 등 별도 검토가 필요합니다.

행동: 임의로 추측하지 말고 어떤 조건이면 재검토 가능한지 PG에 확인합니다.

결론 3. 현재 경로의 가입조건 문제

조건: 해당 PG·카드사·결제상품 정책상 현재 사업모델을 받기 어렵다는 답이 명확합니다.

행동: 같은 사이트 수정 반복을 멈추고 실제 사업내용을 그대로 제시한 상태에서 다른 PG나 다른 결제상품의 가입 가능성을 검토합니다.

대체 PG를 검토하더라도 원인을 먼저 확정하는 편이 좋습니다. 서류·정보·URL 결함이 원인이었다면 PG를 바꿔도 비슷한 문제가 반복될 수 있기 때문입니다.

PG에 그대로 물어볼 7가지

1. 현재 미충족 항목을 한 문장으로 알려주실 수 있나요?
2. PG 단계, 카드사 단계, 특정 결제수단 단계 중 어느 결과인가요?
3. 같은 신청 건에서 보완 후 재심사가 가능한가요?
4. 추가서류나 설명으로 보완 가능한 항목인가요?
5. 업종·상품·사업모델상 계약이 어려운 항목인가요?
6. 보증·한도·정산 등 추가조건을 두고 검토할 수 있는 항목인가요?
7. 현재 결제상품이 어렵다면 다른 결제상품·계약경로가 있나요?

답을 받아두면 “또 뭘 고쳐야 하나”가 아니라 다음 행동이 결정됩니다.

네 가지 상황만 기억하세요

사업자 정보가 다르다

신청서·사업자등록증·사이트 사업자 정보를 같은 기준으로 맞추고 수정 화면을 남깁니다.

상품이나 정책 페이지가 문제다

통지된 상품과 구매조건이 실제로 확인되는지 고치고 정확한 URL을 붙입니다. 특정 PG가 요구하는 상품 수나 서류는 그 PG의 현재 가이드를 따릅니다.

특정 카드사만 결과가 다르다

PG 전체 거절로 취급하지 말고 카드사별 상태와 추가요청을 확인합니다.

업종·사업모델이 문제다

사이트를 위장하지 않습니다. 정확한 거래구조로 추가조건·추가서류 가능 여부를 묻고, 현재 경로에서 불가능하다면 다른 결제경로를 검토합니다.

자주 묻는 질문

반려되면 바로 다른 PG로 신청하는 게 빠르지 않나요?

서류·정보·URL처럼 수정 가능한 문제라면 새 PG에서도 비슷한 문제가 반복될 수 있습니다. 현재 반려 사유를 먼저 확정한 뒤 바꿀지 결정하는 편이 낫습니다.

상품은 몇 개 있어야 하나요?

모든 PG에 적용되는 공통 숫자로 말하기 어렵습니다. 토스페이먼츠의 현재 안내는 판매 가능한 상품 1개 이상을 요구하지만 다른 PG·플랫폼은 현재 가이드를 별도로 확인해야 합니다.

재심사는 며칠 걸리나요?

PG·플랫폼·카드사와 보완 내용에 따라 다릅니다. 특정 플랫폼이 제시한 기간은 그 신청경로의 예시일 뿐입니다.

카드사 하나만 반려될 수 있나요?

카드사별 심사가 개별적으로 진행될 수 있으므로 PG 단계와 카드사별 결과를 분리해 확인해야 합니다.

PG 심사 반려 뒤의 순서는 ‘다른 PG 찾기’가 아니라 ‘원인 확정’입니다.

반려 통지를 저장하고, 사유를 다섯 유형으로 나누고, 각 사유에 수정내용과 확인 증거를 붙입니다. 그다음 7개짜리 증거팩을 정리하고 기존 신청에서 재심사할 수 있는지 확인합니다.

재심사 후에도 문제가 남으면 수정 가능한 미비인지, 추가조건을 협의해야 하는 심사인지, 현재 경로의 가입조건 문제인지 세 가지로 나눕니다. 이 구조를 지키면 필요 없는 사이트 재작업과 무작정 재신청을 줄일 수 있습니다.