한국 서비스 결제 붙이기: 토스페이먼츠·포트원(아임포트) 등 국내 PG 연동 스택 정리

국내 사용자를 위한 서비스를 만들다 보면 카드 결제와 간편결제를 붙이는 순간이 옵니다. 어려운 건 결제창 하나를 띄우는 일이 아니라, 어떤 계층을 선택하고 주문·환불·정산을 어떻게 연결할지 결정하는 일입니다.

조코헌트에 출시된 프로덕트는 218개, 이를 만든 메이커는 171명입니다. 1인 빌더에게 결제 연동은 거대한 플랫폼을 설계하는 일이 아니라, 첫 유료 고객을 놓치지 않으면서 운영 복잡도를 감당하는 문제에 가깝습니다.

1. 결제 연동에서 먼저 나눌 두 층

직접 PG 연동: 제어권이 큰 선택

토스페이먼츠처럼 PG사와 직접 계약하고 SDK와 API를 제품에 붙이는 방식입니다. 결제 요청, 승인, 취소, 웹훅을 한 흐름으로 설계하기 좋습니다. 대신 계약·심사·환경 분리·예외 처리까지 직접 책임져야 합니다.

결제 상태를 세밀하게 다루거나 특정 PG 기능을 깊게 활용해야 한다면 적합할 수 있습니다. 여러 결제사를 동시에 지원할 계획이 없다면 운영 비용까지 일정에 포함해 계산하세요.

결제 게이트웨이: 여러 PG를 한 겹으로 묶기

포트원(아임포트) 같은 결제 게이트웨이는 여러 PG와 결제수단을 상대적으로 일관된 인터페이스로 연결하는 선택지입니다. 결제사를 바꾸거나 복수 PG를 비교할 때 애플리케이션 코드의 변경 범위를 줄이는 데 도움이 될 수 있습니다.

다만 추상화가 모든 PG의 차이를 없애 주지는 않습니다. 결제 승인 결과, 실패 코드, 환불 조건은 선택한 PG의 공식 문서에서 확인해야 합니다.

2. 내 서비스에 맞는 선택 기준

국내 결제만 필요한 MVP

고객과 판매 범위가 한국에 집중되어 있다면 국내 PG 하나 또는 게이트웨이와 국내 PG 조합부터 검토해 보세요. 기준은 기능 목록보다 다음 질문에 가깝습니다.

실제 고객에게 필요한 결제수단은 무엇인가?
결제 승인 뒤 제공할 상품이나 권한은 무엇인가?
부분 취소·전체 환불·구독 해지를 어떻게 기록할 것인가?
문제가 생겼을 때 확인할 로그와 운영 화면이 충분한가?

조코헌트의 가격 모델 분포를 보면 무료 프로덕트가 74%, 유료가 12%, 프리미엄이 10%입니다. 결제 기능을 넣더라도 모든 기능을 유료화하기보다, 무료 사용과 유료 권한의 경계를 작게 실험하는 접근이 현실적일 수 있습니다.

해외 결제를 함께 고려할 때

한국과 해외 고객을 모두 겨냥한다면 국내 결제와 해외 결제를 하나의 규칙으로 억지로 합치지 않는 편이 낫습니다. 통화, 결제수단, 세금 표시, 환불 정책, 정산 통화가 달라질 수 있기 때문입니다.

PaymentProvider, currency, orderStatus, refundStatus처럼 서비스 내부의 공통 모델을 먼저 정의하세요. 해외 결제 사업자의 세금·정산 조건은 결제 연동 도구 비교: Stripe·Lemon Squeezy·Paddle, 한국 인디 메이커의 세금·정산 관점과 함께 비교하면 좋습니다.

3. 사업자등록부터 정산까지 흐름 그리기

계약과 심사를 코드보다 먼저

사업자등록, 업종·과세 유형, 판매 상품의 성격, 환불 안내처럼 결제 승인 전에 확인할 항목이 있습니다. 사업 형태에 따라 달라질 수 있으므로 관할 기관과 PG사의 공식 안내를 기준으로 확인하세요.

개발부터 시작하면 심사에 필요한 정보와 약관·환불 안내를 뒤늦게 준비하게 됩니다. 결제 페이지를 만들기 전, 필요한 서류와 운영 책임자를 체크리스트로 적어 두는 편이 안전합니다.

주문·승인·제공·환불을 분리하기

핵심은 결제 성공 화면이 아니라 서버의 상태 흐름입니다.

주문 생성 → 결제 시도 → 승인 확인 → 상품/권한 제공 → 환불 또는 취소

사용자가 결제창에서 돌아왔다고 곧바로 권한을 주지 말고, 서버가 승인 결과를 검증한 뒤 주문 상태를 바꾸세요. 승인 요청이 중복되어도 상품이 두 번 제공되지 않도록 주문번호와 결제 키를 기준으로 멱등성을 두는 것이 좋습니다.

4. 1인 개발자가 준비할 최소 구현 목록

데이터 모델

orders, payments, refunds를 한 테이블에 몰아넣기보다 역할을 나누면 장애를 추적하기 쉽습니다. 주문에는 상품 정보, 결제에는 승인 시도, 환불에는 금액과 사유를 남깁니다. 실제 필드명은 PG 문서와 서비스 도메인에 맞춰 정하세요.

운영 장치

테스트·운영 키와 콜백 주소 분리
승인·실패·환불 웹훅 저장 및 재처리
사용자 메시지와 내부 오류 로그 분리
결제 관련 로그의 개인정보 범위 점검
미승인·중복·환불 대기 주문 검색 기능

전체 SaaS 도구 선택이 고민이라면 1인 개발자 SaaS 풀스택 도구 지도: 인증부터 에러추적까지를 참고해 결제 모듈을 기존 스택에 배치해 보세요. 세금 흐름은 SaaS·구독 서비스 부가가치세 기초: 과세·면세 구분과 신고 흐름 이해하기와 함께 확인하면 좋습니다.

5. 결론: 결제사를 고르기 전에 실패 경로부터 정하라

직접 PG와 결제 게이트웨이 중 정답은 제품 범위와 운영 여력에 따라 달라집니다. 국내 MVP라면 필요한 결제수단과 환불 흐름을 작게 정의하고, 해외 확장 가능성이 있다면 내부 결제 모델을 제공자와 분리하세요.

결제 성공만 테스트하지 말고 승인 지연, 창 닫기, 중복 요청, 웹훅 재전송, 부분 환불, 권한 회수까지 시나리오로 점검해야 합니다. 결제 연동은 결제창을 붙이는 작업이 아니라 돈의 상태를 잃어버리지 않는 운영 시스템을 만드는 작업입니다.