문서 개요 6개 항목
PG 교체는 수수료율이 아니라 전환 비용까지 포함한 총비용으로 판단해야 합니다. 요율이 내려가도 개발비와 운영 부담이 늘면 절감 효과가 작아집니다. 비용 비교표와 결제 상태 흐름을 나란히 놓고 검토하세요.
온라인 서비스 운영자가 먼저 준비할 것은 최저 요율 광고가 아니라 현재 계약 조건, 결제수단별 거래 집계, 필요한 기능 목록입니다. 이 글은 그 자료를 비교 기준과 개발 요청서로 바꾸는 방법을 다룹니다.
01. 견적서는 세 종류의 비용으로 나눈다
세 항목을 분리해야 어디서 비용이 늘거나 줄었는지 설명할 수 있습니다.
- PG 수수료
- 결제 서비스 계약에 따라 지급하는 비용입니다. 결제수단과 계약 조건별 적용 기준을 확인합니다.
- 개발비
- 주문 시스템과 결제 API를 연결하는 작업의 비용입니다. 신규 연동뿐 아니라 이전과 검수 범위도 포함해 봅니다.
- 운영비
- 연동 이후 장애 확인, 거래 내역 대조, 기능 변경 대응에 드는 비용입니다.
| 비용 | 같은 기준으로 비교할 항목 | 확인 자료 |
|---|---|---|
| PG 수수료 | 결제수단별 요율, 고정·건별 비용, 부가세 기준 | 계약 조건과 실제 정산 자료 |
| 전환 개발비 | 승인·취소·구독·관리자 기능, 이전과 검수 | 범위별 견적과 제외 항목 |
| 운영비 | 대사, 장애 대응, API 변경, 운영자 교육 | 지원 계약과 담당 업무 |
거래 집계는 동일한 기간으로 맞추고 카드·계좌 등 수단별 금액과 건수를 구분합니다. 취소 거래의 비용 반영 방식과 별도 기능 계약도 확인하세요. 특정 수단에만 적용되는 낮은 요율을 전체 거래액에 곱하면 실제 비용과 달라집니다.
PG에는 계약·정산 조건을, 개발사에는 구현·검수·운영 범위를 묻는 것이 좋습니다. ‘결제 연동 포함’이라는 한 줄만 있으면 부분취소나 기존 거래 조회가 포함되는지 알기 어렵습니다. 항목별 담당자와 제외 범위를 견적서에 남기세요.
02. 계산 예시: 0.2%포인트의 차이를 총비용으로 보기
아래는 계산법을 설명하기 위한 가정이며 실제 PG 요율이나 고객 성과가 아닙니다. 월 결제액 5,000만 원 전체에 기존 3.0%, 대안 2.8%가 적용된다고 가정합니다. 거래량은 고정하고 부가세와 다른 비용 차이는 제외했습니다.
| 계산 항목 | 계산식 | 결과 |
|---|---|---|
| 월 수수료 차이 | 5,000만 원 × 0.2%포인트 | 10만 원 |
| 추가 운영비 반영 | 10만 원 − 월 3만 원 | 월 7만 원 |
| 초기 개발비 회수 | 120만 원 ÷ 월 7만 원 | 약 17.2개월, 월 단위 18개월째 |
이 경우 질문은 ‘요율이 더 낮은가?’에서 ‘같은 거래 조건이 얼마나 유지되는가?’로 바뀝니다. 거래량이 줄거나 추가 운영비가 늘면 회수 기간도 길어집니다. 반대로 전환 비용 없이 현재 계약을 조정할 수 있다면 비교 결과가 달라집니다.
순차이가 0 이하라면 이 방식으로 초기 비용을 회수할 수 없습니다. 이때는 교체 외에도 기존 PG를 유지하면서 반복 오류와 수작업을 줄이는 선택을 함께 검토할 수 있습니다. 경제성 계산과 기능 개선의 필요성을 구분해 판단하세요.
03. 성공 화면보다 서버의 결제 상태가 먼저다
결제창을 띄우는 일과 주문을 결제 완료로 확정하는 일은 다릅니다. 토스페이먼츠는 요청·인증·승인을 구분하며, 인증 결과의 주문번호와 금액을 확인한 뒤 서버에서 승인하는 흐름을 안내합니다. 토스페이먼츠 결제 흐름 문서
개발 요청서에는 정상 결제만 적지 마세요. 승인 중 사용자가 화면을 닫는 경우, 응답을 받지 못한 경우, 같은 요청이 다시 들어오는 경우의 주문 상태와 후속 조치를 적어야 합니다. 결과가 불명확한 요청은 새 결제로 반복하기 전에 조회와 거래 대사로 확인하는 절차를 정합니다.
웹훅은 결제 상태 변경을 서버에 알리는 통신입니다. 토스페이먼츠는 수신 후 10초 안에 200 응답을 보내도록 안내하고, 실패한 알림을 재전송합니다. 토스페이먼츠 웹훅 문서
따라서 알림을 받을 때마다 배송이나 이용 권한을 새로 부여하면 안 됩니다. 제공자가 정한 검증을 적용하고, 이미 처리한 사건인지 확인하며, 처리 이력을 남기는 설계가 필요합니다. 이벤트별 검증 방식은 해당 문서를 따르고 모든 웹훅에 같은 서명이 있다고 가정하지 않습니다.
04. 정기결제·부분취소는 사업자가 정할 규칙이다
빌링키 발급만으로 구독 서비스가 완성되지는 않습니다. 토스페이먼츠 자동결제는 추가 계약과 검토가 필요하고 결제 주기에 맞춘 승인 호출은 직접 스케줄링해야 합니다. 토스페이먼츠 자동결제 문서
운영자는 결제일, 청구 금액 확정 시점, 실패 후 재시도, 해지 적용일과 이용 권한 종료일을 정해야 합니다. ‘매월 결제’만으로는 말일 가입자나 결제 직전 해지의 결과를 결정할 수 없습니다. 개발자는 이 정책이 작업 재실행에도 일관되게 적용되도록 구현합니다.
부분취소도 환불 금액부터 정의합니다. 상품 하나를 취소할 때 쿠폰·배송비를 어떻게 배분할지, 이전 취소액을 어떻게 누적할지 정하세요. API 호출이 성공했다는 사실과 고객에게 안내한 환불 금액이 맞다는 사실은 별도 검수 항목입니다.
05. 전환 전에는 예외 처리와 운영 인수를 확인한다
테스트 환경에서 다음 결과를 확인하도록 요청하세요. 목록의 목적은 오류가 없다는 막연한 약속 대신 인수 기준을 명확하게 만드는 것입니다.
- 금액 검증: 변조된 금액은 거절되고 서버의 주문 금액이 유지되는가?
- 중복·지연: 같은 요청이나 늦은 웹훅이 중복 청구·권한 부여를 만들지 않는가?
- 거래 대사: 승인 결과가 불명확할 때 주문번호로 PG와 내부 기록을 대조할 수 있는가?
- 취소·해지: 부분취소 누적액과 정기결제 해지가 합의한 정책대로 반영되는가?
- 운영 인수: 담당자가 실패 내역과 조치 이력을 확인하고 비밀정보는 노출되지 않는가?
검수 뒤 실제 전환은 기존 거래의 처리 경로까지 확인한 다음 진행합니다.
- 기존 거래의 취소·조회 방법과 빌링키 이전 가능 여부를 확인합니다.
- 신규 주문의 전환 시점, 실패 시 돌아갈 범위와 결정 담당자를 합의합니다.
- 전환 후 내부 주문과 PG 거래를 대조하고, 불일치 건의 담당자와 조치 결과를 기록합니다.
초기 검토 자료에는 고객 개인정보와 카드 정보, 시크릿 키를 포함하지 않습니다. 집계와 조건만 공유하고 실제 접근이 필요할 때 목적·권한·전달 수단을 별도로 정하세요.
06. 자주 묻는 질문
수수료가 높아 보이면 PG부터 바꿔야 하나요?
현재 계약과 거래 구성을 먼저 확인하세요. 조건 조정, 기존 연동 개선, PG 교체를 같은 기간의 총비용과 기능 범위로 비교하는 것이 순서입니다.
개발사에 맡기면 PG 계약도 완료되나요?
개발 지원과 PG 계약·심사는 별개입니다. 가입 준비를 어디까지 지원하는지, 적용 조건은 누가 확정하는지 견적 단계에서 구분하세요.
정기결제 실패는 자동으로 해결되나요?
PG 기능과 별도로 재시도·알림·이용 권한 처리 규칙을 확인해야 합니다. 같은 청구 건의 중복 실행을 막을 기준도 필요합니다.
기술 설명은 2026년 9월 14일 확인한 토스페이먼츠 문서 기준이며 다른 PG의 계약·API 정책은 별도 확인이 필요합니다. 실제 수수료 인하나 계약 승인을 보장하는 안내는 아닙니다.
결제 서비스 대행 안내에서 지원 범위를 확인할 수 있습니다. 현재 PG와 플랫폼, 집계 거래량, 필요한 기능과 반복 오류를 정리하면 결제 연동 검토에서 비용과 개발 범위를 구체적으로 논의할 수 있습니다.