핵심 요약
- 온라인 결제는 고객 - 가맹점(우리) - PG사 - 카드사/은행이라는 4가지 핵심 주체가 움직이는 과정이에요.
- PG사는 복잡한 카드사와의 계약과 시스템 연결을 대신해주는 '통합 결제창' 역할을 해요.
- 단건 결제인지 빌링 결제인지에 따라 주문 흐름을 어떻게 설계할지, 회원/비회원 구조에 따라 취소·환불을 어떻게 운영할지를 먼저 정해야 해요.
- 결제가 완료되었다고 해서 바로 돈이 들어오는 것은 아니며, 일반 서비스는 보통 D+5 안팎의 입금 시차를 이해하면 돼요. 만약 중개플랫폼일 경우 별도로 정산 처리 업무가 추가돼요.
이런 상황이라면
"대표님, 카드 결제 붙여야 하는데 PG사는 어디로 하실 거예요?"
외주 개발사의 질문에 당황해요. 카드 결제면 카드사랑 얘기하면 되는 거 아닌가? PG는 또 무엇이며, 왜 우리 서비스와 카드사 사이에 누군가 끼어있어야 하는지 감이 오지 않아요. 당장 내일 결제창을 띄워야 하는데 용어부터 막히기 시작해요.
이 글은 온라인 결제의 뼈대를 빠르게 잡고 싶은 사람을 위해 전체 구조를 프로세스 중심으로 다뤄요.
1온라인 결제에 등장하는 4가지 역할
온라인 결제는 생각보다 이해관계자가 많아요. 먼저 아래 4가지만 구분하면 전체 구조가 훨씬 쉬워져요.
- 고객 (Customer): 우리 서비스에서 물건이나 서비스를 사고 돈을 내는 주체예요.
- 가맹점 (Merchant): 물건을 파는 '우리 서비스'예요. PG사와 계약을 맺고 결제 시스템을 도입해요.
- PG사 (Payment Gateway): 결제대행사예요. 가맹점과 카드사 사이에서 결제창을 대신 제공하고, 카드 정보를 안전하게 처리·보관하며, 카드사로부터 받은 정산금을 가맹점에 전달하는 역할을 해요.
- 카드사/은행 (Issuer): 실제로 돈을 승인하고 내어주는 곳이에요. 고객의 한도를 확인하고 결제를 최종 승인해요.
[관계도]
- 고객의 결제 요청은 오른쪽으로 전달되고, 승인 결과와 결제 상태는 같은 경로를 반대로 되돌아와요.
2결제 한 건이 흐르는 경로
고객이 '결제하기' 버튼을 누른 순간부터 우리 회사 통장에 돈이 찍히기까지의 과정은 크게 승인과 정산으로 나뉘어요.
1단계: 결제 승인 (실시간)
- 고객 클릭: 우리 앱/웹에서 결제 수단을 선택하고 버튼을 눌러요.
- 결제창 호출: PG사가 제공하는 결제창이 떠요. 이때 카드 번호를 입력하거나 간편결제 인증을 해요.
- 인증 및 승인 요청: PG사가 고객 정보를 카드사에 전달하고, 카드사가 본인인증·한도확인·승인을 함께 판단해요.
- 최종 승인: 카드사가 오케이(OK)하면 실시간으로 "결제가 완료됐어요" 문구가 떠요.
2단계: 매입 및 정산 (수일 소요)
온라인 결제에서는 보통 PG가 우리(가맹점)에게 정산금을 지급하는 구조예요. 그래서 승인이 났다고 해서 바로 우리 회사 통장에 돈이 들어오는 것은 아니에요.
- 전표 매입: 승인된 거래가 실제 정산 대상 거래로 확정돼요. 실무에서는 이 단계를 흔히 '전표 매입'이라고 불러요.
- 카드사 → PG사 지급: 확정된 거래에 대해 카드사가 PG사로 정산 대금을 지급해요.
- PG사 → 가맹점 입금: PG사가 계약 주기에 따라 가맹점 계좌로 최종 입금해요.
여기서 중요한 것은 세부 정산 경로를 외우는 것이 아니라, 승인과 입금이 같은 순간에 일어나지 않는다는 점이에요. 이 글에서는 흐름만 단순화해 설명하며, 실제 정산 경로와 처리 주체는 PG 구조와 계약 방식에 따라 달라질 수 있어요.
일반적인 단일 가맹점 서비스라면 여기서 '승인 완료'와 '입금 완료' 사이에 보통 D+5 안팎의 시차가 있다는 점 정도를 이해하면 충분해요. 다만 여러 판매자가 얽힌 중개플랫폼이라면, 이 다음 단계에서 취소·환불 건을 언제 정산에서 차감할지까지 별도 정책이 필요해져요.
3PG사는 왜 필요할까요
"카드사랑 직접 계약하면 수수료가 더 쌀 텐데, 왜 굳이 PG사를 써야 하나?"라는 의문이 생길 수 있어요. 이유는 명확해요. 관리가 불가능하기 때문이에요.
- 계약의 번거로움: PG사 없이 결제를 붙이려면 신한, 삼성, 현대 등 국내 8~9개 카드사와 일일이 계약을 맺어야 해요. PG사를 쓰면 계약 한 번으로 모든 카드 결제를 받을 수 있어요.
- 보안 및 기술 책임: 카드 번호 같은 민감 정보는 가맹점이 직접 저장할 수 없어요. PCI-DSS 같은 카드 업계 보안 인증을 받은 PG사 환경 안에서만 처리·보관되며, 빌링키·간편결제 재사용도 이 위에서 돌아가요. PG사는 이 보안 인프라를 대신 구축·운영해주는 대가로 수수료를 받아요.
- 통합 관리: 카드사별로 제각각인 정산 주기와 입금 내역을 PG사가 하나로 묶어서 관리 페이지를 제공해요. 운영 효율 측면에서 소규모 팀일수록 PG는 선택이 아닌 필수예요.
4실제 연동의 3가지 구성 요소
실제 연동에서는 개발팀이 세 층을 동시에 다뤄요. 어느 층 이야기인지 구분하면 커뮤니케이션이 훨씬 정리돼요.
- 클라이언트 SDK: 고객 화면에서 PG사 결제창을 띄우고 결제 결과를 돌려받아요. 카드 입력·인증은 PG사 결제창 안에서 이뤄지므로 가맹점 코드가 카드 정보를 직접 다루지 않아요.
- 서버 API: 승인 결과를 서버에서 한 번 더 검증하고, 취소·빌링키 관리·구독 결제를 직접 호출해요.
- 관리자 화면: 키 발급, 정산 주기 확인, 웹훅 엔드포인트 설정. 대부분 1회 세팅 후 유지.
여기서는 "클라이언트에서 결제가 끝나면 서버에서 한 번 더 확인해요" 정도만 알고 있으면 충분해요. 그 이상은 개발 구현 영역이에요. 실제 엔드포인트·필드는 개발자 문서 — 결제 개요에서 볼 수 있어요.
5이 구조에서 먼저 정해야 할 3가지
개발자가 코드를 짜기 전에 먼저 정리되어야 하는 핵심 결정은 다음과 같아요.
① 단건 결제인지, 빌링 결제인지 먼저 구분해야 해요
여기서 가장 먼저 던져야 할 질문은 "카드 한 번 받고 끝나는 서비스인가, 아니면 빌링키를 발급받아 반복 결제하는 서비스인가"예요. 단건 결제라면 결제 요청 → 승인 → 완료/취소 흐름이 중심이지만, 빌링 결제라면 빌링키 발급, 결제 요청, 결제 실패 시 보완, 다음 결제 예약, 빌링키 해지 까지 함께 설계해야 해요. 즉 결제수단 나열보다 서비스 과금 구조에 따라 주문 흐름이 완전히 달라진다는 점을 먼저 잡아야 해요.
② 서비스 유형에 맞는 주문 흐름을 먼저 정해야 해요
결제는 단순히 "버튼 누름 → 완료"로 끝나지 않아요. 단건 결제는 결제 요청, 인증, 승인, 실패, 취소, 가상계좌라면 입금 대기, 입금 후 웹훅까지 생겨요. 결국 먼저 해야 할 일은 결제 시나리오를 먼저 이해하고, 우리 서비스에 맞게 적용 및 검토하는 것이에요.
③ 회원 결제인지 비회원 결제인지에 따라 취소·환불 운영이 달라져요
같은 카드 결제라도 회원 서비스와 비회원 서비스는 운영 방식이 달라요. 회원제라면 마이페이지에서 취소 내역 조회, 환불 상태 확인, 정기결제 해지 같은 흐름을 붙일 수 있어요. 반면 비회원 결제라면 주문번호, 휴대폰번호, 주문 비밀번호 같은 별도 조회 수단을 마련해야 하고, 취소 요청을 어디서 받는지도 따로 설계해야 해요. 즉 단순히 "결제가 돼요"가 아니라 회원/비회원 구조에 따라 취소·환불을 어떻게 찾고, 요청하고, 처리할지까지 정해야 해요.
정산은 이 3가지에 비해 일반 결제 서비스에서 우선순위가 조금 뒤예요. 보통 단일 가맹점 서비스는 PG사와 계약한 주기에 따라 D+5 안팎으로 정산을 받기 때문에, 자금 흐름과 입금 시차 정도만 이해하면 돼요. 다만 중개플랫폼은 판매자에게 돈을 나눠줘야 하고 이후 취소·환불이 발생하면 이미 지급한 정산금을 다시 차감해야 할 수 있어요. 그래서 이런 구조에서는 당월 취소를 반영하기 위해 익월 정산, 익익월 정산처럼 여유를 두는 정책이 실무적으로 중요해져요.
실제로 붙이려면
용어와 흐름이 잡혔다면 코드 진입점은 다음 두 곳이에요.
- 결제 SDK 소개 — /guide/intro
- 결제 흐름 — /guide/payment-flow