Blog·인사이트

결제 기능, 생각보다 복잡한 이유

··4분 읽기

"결제 기능 붙이면 되잖아요. 그게 그렇게 오래 걸려요?"

결제는 간단해 보입니다. 사용자가 금액을 확인하고, 카드 정보를 입력하고, 결제 완료. 화면으로는 한 페이지입니다. 하지만 그 한 페이지 뒤에는 생각보다 많은 것들이 숨어있습니다.

PG 연동은 "코드 붙이기"가 아니다

결제를 처리하려면 PG(Payment Gateway)사와 계약해야 합니다. NicePay, KG이니시스, 토스페이먼츠, KCP 등. 프로덕트 메이커는 KM Park 커스텀 커머스에서 NicePay 직계약으로 연매출 200억 규모의 결제·정산 시스템을 구축했습니다.

계약과 심사

PG사와 계약하려면 사업자등록증, 서비스 URL, 판매하는 상품/서비스의 설명이 필요합니다. 심사 기간은 보통 3일~2주. 서비스 내용에 따라 심사가 통과되지 않는 경우도 있습니다.

연동 자체의 복잡도

PG마다 API 스펙이 다릅니다. 그리고 문서의 품질이 천차만별입니다.

아임포트(포트원)나 토스페이먼츠 같은 곳은 API 문서가 웹에 깔끔하게 공개되어 있고, 개발 샘플 코드도 제공되며, 테스트 환경도 잘 갖춰져 있습니다. 개발자 경험이 좋아서 연동이 비교적 수월합니다.

반면 어떤 PG사는 상황이 완전히 다릅니다. 특정 기능이 필요하다고 하면, 담당자가 "1.034 버전" 같은 PDF 문서 하나를 메일로 던져줍니다. 샘플 코드도 ZIP 파일로 보내주는데, 문서와 샘플이 안 맞는 경우도 있습니다. 공식 사이트에 공개된 API 문서는 실제 적용하면 동작이 안 됩니다. "이 파라미터가 뭔가요?" "그건 저 문서 34페이지에 있습니다" "34페이지 대로 했는데 안 됩니다" "아 그건 구버전이고 새 문서 보내드릴게요" — 이런 핑퐁이 수차례, 많게는 수십 차례 오가야 개발이 완료됩니다.

그러면 왜 이런 PG사를 쓰느냐? 수수료가 싸기 때문입니다. 연동은 어렵지만, 거래 건당 수수료가 0.5~1%p 차이 나면 연 매출이 높은 서비스에서는 수천만 원의 차이가 됩니다. 그래서 어려워도 붙이는 겁니다. 이 연동 난이도의 차이가 견적에 반영되어야 하는데, 클라이언트 입장에서는 "결제 붙이는 건 다 같은 거 아니에요?"가 됩니다.

"결제 API 연동 3일이면 되죠?"라고 생각하기 쉽지만, PG사에 따라 연동만 2~4주가 걸릴 수 있습니다.

결제 성공은 시작일 뿐이다

결제가 성공하는 것은 전체의 30%입니다. 나머지 70%는 이런 것들입니다.

결제 실패 처리

  • 카드 한도 초과
  • 네트워크 타임아웃
  • 사용자가 결제 중간에 이탈
  • PG사 서버 장애

실패했을 때 사용자에게 어떤 메시지를 보여줄 것인가, 재시도는 어떻게 할 것인가, 주문 데이터는 어떤 상태로 남겨야 하는가. 이 예외 처리가 결제 개발의 핵심입니다.

취소와 환불

  • 전액 취소: 비교적 단순하지만, PG사에 취소 요청 → 응답 확인 → 주문 상태 변경 → 사용자 알림까지
  • 부분 환불: "3개 중 1개만 환불해주세요" — 이건 훨씬 복잡합니다. 배송비 계산, 쿠폰 적용 금액 재계산, PG 부분 취소 API 호출
  • 환불 지연: PG사에서 취소 처리가 즉시 되지 않는 경우, 상태를 추적해야 함

정산

결제가 완료되었다고 바로 돈이 들어오지 않습니다.

  • PG사별로 정산 주기가 다릅니다 (D+2, D+3, 주 1회 등)
  • 결제 금액에서 PG 수수료가 차감됩니다 (보통 2~3.5%)
  • 카드사별로 수수료율이 다를 수 있습니다
  • 정산 내역과 실제 입금 내역을 대조하는 작업이 필요합니다

"결제를 붙였는데, 정산이 안 맞아요" — 이 문제를 해결하려면 결제 로그를 꼼꼼히 기록하고, 정산 대사(대조) 시스템을 만들어야 합니다.

결제 수단별 추가 고려사항

카드 결제만 있는 게 아닙니다.

  • 간편결제(카카오페이, 네이버페이 등): 각각 별도 연동 필요
  • 가상계좌: 입금 확인 웹훅 처리, 미입금 시 자동 취소
  • 정기결제(구독): 빌링키 발급, 자동 결제 스케줄링, 결제 실패 시 재시도 로직
  • 해외결제: 환율 처리, 해외 카드 지원 여부

결제 수단이 하나 추가될 때마다, 성공/실패/취소/환불 플로우가 각각 필요합니다.

프로덕트 메이커의 경험

프로덕트 메이커는 KM Park(주차 관리 서비스)에서 사이트를 통한 연 매출 200억 원 이상 규모의 결제 시스템을 구축한 경험이 있습니다. 일반 결제와 빌링(정기결제)을 모두 구현했고, 결제 성공/실패/취소/환불의 전체 플로우를 설계했습니다. 그 외에도 여러 프로젝트에서 다양한 PG사를 연동해왔기 때문에, PG사별 특성과 연동 난이도 차이를 잘 알고 있습니다.

결제 시스템에서 가장 중요한 것은 데이터 정합성입니다. 결제는 됐는데 주문이 안 생기거나, 취소를 했는데 환불이 안 되거나, 금액이 맞지 않거나 — 이런 상황이 발생하면 고객 신뢰를 잃고, 운영팀은 수작업으로 처리해야 합니다.

결제 기능을 의뢰할 때 확인할 것

  • 어떤 결제 수단이 필요한가? (카드, 간편결제, 가상계좌, 정기결제)
  • 환불 정책이 정해져 있는가? (전액, 부분, 기간 제한)
  • 정산 관리가 필요한가? (대시보드, 정산 대사)
  • PG사 계약은 되어있는가? (미계약이면 심사 기간도 일정에 포함)

결제는 "기능 하나"가 아닙니다. 결제 성공, 실패, 취소, 환불, 정산이라는 5개의 흐름을 모두 설계해야 하는 시스템입니다.

*결제 시스템 구축이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 경험을 바탕으로 현실적인 설계를 안내드립니다.*


결제,PG,환불,정산,이커머스
다른 포스팅
Blog·인사이트

결제 기능, 생각보다 복잡한 이유

··4분 읽기

"결제 기능 붙이면 되잖아요. 그게 그렇게 오래 걸려요?"

결제는 간단해 보입니다. 사용자가 금액을 확인하고, 카드 정보를 입력하고, 결제 완료. 화면으로는 한 페이지입니다. 하지만 그 한 페이지 뒤에는 생각보다 많은 것들이 숨어있습니다.

PG 연동은 "코드 붙이기"가 아니다

결제를 처리하려면 PG(Payment Gateway)사와 계약해야 합니다. NicePay, KG이니시스, 토스페이먼츠, KCP 등. 프로덕트 메이커는 KM Park 커스텀 커머스에서 NicePay 직계약으로 연매출 200억 규모의 결제·정산 시스템을 구축했습니다.

계약과 심사

PG사와 계약하려면 사업자등록증, 서비스 URL, 판매하는 상품/서비스의 설명이 필요합니다. 심사 기간은 보통 3일~2주. 서비스 내용에 따라 심사가 통과되지 않는 경우도 있습니다.

연동 자체의 복잡도

PG마다 API 스펙이 다릅니다. 그리고 문서의 품질이 천차만별입니다.

아임포트(포트원)나 토스페이먼츠 같은 곳은 API 문서가 웹에 깔끔하게 공개되어 있고, 개발 샘플 코드도 제공되며, 테스트 환경도 잘 갖춰져 있습니다. 개발자 경험이 좋아서 연동이 비교적 수월합니다.

반면 어떤 PG사는 상황이 완전히 다릅니다. 특정 기능이 필요하다고 하면, 담당자가 "1.034 버전" 같은 PDF 문서 하나를 메일로 던져줍니다. 샘플 코드도 ZIP 파일로 보내주는데, 문서와 샘플이 안 맞는 경우도 있습니다. 공식 사이트에 공개된 API 문서는 실제 적용하면 동작이 안 됩니다. "이 파라미터가 뭔가요?" "그건 저 문서 34페이지에 있습니다" "34페이지 대로 했는데 안 됩니다" "아 그건 구버전이고 새 문서 보내드릴게요" — 이런 핑퐁이 수차례, 많게는 수십 차례 오가야 개발이 완료됩니다.

그러면 왜 이런 PG사를 쓰느냐? 수수료가 싸기 때문입니다. 연동은 어렵지만, 거래 건당 수수료가 0.5~1%p 차이 나면 연 매출이 높은 서비스에서는 수천만 원의 차이가 됩니다. 그래서 어려워도 붙이는 겁니다. 이 연동 난이도의 차이가 견적에 반영되어야 하는데, 클라이언트 입장에서는 "결제 붙이는 건 다 같은 거 아니에요?"가 됩니다.

"결제 API 연동 3일이면 되죠?"라고 생각하기 쉽지만, PG사에 따라 연동만 2~4주가 걸릴 수 있습니다.

결제 성공은 시작일 뿐이다

결제가 성공하는 것은 전체의 30%입니다. 나머지 70%는 이런 것들입니다.

결제 실패 처리

  • 카드 한도 초과
  • 네트워크 타임아웃
  • 사용자가 결제 중간에 이탈
  • PG사 서버 장애

실패했을 때 사용자에게 어떤 메시지를 보여줄 것인가, 재시도는 어떻게 할 것인가, 주문 데이터는 어떤 상태로 남겨야 하는가. 이 예외 처리가 결제 개발의 핵심입니다.

취소와 환불

  • 전액 취소: 비교적 단순하지만, PG사에 취소 요청 → 응답 확인 → 주문 상태 변경 → 사용자 알림까지
  • 부분 환불: "3개 중 1개만 환불해주세요" — 이건 훨씬 복잡합니다. 배송비 계산, 쿠폰 적용 금액 재계산, PG 부분 취소 API 호출
  • 환불 지연: PG사에서 취소 처리가 즉시 되지 않는 경우, 상태를 추적해야 함

정산

결제가 완료되었다고 바로 돈이 들어오지 않습니다.

  • PG사별로 정산 주기가 다릅니다 (D+2, D+3, 주 1회 등)
  • 결제 금액에서 PG 수수료가 차감됩니다 (보통 2~3.5%)
  • 카드사별로 수수료율이 다를 수 있습니다
  • 정산 내역과 실제 입금 내역을 대조하는 작업이 필요합니다

"결제를 붙였는데, 정산이 안 맞아요" — 이 문제를 해결하려면 결제 로그를 꼼꼼히 기록하고, 정산 대사(대조) 시스템을 만들어야 합니다.

결제 수단별 추가 고려사항

카드 결제만 있는 게 아닙니다.

  • 간편결제(카카오페이, 네이버페이 등): 각각 별도 연동 필요
  • 가상계좌: 입금 확인 웹훅 처리, 미입금 시 자동 취소
  • 정기결제(구독): 빌링키 발급, 자동 결제 스케줄링, 결제 실패 시 재시도 로직
  • 해외결제: 환율 처리, 해외 카드 지원 여부

결제 수단이 하나 추가될 때마다, 성공/실패/취소/환불 플로우가 각각 필요합니다.

프로덕트 메이커의 경험

프로덕트 메이커는 KM Park(주차 관리 서비스)에서 사이트를 통한 연 매출 200억 원 이상 규모의 결제 시스템을 구축한 경험이 있습니다. 일반 결제와 빌링(정기결제)을 모두 구현했고, 결제 성공/실패/취소/환불의 전체 플로우를 설계했습니다. 그 외에도 여러 프로젝트에서 다양한 PG사를 연동해왔기 때문에, PG사별 특성과 연동 난이도 차이를 잘 알고 있습니다.

결제 시스템에서 가장 중요한 것은 데이터 정합성입니다. 결제는 됐는데 주문이 안 생기거나, 취소를 했는데 환불이 안 되거나, 금액이 맞지 않거나 — 이런 상황이 발생하면 고객 신뢰를 잃고, 운영팀은 수작업으로 처리해야 합니다.

결제 기능을 의뢰할 때 확인할 것

  • 어떤 결제 수단이 필요한가? (카드, 간편결제, 가상계좌, 정기결제)
  • 환불 정책이 정해져 있는가? (전액, 부분, 기간 제한)
  • 정산 관리가 필요한가? (대시보드, 정산 대사)
  • PG사 계약은 되어있는가? (미계약이면 심사 기간도 일정에 포함)

결제는 "기능 하나"가 아닙니다. 결제 성공, 실패, 취소, 환불, 정산이라는 5개의 흐름을 모두 설계해야 하는 시스템입니다.

*결제 시스템 구축이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 경험을 바탕으로 현실적인 설계를 안내드립니다.*


결제,PG,환불,정산,이커머스
다른 포스팅
WebGL프로젝트 상담