자사몰을 오픈한 지 일주일도 안 돼 “결제는 됐는데 주문 내역에는 안 뜬다”는 문의가 들어왔습니다. 확인해보니 결제 승인은 PG사에서 정상 처리됐지만, 그 결과를 홈페이지 주문 시스템에 반영하는 연동 구간에 오류가 있었던 것입니다. 고객 돈은 이미 빠져나갔는데 회사는 주문이 들어온 사실조차 몰랐습니다. PG 연동은 “결제가 되는가”가 아니라 “결제 이후 데이터가 정확히 맞물리는가”가 핵심입니다.
PG 연동에서 가장 위험한 구간은 결제 그 자체가 아니다
PG(전자결제대행) 연동을 테스트할 때 대부분 “결제창이 뜨고 결제가 완료되는지”만 확인합니다. 그러나 실제 사고는 결제 완료 이후 구간에서 발생합니다.
- 결제는 성공했지만 주문 상태가 홈페이지에 반영되지 않는 경우
- 결제 취소·환불 요청 시 실제 PG사 처리와 홈페이지 상태가 어긋나는 경우
- 결제 진행 중 브라우저가 닫히거나 네트워크가 끊겼을 때 중복 결제되는 경우
- PG사 응답이 지연될 때 사용자가 결제 버튼을 여러 번 눌러 중복 처리되는 경우
이런 사고는 자주 발생하지 않지만, 한 번 발생하면 고객 신뢰와 매출에 직접 영향을 미치기 때문에 오픈 전 반드시 시나리오별로 테스트해야 합니다.
오픈 전 필수 테스트 시나리오
| 시나리오 | 확인 내용 |
|---|---|
| 정상 결제 | 결제 완료 후 주문 상태, 재고 반영, 알림 발송까지 전체 확인 |
| 결제 취소 | 사용자가 결제 중 취소 시 주문이 생성되지 않는지 |
| 결제 실패 | 카드 한도 초과 등 실패 시 적절한 안내와 재시도 가능 여부 |
| 부분 환불 | 관리자가 부분 금액만 환불했을 때 데이터 정합성 유지 여부 |
| 중복 클릭 | 결제 버튼을 빠르게 여러 번 눌렀을 때 중복 결제 방지 여부 |
| 결제 중 이탈 | 결제창을 닫거나 이탈 시 주문 데이터 처리 방식 |
이 6가지 시나리오는 실제 운영 중 반드시 한 번씩은 발생하는 상황입니다. 오픈 전 테스트 계정으로 각 상황을 직접 재현해 확인해야 합니다.
국내 PG 연동 시 자주 발생하는 기술적 함정
국내 주요 PG사들은 각자 다른 방식(웹훅, 콜백, 승인 API 등)으로 결제 결과를 전달합니다. 연동 과정에서 자주 발생하는 문제는 다음과 같습니다.
- PG사에서 보내는 결제 완료 알림(웹훅)을 놓쳐 주문이 누락되는 경우
- 모바일 앱 결제와 웹 결제의 처리 방식이 달라 한쪽에서만 오류가 발생하는 경우
- 정기결제(구독)가 있는 경우, 자동 결제 실패 시 후속 처리(알림, 서비스 중단 등) 미비
- 테스트 환경(개발용) 설정을 실제 운영 환경에서 그대로 사용해 실결제가 되지 않는 경우
이런 문제는 “결제창이 잘 뜬다”는 확인만으로는 발견되지 않고, 실제 결제 완료 후의 데이터 흐름을 끝까지 추적해야 발견됩니다.
보안 테스트, 무엇을 확인해야 하는가
결제 데이터는 민감한 개인정보·금융정보를 포함하므로 아래 보안 항목을 별도로 점검해야 합니다.
| 항목 | 확인 내용 |
|---|---|
| 카드 정보 저장 여부 | 카드번호 등 민감정보를 홈페이지 서버에 직접 저장하지 않는지(PG사 위임 처리 확인) |
| 결제 요청 위·변조 방지 | 결제 금액이 사용자 브라우저에서 임의로 조작되지 않도록 서버에서 재검증하는지 |
| 통신 암호화 | 결제 관련 통신이 암호화(SSL/TLS)되어 있는지 |
| 접근 권한 관리 | 결제·주문 데이터를 관리자 화면에서 누가 조회·수정 가능한지 |
특히 결제 금액을 서버에서 재검증하지 않는 구조는 심각한 보안 취약점입니다. 브라우저에서 전달된 금액을 그대로 믿고 처리하면, 값을 조작해 실제보다 적은 금액으로 결제를 시도하는 공격에 노출될 수 있습니다.
자사몰 구축 시 PG 선택과 계약에서 확인할 것
PG 계약 자체는 회사가 직접 하지만, 연동 개발 과정에서 아래를 함께 확인해야 합니다.
- 취급 상품·서비스가 PG사 심사 대상 업종에 해당하는지(고액 결제, 정기결제 등 제한 업종 존재)
- 정산 주기와 수수료 구조가 사업 특성에 맞는지
- 간편결제(계좌, 각종 페이 연동 등) 추가 지원 여부와 연동 난이도
- 연동 개발 시 PG사가 제공하는 테스트 환경을 충분히 활용할 수 있는지
개발사와 PG사 계약은 별개이므로, 개발 착수 전 PG 가맹 계약이 먼저 완료되어야 실제 연동 테스트가 가능합니다. 계약 초기 단계에서 이 순서를 놓치면 일정이 지연되는 경우가 많습니다.
결제 관련 장애, 대응 프로세스를 미리 정해두라
테스트를 철저히 해도 결제 장애는 언제든 발생할 수 있습니다. 대응 프로세스가 없으면 장애 순간 혼란이 커집니다.
- 장애 감지 — 결제 실패율이 급증하면 담당자에게 알림이 가는 구조
- 1차 확인 — PG사 장애인지, 홈페이지 연동 문제인지 구분
- 고객 안내 — 결제 오류 발생 시 사용자에게 명확한 안내와 대체 결제 수단 제시
- 사후 정산 확인 — 중복 결제, 미반영 주문이 있는지 로그로 재확인
이 프로세스를 사전에 문서화해두면 장애 상황에서도 신속하게 대응할 수 있습니다. QA 전반은 프론트엔드·백엔드 QA 체크리스트와 함께 준비하는 것이 좋습니다.
테스트가 끝났다고 안심하지 말아야 할 이유
오픈 전 테스트를 통과했어도, 아래 상황에서는 재검증이 필요합니다.
- PG사 정책·API가 업데이트된 경우
- 새로운 결제 수단(간편결제 등)을 추가한 경우
- 홈페이지 개편이나 주문 시스템 구조를 변경한 경우
- 트래픽이 급증하는 이벤트·할인 시즌 직전
결제 연동은 “한 번 검증하고 끝”이 아니라 변경이 생길 때마다 재검증이 필요한 영역입니다. 정기적인 점검이 부담스럽다면 무료 견적요청을 통해 결제 시스템 전반의 안정성 점검을 상담받아보세요.
자주 묻는 질문 (FAQ)
결제 테스트는 실제 카드로 해야 하나요? +
PG사에서 제공하는 테스트 환경과 테스트 카드번호로 대부분의 시나리오를 확인할 수 있습니다. 실 운영 전환 직전에는 소액으로 실제 결제 테스트를 1회 이상 진행해 실환경에서도 정상 작동하는지 확인하는 것이 안전합니다.
결제 오류가 자주 발생하면 PG사를 바꿔야 하나요? +
PG사 문제인지 연동 구조 문제인지 먼저 구분해야 합니다. 오류 로그를 분석해 원인이 명확한 연동 버그라면 개발 쪽에서 해결이 가능하고, PG사 자체의 반복적인 장애라면 다른 PG사와의 비교 검토가 필요할 수 있습니다.
정기결제(구독) 서비스는 일반 결제와 다르게 테스트해야 하나요? +
네, 정기결제는 최초 결제 외에도 자동 갱신 결제, 결제 실패 시 재시도, 구독 해지 처리 등 별도 시나리오가 필요합니다. 특히 카드 만료나 한도 초과로 자동 결제가 실패했을 때의 후속 처리를 반드시 테스트해야 합니다.
보안 테스트는 자체적으로 할 수 있나요, 전문 업체가 필요한가요? +
기본적인 항목(금액 재검증, 통신 암호화 확인 등)은 개발사가 자체 점검할 수 있습니다. 다만 결제·개인정보를 대량으로 다루는 서비스라면 정기적인 전문 보안 점검을 병행하는 것을 권장합니다.
오픈 후에도 결제 로그를 계속 확인해야 하나요? +
네, 특히 오픈 초기와 이벤트 시즌에는 결제 성공률과 오류 로그를 주기적으로 확인하는 것이 좋습니다. 이상 패턴(특정 시간대 실패율 급증 등)을 조기에 발견하면 큰 장애로 번지기 전에 대응할 수 있습니다.