블로그 목록으로
소프트웨어

결제는 붙였는데 정산이 안 맞는다: PG 연동·정기결제·환불·대사 설계 가이드

결제 연동의 진짜 난관은 결제 성공 이후의 누락 주문, 이중 결제, 환불 불일치입니다. 상태 설계와 서버 검증, 웹훅 멱등성, 정기결제·부분 환불 계산, 자동 대사까지 결제 운영을 안정적으로 만드는 설계 기준을 정리했습니다.

POLYGLOTSOFT 기술팀2026-09-297분 소요10
PG 연동정기결제환불 처리결제 대사웹훅

결제 버튼보다 어려운 것은 그 뒤의 일

결제 연동은 PG사 SDK를 붙이고 테스트 결제가 한 번 성공하면 끝난 것처럼 보입니다. 실제 문제는 운영을 시작한 뒤에 드러납니다. 고객은 결제 완료 문자를 받았는데 주문 목록에는 주문이 없습니다. 버튼을 두 번 눌러 같은 금액이 두 번 승인되기도 합니다. 부분 환불을 했는데 PG 취소 금액과 내부 환불 금액이 몇 백 원씩 어긋나는 경우도 있습니다.

하루 1,000건을 처리하는 서비스에서 0.3%만 누락돼도 하루 3건, 한 달이면 약 90건입니다. 건마다 CS 담당자가 PG 관리자 화면과 내부 DB를 번갈아 보며 수작업으로 맞춰야 하고, 처리가 늦어지면 고객 불만과 카드사 이의제기로 이어집니다. 결제 시스템의 품질은 결제 버튼이 아니라 그 뒤의 상태 관리와 정산에서 결정됩니다.

결제 흐름의 기본 설계

상태를 먼저 정의합니다

주문은 최소한 다음 단계를 거치도록 설계합니다.

  • 주문 생성(PENDING): 금액과 상품을 서버에서 확정하고 주문번호를 발급합니다
  • 결제 승인 요청: PG 결제창을 호출합니다
  • 결과 검증(VERIFYING): 서버가 PG 조회 API로 실제 승인 여부와 금액을 확인합니다
  • 주문 확정(PAID): 검증을 통과해야만 재고 차감과 알림 발송을 진행합니다
  • 상태 전이는 한 방향으로만 허용하고, 모든 전이를 이력 테이블에 남겨야 나중에 원인을 추적할 수 있습니다.

    클라이언트 결과를 믿지 않습니다

    브라우저가 전달하는 "결제 성공" 파라미터는 조작하거나 재전송할 수 있습니다. 100,000원짜리 주문을 1,000원으로 결제한 뒤 성공 콜백만 보내는 공격이 대표적입니다. 서버는 반드시 PG에 결제 건을 직접 조회해 승인 상태, 결제 금액, 주문번호가 주문 생성 시점의 값과 일치하는지 확인해야 합니다.

    웹훅과 멱등성

    사용자가 결제 직후 창을 닫으면 리다이렉트가 오지 않습니다. 이때 PG 웹훅이 누락 주문을 살려 줍니다. 대신 웹훅은 재전송될 수 있으므로 결제 고유 키 기준의 멱등 처리가 필수입니다. 같은 키가 다시 들어오면 이미 처리한 결과를 돌려주고, 상태 변경은 한 번만 일어나게 합니다. 승인 요청에도 멱등 키를 붙이면 더블클릭으로 인한 이중 결제를 막을 수 있습니다.

    정기결제와 부분 환불

    빌링키 기반 정기결제

    정기결제는 최초 인증 때 발급받은 빌링키로 매 주기 서버가 승인을 요청합니다. 한도 초과나 카드 만료로 인한 실패는 흔하므로 1일·3일·7일 후 재시도처럼 정책을 정해 두고, 실패할 때마다 고객에게 결제수단 변경 링크를 안내합니다. 마지막 재시도까지 실패하면 즉시 해지하기보다 유예 상태(PAST_DUE)를 거치는 것이 이탈을 줄이는 데 유리합니다.

    쿠폰·포인트가 섞인 주문의 환불

    100,000원 주문에 쿠폰 10,000원과 포인트 5,000원을 쓰고 카드로 85,000원을 결제한 고객이 40,000원짜리 상품 하나를 반품한다고 가정해 보겠습니다. 할인을 상품 금액 비율(40%)로 배분하면 쿠폰 4,000원과 포인트 2,000원이 차감되고, 카드 부분취소 금액은 34,000원이 됩니다. 배분 기준을 주문 시점에 상품별로 저장해 두지 않으면 환불할 때마다 계산이 달라집니다.

    플랜 변경 일할 계산

    30일 주기로 월 30,000원 플랜을 쓰던 고객이 11일째에 월 90,000원 플랜으로 올린다면, 남은 20일에 대한 차액은 60,000원 × 20/30 = 40,000원입니다. 즉시 청구할지, 다음 결제일에 반영할지를 정책으로 명확히 정하고 약관과 결제 화면에 같은 기준으로 표시해야 분쟁이 생기지 않습니다.

    대사(Reconciliation)와 운영

    매일 자동 대사

    PG사가 제공하는 정산 내역 파일이나 API를 매일 내려받아 내부 결제 테이블과 결제 키 기준으로 대조합니다. 불일치는 보통 다음 네 가지로 나뉩니다.

  • PG에만 있음: 승인됐지만 주문이 확정되지 않은 누락 건으로, 주문을 복구하거나 결제를 취소합니다
  • 내부에만 있음: 실제 승인이 없는 주문으로, 주문 상태를 되돌립니다
  • 금액 불일치: 부분취소 반영 누락 여부를 확인합니다
  • 상태 불일치: PG는 취소인데 내부는 결제 완료인 건 등입니다
  • 관리자 화면에서는 유형별 목록, 원클릭 재조회, 처리 담당자와 메모 기록을 제공해야 CS 처리 시간이 줄어듭니다.

    저장 범위와 보안

    카드번호 전체나 CVC는 저장하지 않고 빌링키와 마스킹된 카드번호만 보관합니다. 웹훅은 서명이나 발신 IP로 검증하고, 결제 관련 API 키는 서버 환경변수에만 둡니다. 전자금융거래 기록은 법령상 보존 의무가 있으므로(거래 금액에 따라 1년 또는 5년) 삭제 정책도 이 기준에 맞춰 설계해야 합니다.

    POLYGLOTSOFT의 결제 시스템 구축 지원

    쇼핑몰은 부분취소와 쿠폰 배분, SaaS는 정기결제와 일할 계산, 예약 서비스는 취소 수수료와 노쇼 정책이 핵심입니다. POLYGLOTSOFT는 서비스 유형에 맞춰 결제 상태 설계부터 웹훅 멱등 처리, 자동 대사 배치, 관리자 정산 화면까지 함께 구축합니다. 구독형 개발(월 29만원부터)로 진행하시면 오픈 이후 발생하는 정산 불일치, PG 정책 변경 대응 같은 운영 이슈까지 같은 팀이 이어서 관리합니다. 결제 연동을 앞두고 계시다면 요구사항 문서를 작성해 보시거나 문의하기로 편하게 상담을 요청해 주십시오.

    기술 상담이 필요하신가요?

    스마트공장, AI, 물류자동화 분야의 전문 컨설턴트가 귀사의 요구사항을 분석해 드립니다.

    무료 상담 신청