PG 연동과 정산 — 쇼핑몰 구축 시 빠뜨리면 막히는 것
쇼핑몰 견적 단계에서 “결제만 붙이면 된다”고 말하는 경우가 많습니다.
실제로는 결제 승인 → 주문 확정 → 정산 데이터 → 환불·부분취소 → 정산 보류까지가 한 줄로 묶여 있습니다. 이 중 하나만 빠져도 오픈 직후 고객센터와 재무가 동시에 막힙니다.
화면 목록만 보고 외주를 맡기면, 개발 중반에 “정산 엑셀은 누가 뽑나요?”, “부분 환불 시 결제 금액과 주문 금액이 안 맞아요” 같은 질문이 한꺼번에 나옵니다. 그때 이미 일정과 예산이 고정된 상태인 경우가 많습니다.
왜 이런 일이 생기나요?
PG(Payment Gateway, 결제대행)는 카드·간편결제로 돈을 받는 통로입니다. 쇼핑몰은 그 돈이 어떤 주문·어떤 배송·어떤 환불에 해당하는지 끝까지 추적해야 합니다. 통로만 연결하고 추적 구조가 없으면 정산 시즌에 수작업으로 무너집니다.
| 구분 | 결제대행 쪽 | 쇼핑몰 쪽 |
|---|---|---|
| 카드/간편결제 인증 | 결제창·앱 연동 처리 | 주문 금액·상품 내역 고정 |
| 승인 결과 통지 | 승인/실패 응답, 서버 알림 | 주문 상태 변경, 재고 차감 시점 결정 |
| 정산 금액 | 수수료 차감 후 입금 일정 | 주문·취소·부분환불을 정산 단위와 매칭 |
| 영수증·매출 기록 | 일부 제공 | 고객·세무 대응용 자체 기록 보관 |
국내 주요 PG 연동을 개념적으로 나누면 대략 다음 단계입니다. 구현 세부는 사업사 문서·계약 조건에 따르고, 아래는 빠뜨리기 쉬운 체크 포인트 위주입니다.
- 주문 생성(서버)
장바구니/바로구매 기준으로 주문 번호, 결제 예정 금액, 상품 내역을 서버에 먼저 만듭니다. 화면에서 금액을 최종 결정하면 조작 위험이 큽니다.
- 결제 준비(서버 → PG)
주문번호·금액·성공/실패 후 이동 주소를 넘깁니다. 테스트 키와 라이브 키, 상점 아이디 환경을 분리합니다.
- 결제창/앱 이동
웹·앱에서 카드사·간편결제 앱으로 넘어갑니다. 심사용 테스트 경로와 실결제 경로를 혼동하면 심사가 막힙니다.
- 승인 확정(서버)
결제 성공 화면만 보고 주문을 “결제완료”로 바꾸면 안 됩니다. 서버가 PG에 최종 확인한 뒤에만 주문 상태를 올립니다.
- 서버 알림(비동기 통지)
사용자가 브라우저를 닫아도 승인/취소 결과가 올 수 있습니다. 위조 방지 검증·중복 수신 처리가 없으면 이중 반영이나 미반영이 생깁니다.
- 정산·대사
PG 정산 리포트와 자사 주문 기록을 주문번호·결제키 기준으로 맞춥니다. 부분취소·입금 확인 지연이 있으면 일자별 차이가 납니다.
키 값·비밀 정보를 코드에 박아 두지 말고, 환경별로 분리해 관리하는 것이 기본입니다.
이렇게 보면 쉬워요
정산에서 막히는 지점은 네 가지로 정리할 수 있습니다.
1) 주문 단위와 결제 단위가 1:1이 아닐 때
묶음 배송, 부분 출고, 부분 환불, 교환 재결제가 생기면 “주문 1건 = 결제 1건” 가정이 깨집니다. 처음부터 결제 시도와 주문을 구분해 두고, 상태 변화를 기록하는 편이 안전합니다.
2) 정산 기준일과 배송 완료일이 다를 때
PG 입금일과 쇼핑몰 매출 인식 기준이 다르면 재무 장부와 운영 화면이 어긋납니다. “매출 기준을 결제일로 할지, 출고일로 할지”를 운영 정책으로 고정해야 합니다.
3) 수수료·부가세·쿠폰 분담
쿠폰을 플랫폼이 부담하는지, 입점 판매자가 부담하는지에 따라 정산 공식이 달라집니다. 단일 브랜드몰이어도 내부 프로모션 예산을 나누면 같은 문제가 생깁니다. 견적 단계에 “프로모션 정산 규칙”을 문장으로 남겨 두지 않으면 개발 중 범위가 늘어납니다.
4) 환불 창구가 여러 개일 때
고객센터 수동 환불, 사용자 앱 취소, 관리자 부분취소, PG 직접 취소가 동시에 열리면 상태가 꼬입니다. 환불의 단일 진입점을 두고 PG 취소와 주문 상태 변경을 같은 흐름으로 묶는 것이 좋습니다.
| 흔한 선택 | 이후 비용 |
|---|---|
| “결제 모듈만 붙이고 정산은 엑셀” | 시즌마다 수작업 대사, 누락 환불 분쟁 |
| 화면 금액으로 승인 | 금액 조작·과소/과다 결제 사고 |
| 서버 알림 없이 성공 화면만 신뢰 | 앱 강제 종료 시 미확정 주문 다수 |
| 테스트 키로 라이브 오픈 | 실결제 불가 또는 테스트 거래 혼입 |
| 부분취소 미설계 | 반품 시 전액 취소만 가능 → 고객센터 폭증 |
이렇게 준비하면 좋아요
- □ 주문 생성과 결제 승인 확정이 서버에서 분리되어 있다
- □ 결제 예정 금액이 서버에 고정된다
- □ 성공 화면 복귀와 서버 알림 모두에서 같은 주문번호로 중복 없이 처리한다
- □ 부분취소·전액취소·결제 실패·시간 초과 상태가 구분된다
- □ 테스트/라이브 키·상점 아이디·콜백 주소가 환경별로 분리된다
- □ PG 정산 리포트와 주문을 맞출 키(주문번호·결제키)가 저장된다
- □ 쿠폰·포인트·배송비 포함 시 정산 공식이 문서화되어 있다
- □ 환불 시 재고·쿠폰 복원 정책이 결제 취소와 같은 흐름에 있다
- □ 앱에서 결제 시 외부 앱으로 나갔다 복귀하는 경로를 검증했다
- □ 관리자 화면에 “결제 상태 ≠ 주문 상태” 불일치 건을 볼 수 있다
오픈 후 결제·정산 층을 갈아엎는 비용은, 초기 설계에 상태를 넣는 비용보다 보통 훨씬 큽니다. “일단 결제창만”은 일정을 앞당기는 것처럼 보이지만, 실제로는 정산 시즌에 일정을 뒤로 미룹니다.
자주 하는 실수
- 결제 성공 화면만 보고 주문 완료 처리
- 부분 환불을 “전액 취소 후 재결제”로만 땜질
- 정산을 시즌마다 엑셀 수작업으로 버팀
- 테스트 상점과 운영 상점 설정을 섞음
- 환불을 여러 경로에서 동시에 실행
- 앱 결제 복귀·중복 클릭을 검수하지 않음
LB Contents는 앱·홈페이지·쇼핑몰을 만들 때 결제창 연동만이 아니라 주문·정산·환불·운영 화면 구조까지 함께 설계합니다. PG 계약 전 단계에서 필요한 기능 범위를 정리하는 상담도 가능합니다.