단말기에서 다중 사업자 지원하기

자리 두 개에 POS가 있고, 각 자리마다 카드 단말기가 하나씩 붙어 있다고 하자. 여기에 사업자 A와 사업자 B를 둘 다 받을 수 있게 만들면 결제 버튼 하나가 생각보다 많은 것을 결정한다. 주문은 A 사업자로 잡혔는데 실제 카드 승인이 B 사업자 문맥으로 나가면 전표, 취소, 정산 대사가 한 번에 어긋난다.

사업자만으로는 부족하다

처음에는 화면에서 A 사업자 주문인지 B 사업자 주문인지 잘 고르면 된다고 생각하기 쉽다. 하지만 단말기 연동에서는 한 단계가 더 있다. 그 사업자가 어느 자리의 어느 단말기에서 승인될 것인지까지 정해야 한다.

사업자 A와 단말기 1대만 있으면 A의 단말 식별자 하나를 저장하면 끝난다. 하지만 자리 2개에 단말기 2대가 있고, 각 자리에서 A와 B 사업자를 모두 받을 수 있으면 조합이 생긴다.

이때 저장 단위는 사업자도 아니고 단말기도 아니다. 사업자 x 단말기 매핑이다.

자리1 단말기 + 사업자A -> NICE CAT_ID_A1 또는 KICC vanTid_A1
자리1 단말기 + 사업자B -> NICE CAT_ID_B1 또는 KICC vanTid_B1
자리2 단말기 + 사업자A -> NICE CAT_ID_A2 또는 KICC vanTid_A2
자리2 단말기 + 사업자B -> NICE CAT_ID_B2 또는 KICC vanTid_B2

이 매핑을 생략하면 승인 요청 시점에 "A 사업자"라는 사실만 남고, 실제 어떤 외부 단말 식별자로 보내야 하는지 결정할 근거가 부족해진다. 더 위험한 경우는 사람에게 단말기 화면에서 사업자를 고르게 두는 방식이다. POS 매출은 A로 잡혔는데 카드 승인은 B 문맥으로 나가면 정산, 취소, 전표가 한 번에 어긋난다.

회사별 이름을 먼저 확인하기

여기서 헷갈리는 지점이 이름이다. 카드 단말 연동에서는 TID, CAT_ID, TerminalID 같은 이름이 같이 나온다. 내가 다룬 KICC 한국정보통신 쪽 문서에서는 vanTid라는 필드명으로 VAN 터미널 ID를 받는다. 반면 NICE정보통신 개발자센터 용어사전은 CATID(TID, TerminalID)처럼 같은 층위의 용어를 묶어 표기한다.

그래서 TID와 CAT_ID를 전혀 다른 개념으로 나누기보다, VAN사가 발급한 단말/거래 식별자를 회사별로 다르게 부른다고 보는 쪽이 실무에 가깝다. 다만 코드에서는 이 차이를 지워버리면 안 된다. KICC에서 받은 값은 KICC의 vanTid로, NICE에서 받은 값은 NICE의 CAT_ID로 원문 그대로 저장하고 전송해야 한다.

suffix도 단말기 기준으로 나누기

NICE에서 가맹점별 7자리 CAT_ID를 받고 뒤 3자리 suffix를 붙여 10자리 단말 식별자로 쓰는 구조라면 기준은 같다. 같은 7자리 base 아래에 물리 단말기 두 대가 있다면 둘 다 001로 두면 최종 CAT_ID가 충돌한다. 한 대는 001, 다른 한 대는 002처럼 나눠야 어떤 단말에서 발생한 거래인지 추적할 수 있다. 다른 사업자라면 base가 다르기 때문에 둘 다 001을 쓸 수 있지만, 같은 base 안에서는 중복을 피해야 한다.

이 규칙은 코드보다 먼저 운영 정책으로 고정해둔다. 나중에 단말기를 교체하거나 자리를 늘릴 때도 같은 기준으로 새 suffix를 부여할 수 있어야 한다.

로그에 남길 값

결제 로그에는 요청에 사용한 외부 단말 식별자와 응답으로 받은 식별자를 같이 남긴다. 여기에 주문 ID, 내부 사업자 ID, 단말기 ID, VAN사, 승인번호, 원거래 참조값을 같이 저장하면 취소와 장애 대응이 쉬워진다. 나중에 VAN 관리자에서 CAT_ID나 TID 기준으로 거래를 조회할 때도 내부 주문과 외부 승인 건을 다시 맞출 수 있다.

정리

결국 다중 사업자 POS의 핵심은 화면에서 A/B를 고르는 UI가 아니다. 주문의 사업자, 자리의 단말기, VAN사가 발급한 외부 단말 식별자를 하나의 매핑으로 관리하는 것이다. NICE에서는 그것이 CAT_ID로 보이고, KICC에서는 vanTid 또는 VAN TID로 보일 수 있다. 이 매핑이 명확해야 승인, 취소, 정산 대사가 같은 거래를 바라본다.