PG / VAN 이란?
PG (Payment Gateway)
PG == 전자결제를 대행하는 업체
전자결제 대행 서비스란, 인터넷 쇼핑몰에서 상품 및 서비스를 구매하는 고객들의 결제(신용카드 및 기타 결제수단)를 중계하는 서비스를 의미한다.
PG는 왜 필요한가? 무슨 일을 하나?
온라인 카드 결제를 처리할 때, PG가 하는 일은 다음과 같다. (e.g., mpi 일반결제)
- VAN과 계약 하고
- ㅇㅇ카드, ㅁㅁ카드, ... 선택 페이지 만들고
- ㅇㅇ카드 선택 시 VAN에서 요구하는 파라미터들과 함께 팝업으로 VAN을 호출
- VAN은 VAN 페이지 -> 카드사 페이지로 포워딩
- 카드사 페이지에 카드 번호 입력해서 카드사 측에서 인증이 완료되면, 카드사는 인증 완료되었다는 키값을 돌려주고
- 이 키 값을 이용해서 VAN에 승인 요청
- TCP 전문으로 되어 있음.
- 승인 완료되면 사용자 입장에서는 결제 완료
- 하지만 PG는 승인 데이터를 잘 모아다가 이후 VAN(을 통해 카드사)에 매입을 청구해야 함.
- 이래야 실제로 카드사에게서 돈을 받을 수 있음.
- 승인의 의미는 가맹점에 해당 거래 전표를 매입해주겠다는 의미
- 매입 이후에는 정산 과정이 있음. 그리고 정산 받은 돈이 맞는지 안맞는지 검증.
*** 이 밖에 간편결제 서비스 등 카드와 관련된 온라인 서비스 단의 요구사항을 도맡아 처리하는 것이 PG
- 내가 온라인 쇼핑몰을 하나 열었다고 가정해보면, PG를 안쓰고 이러한 일들을 직접 한다는건 거의 불가능하다.
- 네이버, 배민, 요기요 등 여력이 있는 IT 회사는 사내에 자체 PG를 운용함.
- 수수료 절감 및 커스터마이징 목적 (Npay 라던가.)
- 수수료 절감이지만 이런 회사들은 거래액이 하도 크다 보니 액수가 상당함.
VAN (Value Added Network)
- 부가 가치 통신망
- 회선을 소유하는 사업자로부터 통신회선을 빌려 독자적인 통신망을 구성하고, 거기에 어떤 가치를 부가한 통신망
- 즉, 네트워크를 구축한 다음 이 통신망 이용을 제3자에게 판매하는 네트워크를 의미한다.
- KCP, ksnet, nice, lguplus 이런 곳이 VAN사. (PG를 같이 하는 경우도 있다.)
VAN은 무슨 일을 하나? 왜 필요한가?
VAN의 본질은 네트워크 사업자다.
- 카드사에 승인, 매입 등을 요청하려면 각 카드사와 연결된 전용선을 사용해야만 함.
- VAN은 각각의 카드사와 전용선으로 연결되어 있고, 이 통신망을 사용할 수 있도록 중계해주는게 핵심.
- 즉, 이러한 전용선을 직접 다 개통하는 수고스러움을 대신해주는 것이 VAN의 핵심이다.
- 오프라인이든 온라인이든, 카드사로 승인을 내거나 매입을 보내고 싶다? VAN을 타야한다.
오프라인 ) 결제 단말기 공급 업무
- 오프라인 결제 시, 결제 정보가 전송되는 시작 지점은 카드 단말기다.
- 원래 1개의 카드 단말기는 1개의 카드사와 연결되어 있기 때문에, 각 카드사의 전용 단말기가 모두 필요하다. (ex, 삼성 카드 단말기, 신한 카드 단말기, ...) 너무 비효율적이다.
- 그래서 VAN사는 이런 각각의 단말기를 하나의 단말기로 통합하여 제공하고 있다.
- 이 것이 가능한 이유는 VAN이 각 카드사와 전용선을 다 뚫어 놓았기 때문인 것이고. 받아서 카드사 식별해서 카드사로 전달한다.
* 오프라인 상점에 카드 결제 단말기를 제공하는게 핵심이라기 보다는 이 단말기를 통해 카드결제승인을 받을 수 있게 VAN사 네트워크를 통해서 승인중계업무를 하는게 핵심이다.
오프라인 ) 자체매입
- 온라인의 경우 PG가 매입전표 수거해서 VAN으로 매입을 보낸다지만, 작은 오프라인 가맹점이 이러한 매입청구 능력을 갖추기란 어렵다.
- 그래서 VAN이 매입업무를 대행해주고 있음. 승인 내역을 바탕으로 매입청구 데이터 생성해 카드사로 전송.
- 실제 매입전표 제출하는게 아니라 매입청구 데이터 만들어서 전송하는 듯
- 확인 대사를 위해 대리점을 통해서 매출전표를 따로 수거하긴 한다고 함.
온라인 ) PG -> VAN
- PG는 VAN에 승인, 매입 요청하고, VAN은 이를 카드사로 전달
- 카드사 마다 다른 전문 스펙을 어느정도 단일화 하는 역할도 하고 있는 듯.
- 본인들이 받아서 분기치면서 각 카드사 스펙에 맞게 넣어주는 듯?
- 다만 어디까지나 "일부분"이다.
- 매입검증대사
- 가맹점A는 VAN사 [x,y,z]와 계약을 한 상태. 이 중 x는 매입 VAN이며, 나머지 y, z는 승인만 한다.
- 즉 승인은 [x,y,z]로 매입은 x로.
- 매입 VAN x는 y, z로부터 승인 내역을 받고, 가맹점 A로부터 매입 내역을 받아서 [승인내역<>매입내역] 비교 대사를 진행해준다.
- "y 승인 내역에는 있는데 매입 내역에는 없다" 같은 불일치건들을 메일링해줌.
- 가맹점A는 VAN사 [x,y,z]와 계약을 한 상태. 이 중 x는 매입 VAN이며, 나머지 y, z는 승인만 한다.
3당사자 모델, 4당사자 모델
용어 정리
매입사: Acquirer, 발급사: Issuer
승인 : Approval
가맹점→매입사 전표 전송 : Batching
매입사→발급사 전표 전송 : Clearing (매입사 != 발급사인 4당사자 모델에만 존재)
정산 : Settlement
https://www.mastercard.com/eea/switching-services/our-technology/transaction.html
- 3당사자 모델 : 브랜드사, 발급사, 매입사가 동일
- 4당사자 모델 : 브랜드사, 발급사, 매입사가 모두 상이
우리나라의 3당사자 모델 : VAN은 한국에만 있다. 해외에는 없음.
- 3당사자 모델의 신용카드사(네트워크+발급사+매입사) 에서 네트워크만 VAN으로 분리되어 중간에서 대행하는 구조
- 우리나라 3당사자 모델은 신용카드사(발급사+매입사), VAN(네트워크) 이렇게 구성된다.
- 우리나라는 발급사와 매입사가 1:1구조이므로 신용카드사(발급사+매입사) 구조가 맞다.
- BC만 좀 예외로 발급사와 매입사가 n : 1 구조다.
개발 할 때는...
- 신용카드사가 VAN으로 완전히 가려진다면(완전히 추상화 되어 우리가 구분할 필요가 없다면) VAN을 카드사로 보고 개발할 수는 있는데,
- 보통 VAN은 대행만 하는 경우가 많아 VAN 뒤에 있는 신용카드사를 완전히 가리지 못한다. 이는 즉 신용카드사에 따른 구분이 들어가야 한다는 것을 의미한다.
VAN도 actor라고 보면 4당사자 모델 아닌가?
- 4당사자 모델의 경우 당사자는 [발급사, 매입사, 회원, 가맹점]
- 우리나라의 경우 [신용카드사(발급사+매입사), VAN, 회원, 가맹점]
- VAN을 당사자로 보더라도 기존의 4당사자 모델과 일치하지는 못하며, (3당사자 + Network)라고 보는 것이 적절하다.
BC는 뭐야?
BC카드의 경우 회원사 / 고객사가 나뉘어져 있고
회원사는 결제 처리 방식에 따라 두 종류로 분류 가능
- case1 ) BC로 결제가 들어오면 발급사를 거치지 않고 BC에서 자체적으로 승인
- case2 ) BC로 결제가 들어오면 발급사로 보내고, 발급사에서 승인 낸 후 결과를 BC로 전달하고, BC가 승인 값 전달
고객사는 BC의 가맹점 네트워크만 빌려쓰는 형태. 카드는 자체 브랜드이므로 BC가 붙어있지 않다.
BC카드 내의 MSS 시스템이라는 것이 VAN 역할을 하게 되어
BC의 13개 회원사 및 승인매입중계만 하는 고객사의 결제건은 모두 BC MSS 시스템으로 보내면 된다.어찌 되었건 BC 앞단에서는 BC만 신경쓰면 되는 구조
매입은 왜 필요?
- 신용 거래이기 때문에, 매입 절차를 두면 카드사는 가맹점에 대금 지급을 보류하고 검증 프로세스를 돌릴 수 있다.
- 온라인 결제의 경우 결제 시점에 거래 유효성 검증이 가능하지만, 카드의 시작이 오프라인이고 거기에 끼워 맞추는 식으로 하다 보니 온라인/오프라인 상관 없이 매입 절차가 있다.
- 그러나 최근 온라인 결제에 대해서는 위와 같은 이유로 매입 절차를 생략하는 경우도 있다.
미국의 4당사자 모델 diagram
'Liberal arts > Payment' 카테고리의 다른 글
지급결제란? (0) | 2019.10.09 |
---|