VAN과 PG

결제 시스템을 연동해 개발하다 보면 VAN, PG 같은 단어를 계속 마주하게 된다. 처음에는 둘 다 "카드 결제를 붙여주는 곳"처럼 보인다. 하지만 코드를 설계할 때는 둘을 같은 provider로 취급하면 금방 애매해진다. 승인 요청을 어디로 보내는지, 정산은 누가 묶어주는지, 장애가 났을 때 어떤 로그를 봐야 하는지가 달라지기 때문이다.

먼저 정의부터 나누기

VAN은 Value Added Network의 약자로, 카드사와 가맹점 사이에서 카드 승인과 매입 데이터를 중계하는 통신망이다. 오프라인 매장의 POS나 카드단말기에서 발생한 승인 전문을 카드사로 보내고, 승인번호와 응답을 다시 단말기 쪽으로 돌려주는 역할에 가깝다.

PG는 Payment Gateway의 약자로, 온라인 상점이 카드, 계좌이체, 가상계좌, 간편결제 같은 결제수단을 받을 수 있게 해주는 결제 대행 계층이다. 결제창, 인증 결과, 승인 API, 취소, 정산 리포트, webhook 같은 기능을 묶어서 제공하는 경우가 많다.

국내 VAN의 대표적인 회사로는 한국정보통신(KICC), NICE정보통신, KIS정보통신, KSNET, KOVAN 등이 있다. 오프라인 매장, POS, 카드단말기, VAN 터미널 ID, CATID 같은 단어와 같이 등장하는 경우가 많다.

국내 PG의 대표적인 회사로는 KG이니시스, NHN KCP, 토스페이먼츠, 나이스페이먼츠, 한국정보통신 이지페이 등이 있다. 온라인 결제창, API 승인, 결제 취소, 정산 리포트, webhook 같은 기능을 붙일 때 주로 마주친다.

다만 회사 이름이 곧 역할 하나를 뜻하지는 않는다. 예를 들어 한국정보통신(KICC)은 개발자 문서에서 온라인 결제, 간편 결제, VAN 결제를 나눠 제공하고, NICE정보통신도 오프라인 결제 네트워크와 온라인 전자결제를 함께 소개한다. 그래서 대표 사업자를 알되, 실제 연동에서는 지금 쓰는 상품이 VAN 흐름인지 PG 흐름인지 다시 확인해야 한다.

시작점이 다르다

오프라인 카드 결제에서 먼저 보이는 것은 단말기다. 고객이 카드를 꽂거나 태그하면 POS와 카드단말기가 거래 금액, 단말 식별자, 가맹점 정보를 VAN 쪽으로 보낸다. VAN은 그 승인 전문을 카드사로 넘기고 승인번호를 돌려준다. 여기서 핵심은 결제창이 아니라 단말기, 승인번호, 매입, 일마감, 통신 안정성이다.

온라인 결제에서 먼저 보이는 것은 주문 흐름이다. 서비스 서버는 주문번호와 금액을 만들고, PG 결제창이나 API를 통해 고객 인증을 진행한다. 결제가 끝나면 redirect, callback, webhook, 거래 조회로 상태를 확인한다. 여기서 핵심은 결제수단 묶음, 인증 결과 검증, 부분취소, 정산 리포트, 멱등 처리다.

VAN 중심

POS와 단말기에서 승인 요청이 시작된다.
VAN 터미널 ID, CATID, 승인번호, 매입 데이터가 운영의 중심이 된다.
장애를 보면 PC, 단말기, 케이블, VAN망, 카드사 응답을 같이 추적한다.

PG 중심

주문과 결제 의도에서 요청이 시작된다.
payment key, webhook, 정산 상태, 취소 상태가 운영의 중심이 된다.
장애를 보면 인증 완료, 승인 API, callback, 내부 주문 반영을 나눠 추적한다.

회사 이름만으로는 부족하다

헷갈리는 지점은 국내 결제사가 한 역할만 하지 않는다는 데 있다. VAN으로 알려진 회사가 PG 상품도 운영하고, 온라인 결제창처럼 보이는 상품이 실제로는 오프라인 가맹점의 VAN 기반 비대면 결제로 동작하기도 한다. 그래서 회사 이름보다 거래가 어떤 레이어를 타는지 봐야 한다.

연동 코드에서 갈리는 지점

이 구분은 연동 코드에서 바로 갈린다. VAN 거래는 어떤 단말 식별자로 승인됐는지가 중요하다. 한국정보통신(KICC) 문서에서는 vanTid를 VAN 터미널 ID로 받고, NICE정보통신 문서에서는 CATID(TID, TerminalID)처럼 묶어 부른다. 이름은 다르지만 둘 다 "이 승인 요청이 어떤 VAN 단말 문맥에서 나갔는가"를 가리키는 값으로 봐야 한다.

반대로 PG 거래는 단말 식별자보다 주문번호, 결제창 인증 결과, 승인 API 결과, webhook 이벤트, 정산 상태가 더 앞에 온다. 그래서 내부 모델도 달라진다. VAN 연동에서는 provider별 단말 식별자와 승인번호, VAN 거래번호, 원거래 참조값을 원문 그대로 보관하는 쪽이 중요하고, PG 연동에서는 결제 의도와 외부 결제키, 이벤트 멱등성 키를 중심으로 잡는 편이 자연스럽다.

구분 기준은 거래 단위다

그래서 "NICE정보통신은 VAN인가 PG인가", "한국정보통신(KICC)은 VAN인가 PG인가"처럼 회사 이름으로만 분류하면 다시 헷갈린다. 같은 회사 안에서도 오프라인 단말 승인, VAN 기반 비대면 결제창, 온라인 PG 결제창은 저장해야 할 값과 장애 대응 방식이 다르다.

내부에서는 회사명을 기준으로 provider를 나누되, 실제 처리는 거래가 타는 레이어를 기준으로 나누는 편이 안전하다. 단말에서 시작해 VAN 터미널 식별자로 승인되는 거래인지, 주문에서 시작해 PG 결제창과 webhook으로 상태가 돌아오는 거래인지가 더 중요한 기준이다. 이 기준을 먼저 정리하면 VAN과 PG를 같은 결제 연동으로 뭉뚱그리지 않게 된다.