-
카드사와 가맹점 사이의 결제/정산 프로세스 정리어쩌다보니 알게 되는 것들.../비즈니스 도메인 2026. 6. 21. 18:24반응형
사용자는 카드로 결제 버튼을 누르지만, 실제로는 카드사, PG사, VAN사, 카드 네트워크, 은행, 가맹점 등 여러 기관이 복잡하게 데이터를 주고받으며 돈을 이동시킨다. 이번 글에서는 국내 신용카드 결제 및 정산 시스템을 기준으로 전체 프로세스를 정리해보겠다.
결제 생태계 참여자
먼저 등장인물을 알아보자.
1. 소비자(Card Holder)
카드를 소유한 고객
예)
- 신한카드 사용자
- 삼성카드 사용자
2. 가맹점(Merchant)
상품이나 서비스를 판매하는 사업자
예)
- 쿠팡
- 배달의민족
- 스타벅스
3. PG사(Payment Gateway)
온라인 쇼핑몰과 카드사를 연결
대표 기업
- KG이니시스
- NHN KCP
- 토스페이먼츠
역할
- 카드 승인 요청 전달
- 결제 결과 수신
- 가맹점 정산 지원
4. VAN사(Value Added Network)
오프라인 카드 단말기 네트워크 사업자
대표 기업
- KIS정보통신
- 나이스정보통신
- 한국정보통신
역할
- 단말기 ↔ 카드사 연결
- 승인 중계
5. 카드사(Issuer)
카드를 발급한 회사
예)
- 신한카드
- 삼성카드
- KB국민카드
역할
- 승인 여부 판단
- 한도 관리
- 고객 청구
6. 매입사(Acquirer)
가맹점의 카드 매출을 매입하는 회사
국내에서는 대부분 카드사가 직접 수행한다.
전체 흐름 한눈에 보기
고객 ↓ 가맹점 ↓ PG/VAN ↓ 카드사 ↓ 승인결과 PG/VAN ↓ 가맹점 (승인 완료) ------------------- 카드사 ↓ 매입 ↓ 정산 ↓ 가맹점 계좌결제는 크게
- 승인(Authorization)
- 매입(Capture)
- 정산(Settlement)
3단계로 나뉜다.
1단계 : 승인(Authorization)
사용자가 10만원 상품 구매
고객 ↓ 결제 요청 ↓ 가맹점
승인 요청 생성
가맹점 서버는 다음 데이터를 생성
{ "amount": 100000, "cardNo": "****", "merchantId": "M1234", "orderId": "ORD-001" }
PG 전송
가맹점 ↓ PG
카드사 승인 심사
카드사는 카드 상태, 한도, 도난 신고 여부, 이상 거래 탐지(FDS) 검사
승인 가능 → 승인 문제 발생 → 거절
승인 응답
{ "result": "SUCCESS", "approvalNo": "12345678" }승인번호가 생성된다.
승인과 실제 출금은 다르다
많은 사람들이 착각하는 부분이다. 승인 = 돈이 이동한 것 아니다.
승인은 "이 카드에서 나중에 돈을 받을 권리를 확보했다"에 가깝다.
실제 돈은 아직 이동하지 않았다.
2단계 : 매입(Capture)
승인 완료 후 가맹점 매출 데이터를 카드사가 가져간다.
이를 매입이라고 한다.
매입 데이터
{ "approvalNo": "12345678", "amount": 100000 }카드사는 승인 데이터와 대조
승인 O 매입 O이면 거래 확정
3단계 : 대금 청구(Clearing)
매입이 완료되면
카드사는 고객에게 청구할 금액을 확정한다.
예)
6월 1일 결제 6월 2일 매입 → 청구 대상 등록
고객 명세서
넷플릭스 17,000원 배달의민족 22,000원 쿠팡 61,000원
4단계 : 카드대금 수납
결제일 도래
고객 계좌 ↓ 카드사카드사는
- 자동이체
- 계좌 출금
으로 돈 회수
5단계 : 가맹점 정산
가장 중요한 단계
카드사는 먼저 지급한다
실제 구조는
고객 (아직 안 냄) 카드사 ↓ 가맹점 지급즉
카드사가 신용을 제공
정산 금액 계산
예)
결제금액 100,000원 카드수수료 2.0% PG수수료 0.3%
100,000 -2,000 -300 -------- 97,700원입금
정산 주기
보통
D+2 D+3 D+5
예)
월요일 승인 수요일 정산
실제 돈 흐름
[결제 시점] 고객 ↓ 카드 승인 카드사 ↓ 정산 예정 가맹점 ----------------- [정산 시점] 카드사 ↓ 97,700원 가맹점 계좌 ----------------- [청구일] 고객 계좌 ↓ 카드사즉, 카드사가 중간에서 자금을 선지급한다.
취소 프로세스
승인 취소
당일 취소
승인 ↓ 즉시 취소매입 전, 흔적 없이 제거
매입 후 취소
승인 ↓ 매입 ↓ 취소이미 정산 진행
이 경우
카드사 ↓ 마이너스 정산발생
부분 취소
예)
100,000원 결제 30,000원 환불
남은 금액 70,000원정산 시스템에서 매우 복잡한 영역 중 하나
실무에서 자주 발생하는 문제
승인 성공 + DB 실패
카드사 승인 O 우리 서버 저장 X가장 위험한 상황
중복 승인
사용자 새로고침 결제 2번
승인 성공 + 응답 유실
카드사 → PG 응답 네트워크 장애
정산 금액 불일치
카드사 집계 ≠ 가맹점 집계
부분 취소 누락
100,000 결제 30,000 취소 70,000 정산되어야 함결제 시스템의 본질은 "승인"이 아니라 "채권과 채무를 관리하고 정산하는 회계 시스템"에 가깝다. 실제 정산 시스템은 이벤트 소싱(Event Sourcing)에 구조로 설계되는 경우가 많다.
반응형