결제 연동 개발, PG사 고르기 전에 알아야 할 7가지 (2026)

플랫폼이나 쇼핑몰을 만들 때 결제는 거의 마지막에 붙이는 작업처럼 보입니다. 그래서 많은 대표님이 "PG사 하나 골라서 연동하면 끝"이라고 생각하고 견적을 받습니다. 그런데 실제로 운영에 들어가면 결제가 가장 많은 문의와 환불 분쟁, 정산 오류를 만드는 지점입니다. 결제는 돈이 직접 오가는 곳이라 작은 설계 실수 하나가 그대로 손실이나 고객 이탈로 이어집니다.

이 글은 결제 연동을 앞둔 중소기업 대표님이 PG사를 고르고 개발사에 맡기기 전에 반드시 짚어야 할 기준을 정리했습니다. 단순 결제창 연동이 아니라, 환불, 정산, 보안, 운영까지 포함한 실제 기준입니다. 결제 연동 개발 비용이 업체마다 크게 차이 나는 이유도 여기에 있습니다.

결제 연동이란 결제창만 붙이는 게 아니다

결제 연동이라고 하면 보통 카드 입력창 하나를 떠올립니다. 하지만 실제로 돈이 오가는 흐름은 결제 요청, 승인, 취소, 부분 취소, 환불, 정산, 대사(장부 맞추기)까지 이어집니다. 이 중 하나라도 빠지면 운영팀이 수작업으로 메워야 하고, 그 수작업이 바로 오류와 분쟁의 출발점이 됩니다.

예를 들어 고객이 상품 두 개를 사고 그중 하나만 환불받는 상황을 생각해 보겠습니다. 부분 취소가 없으면 운영자는 전체를 취소하고 다시 결제를 유도해야 합니다. 그 과정에서 고객은 돈이 빠져나갔다가 돌아오는 걸 보며 불안해하고, 재결제가 안 되면 주문 자체가 깨집니다. 결제 연동 개발에서 이런 예외 흐름을 처음부터 설계했느냐가 품질을 가릅니다.

PG사와 결제대행, 용어부터 정리하기

견적을 받다 보면 PG, VAN, 간편결제, 오픈마켓 정산 같은 말이 섞여 나옵니다. 역할이 다르기 때문에 내 서비스에 뭐가 필요한지 먼저 구분해야 합니다.

온라인 서비스라면 보통 PG 한 곳을 중심에 두고 그 위에 간편결제 몇 개를 얹는 구조가 일반적입니다. 문제는 PG마다 연동 방식(API 규격, 결제창 호출 방식, 정산 데이터 포맷)이 다르다는 점입니다. 그래서 "나중에 PG를 바꾸면 되지"라고 가볍게 생각하면, 바꿀 때 결제 코드를 거의 다시 짜야 하는 상황이 생깁니다.

결제 연동에서 가장 많이 터지는 7가지

실무에서 결제 연동이 운영 사고로 번지는 지점은 대부분 정해져 있습니다. 개발사에 맡기기 전에 이 7가지가 설계에 들어가 있는지 확인하는 것만으로도 상당수 사고를 막을 수 있습니다.

1. 결제 성공했는데 주문이 안 생기는 경우

고객 카드에서는 돈이 빠졌는데 우리 DB에는 주문이 없는 상황입니다. 결제창 응답만 믿고 주문을 생성하면, 고객이 중간에 창을 닫거나 네트워크가 끊길 때 결제와 주문이 어긋납니다. 이걸 막으려면 PG가 서버로 직접 쏘는 결제 통보(웹훅, noti)를 받아 한 번 더 대조하는 구조가 필요합니다.

2. 같은 결제가 두 번 들어오는 중복 결제

고객이 결제 버튼을 두 번 누르거나 새로고침할 때 같은 주문이 두 번 결제될 수 있습니다. 주문마다 고유 번호를 두고, 이미 처리된 건은 막는 처리가 없으면 그대로 이중 청구가 됩니다.

3. 부분 취소와 부분 환불

위에서 설명한 흐름입니다. 여러 상품을 묶어 결제한 뒤 일부만 환불하는 경우, 배송비는 어떻게 할지, 쿠폰으로 할인받은 금액은 어떻게 돌려줄지까지 규칙이 있어야 합니다.

4. 정산 데이터와 실제 입금 맞추기

PG가 주는 정산 내역과 우리 장부가 맞는지 확인하는 작업입니다. 플랫폼이라면 여기에 판매자별 수수료 떼고 송금하는 과정까지 더해집니다. 이 부분을 수작업 엑셀로 하면 거래가 늘수록 사람이 버티지 못합니다.

5. 결제 수단별 다른 규칙

카드, 계좌이체, 가상계좌, 간편결제는 승인과 취소 가능 기간, 수수료, 환불 방식이 다 다릅니다. 가상계좌는 입금 전까지 미결제 상태로 관리해야 하고, 입금이 안 되면 자동으로 주문을 정리하는 흐름도 필요합니다.

6. 결제 금액 위변조 방지

결제 금액을 화면에서 넘기는 값만 믿으면, 악의적인 사용자가 1만원짜리를 10원으로 바꿔 결제를 시도할 수 있습니다. 서버에서 실제 주문 금액을 다시 계산해 PG로 보내고, 승인된 금액과 대조하는 검증이 반드시 들어가야 합니다.

7. 카드 정보는 우리가 저장하지 않는다

카드 번호 같은 민감 정보를 직접 저장하면 보안 책임과 규제 부담이 급격히 커집니다. 실제 카드 정보는 PG가 보관하고, 우리는 결제 식별용 키(빌링키 등)만 받아 쓰는 구조로 가야 합니다. 정기결제가 필요한 서비스일수록 이 설계가 중요합니다.

결제 연동 개발, 직접 할까 맡길까

결제 연동은 PG가 제공하는 문서와 샘플 코드가 있어서 "생각보다 쉬워 보인다"는 함정이 있습니다. 결제창 한 번 띄우는 것까지는 하루면 되지만, 앞에서 말한 예외 흐름과 정산까지 운영 수준으로 만드는 건 전혀 다른 일입니다.

내부에 결제 경험이 있는 개발자가 있다면 직접 하는 것도 방법입니다. 하지만 결제가 핵심 매출 경로라면, 예외 흐름을 다뤄 본 팀에 맡기는 편이 결과적으로 비용을 아끼는 경우가 많습니다. 결제는 한번 사고가 나면 그 복구 비용이 개발비를 넘어서기 때문입니다.

우리가 실제로 다룬 결제 흐름들

어니스트패밀리는 결제가 단순 결제창을 넘어서는 프로젝트를 여러 번 진행했습니다. 가상의 사례가 아니라 실제로 구축한 것들입니다.

구독형 창고대여 플랫폼에서는 매달 구독료를 자동으로 받으면서 점주별로 수익을 자동 정산하는 구조를 만들었습니다. 결제와 정산이 한 흐름으로 돌아가야 해서, 단순 정기결제보다 설계가 복잡했습니다. 운영 중이던 데이터를 멈추지 않고 옮기는 작업까지 함께 진행했습니다.

구독형 농작물 쇼핑몰에서는 정기 구독과 단품 구매가 한 장바구니에서 섞이는 상황을 다뤘습니다. 레시피를 보고 재료를 바로 구매로 연결하면서, 주문과 정산을 하나의 관리자에서 통합해 관리하도록 만들었습니다. 체험단 매칭 플랫폼에서는 광고주와 인플루언서 사이의 정산 흐름을 운영팀이 직접 조정할 수 있게 설계를 확장해 왔습니다.

대기업 SaaS 서비스에서는 크레딧 기반 API 과금(번역, OCR을 쓴 만큼 차감)과 SDK 라이선스 발급을 함께 다뤘습니다. 쓴 만큼 돈이 빠지는 구조는 일반 결제와 또 달라서, 잔액 검증과 보안 설계가 핵심이었습니다.

결제 연동 개발 비용은 왜 업체마다 다를까

같은 "결제 연동"이라는 말을 쓰는데 견적이 두세 배 차이 나는 이유는, 포함하는 범위가 다르기 때문입니다. 결제창 하나 붙이는 견적과 예외 흐름, 정산, 대사까지 포함한 견적은 애초에 다른 작업입니다.

위시켓이나 크몽 같은 매칭 플랫폼에서 결제 연동 건을 올리면 단가가 낮은 제안부터 높은 제안까지 폭넓게 들어옵니다. 싼 제안이 나쁜 건 아니지만, 그 견적이 어디까지 포함하는지는 반드시 확인해야 합니다. 결제창까지만 잡은 견적이면 정산과 예외 처리는 나중에 추가 비용으로 돌아옵니다. 견적서를 받을 때 "부분 취소, 결제 통보 대조, 정산 자동화가 포함되는지"를 한 줄로 물어보는 것만으로 많은 게 분명해집니다.

자주 묻는 질문

결제 연동만 따로 개발 외주를 줄 수 있나요?

가능합니다. 다만 결제는 주문, 회원, 상품 데이터와 맞물려 있어서, 기존 시스템 구조를 모르는 상태로 결제만 떼어 붙이면 정산이나 환불에서 어긋나기 쉽습니다. 기존 코드를 넘겨받아 흐름을 파악한 뒤 작업하는 게 안전합니다.

PG사는 어디를 고르는 게 좋나요?

거래 규모, 수수료, 정산 주기, 지원하는 결제 수단을 기준으로 보시면 됩니다. 토스페이먼츠, 나이스페이먼츠, KG이니시스 등이 많이 쓰이고, 간편결제는 고객층에 따라 카카오페이나 네이버페이를 함께 붙이는 경우가 많습니다. 어느 곳이든 나중에 바꿀 가능성을 염두에 두고, 결제 로직을 PG에 너무 깊게 묶지 않는 설계가 중요합니다.

정기결제(구독)도 결제 연동에 포함되나요?

포함될 수 있지만 일반 단건 결제보다 설계가 복잡합니다. 카드 정보를 대신하는 빌링키 관리, 결제 실패 시 재시도, 구독 변경과 해지 처리까지 들어가기 때문입니다. 구독 모델을 생각하고 있다면 처음부터 이 부분을 범위에 넣어 설계하는 걸 권합니다.

결제 흐름부터 한번 점검해 보세요

결제는 기능 목록의 한 줄이 아니라, 돈이 실제로 오가는 서비스의 심장입니다. 지금 준비 중인 서비스에 결제 통보 대조, 부분 환불, 정산 자동화 같은 흐름이 설계에 들어가 있는지 한번 짚어 보시면 좋겠습니다. 어디까지 필요한지 애매하다면, 지금 그리고 있는 결제 흐름을 놓고 무료로 한번 이야기 나눠 보셔도 됩니다. 풀스택 개발자 출신 대표가 직접 보고, 어떤 범위가 맞을지 편하게 말씀드리겠습니다.