pay system 연구 내용

주제 및 소개

 

모바일 기종과 카드 종류에 구애받지 않는, NFC 태깅을 통한 결제의 성공을 목표로 합니다.

 

POS(Point of Sale) 시스템은 매출 관리, 결제 처리, 재고 관리 등의 기능을 포함하는 소프트웨어 시스템입니다.

구현하고자 하는 단계는 '주문 입력' - '주문 처리' - '결제 처리' - '주문 전달' - '매출 및 재고 관리'의 단계 입니다.

 

핵심이라고 할 수 있는 '해당하는 커피 클릭' → '결제' → 'NFC 태그 인식' 과정에서,

이 때, 포스기는 액티브 모드이며 핸드폰은 패시브 모드로 동작하는 방식을 취합니다.

NFC device(여기서는 NFC-capable phones)제조사(Android / IOS)에서 소프트웨어 업데이트를 통해 목적성을 갖는 상호작용 기기들에 대해서만 NFC 태깅이 가능하도록 Client(핸드폰)의 액티브 모드(Write)는 통제하기 때문입니다.

따라서 저희는 Client에서 패시브 모드(Read)를 통해 pay App으로 이동할 수 있게 하고자 하였습니다.

패시브 모드로써 딥 링크(유니버셜 링크)를 부여받고,

사용자의 트리거(링크 클릭 등)를 통해 pay App 내 결제 결정 페이지까지 이동하는 플로우 입니다.

service field 내에서 동작하는 App으로써의 설계

 

목적과 목표

자사 내 service field의 Shell에서 App을 추가하는 형태입니다.

general pay system을 제공하기에 앞서, 프로토타입을 만드는 것을 목표로 하였습니다.

이에 자사 카페 내에서 NFC 태그를 통한 결제 사이클을 경험하는 것이 목표 되었습니다.

기존 자사 카페는 사원증을 통한 NFC 태깅을 통해 결제를 처리하였으며, 이를 모바일로 대체하고자 했습니다.

기기 별 관계도와 동작 순서

 

발생했던 문제들

- POS의 server로써의 동작

demo 개발 과정에서 최초에는 POS가 server로써 동작하게 설계되었는데,

pay app이 더 나아가 general pay가 되고 추후 solution으로써 제공되어 외부 기업에서 동작한다고 할 때,

그 필드에서는 POS가 server로 동작할 수 없을 확률이 높기 때문에 이를 고려하여야 했습니다.

 

- SSE connection

NFC 태깅된 사원의 정보를 총무DB에 반영하기 위해서는 broker 서버와 연결을 유지해야 했습니다.

동작이 단순하고, 단방향 처리해도 문제가 없는(POS는 req없음) SSE connection을 채택하였습니다.

하지만 SSE Connection은 저희가 개발하는 pay 컴포넌트 상위 컴포넌트인 shop에서 이루어져야 했습니다.

Pay Component에서 SSE Connection을 이루어봤자, 각각의 결제 요청마다 연결이 끊어지기 때문입니다.

 

결과와 의의, 그리고 한계점

- 외부적 문제 (계열사 분리) .

데모를 동작시킬 필드(POS의 OS)의 주인이 계열사에서 분리되어버린 것.

 

- 모바일 기기의 태그 과정에서 write모드(후술)가 확률적으로 발생하는 이슈.

 

그 외 연구 내용

결제수단 등록

결제수단 등록의 인증절차가 더 까다로워야 하는 이유

인증서는 공인인증기관에서 발급하는 디지털 인증서로, 사용자의 신원을 확인하고 신뢰할 수 있는 인증서를 발급합니다.

결제 시에는 간단한 인증 수단을 사용하여 신원을 확인하는 수준으로 보안 요구사항을 상대적으로 낮출 수 있습니다.

 

결제 수단 등록은 일반적으로 사용자의 금융 정보와 관련된 중요한 데이터를 처리하는 과정입니다.

사용자의 계좌 정보를 등록하고 저장하는 등 보안에 민감한 작업이 수반될 수 있습니다.

이에 따라 금융 기관이나 결제 서비스 제공업체는 인증서 등록과 같은 보다 높은 수준의 보안 요구사항을 가지고 있습니다.

 

인증서 발급 로직에는 다음 두가지를 일반적으로 사용합니다.

• 1원 송금 예치좌명 인증(Toss 방식, BE와 API통신 기반)
• ARS 인증(Naver 방식, FE 라이브러리 기반)

일반적으로 전자(예치좌명 인증)의 경우가 보안적으로 뛰어납니다.

 

단어 정리

NFC

Near Field Communication.

짧은 거리의 두 장치 사이에서 데이터를 안전하게 교환할 수 있는 무선통신 기술.

RFID_전자태그 기술(주파수를 이용해 ID를 식별하는 기술)이 발전한 형태. 자기장의 원리로 동작한다.

스마트폰 내부에 코일처럼 꼬아진 작은 안테나가 존재.

안테나가 단말기 근처에 있을 시, 자동으로 자기장이 형성되고, 이를 통해 발생한 전류로 데이터의 송/수신이 가능.

해킹이 어렵고, 해킹해도 의미가 없다. (NFC신호를 10m 이내에서 해킹이 가능하긴 하다.)

애플페이, 삼성페이 등의 결제 시스템은 민감한 데이터를 보호하는 토큰을 사용하여 결제를 따로 보호.

 

NFC는 기본적으로 Reader/Writer, Card Emulation, P2P 형태의 3가지 mode가 존재하는데

일반적으로 생각하는 결제상황에서는 Reader/Writer mode를 사용한다. 

NFC 태그는 수동적이므로 다른 NFC 장치와 대화를 시작할 수 없다 .

NFC 태그에는 배터리나 다른 전원이 없으며 NFC 하드웨어에서 전력을 수집한다.

 

마그네틱 방식

마그네틱 방식은 자기장을 이용하여 정보를 전송하는 기술. 주로 신용카드, 체크카드, 자기카드 등에 적용된다.

일반적으로 스마트폰의 NFC와 달리 약간의 거리를 두고 작동.

마그네틱 카드는 액티브 모드로 동작하며, 읽기 또는 쓰기 작업을 수행하기 위해 카드 리더에서 외부 전력을 사용한다.

예를 들어, 신용카드 리더기에 카드를 스왑하면 카드 리더가 자기장을 생성하여 카드의 정보를 읽는다.

마그네틱 카드는 일반적으로 마그네틱 스트라이프로 알려진 특정 영역에 데이터를 저장.

이 영역은 비교적 많은 양의 데이터(일반적으로 수 킬로바이트)를 저장할 수 있다.

 

DeepLink와 Universal Link

Deep link

Deep link는 앱 내의 특정 화면이나 기능으로 바로 이동하는 링크.

앱의 특정 화면을 식별하는 URL 스킴(scheme)을 사용하여 동작.

예를 들어, "myapp://product/details?productId=12345"와 같은 형식.

Deep link는 앱 외부에서 앱을 호출하여 특정 동작을 수행할 수 있도록 한다.

사용자가 웹페이지, 메시지, 이메일 등에서 Deep link를 클릭하면 해당 앱이 열리고 지정된 화면으로 이동.

 

Universal link

Universal link는 Deep link와 유사하지만, 앱과 웹 사이의 통합된 링크 메커니즘.

Universal link는 웹 URL을 사용하며, 해당 URL을 클릭하면 앱을 열 수 있다.

예를 들어, "https://example.com/product/details?productId=12345"와 같은 형식.

Universal link는 앱이 설치되어 있을 경우 앱으로 연결되고, 앱이 설치되어 있지 않은 경우 웹 페이지로 이동할 수 있다.

 

차이점

링크 형식: Deep link는 앱의 URL 스킴을 사용하고, Universal link는 웹 URL을 사용.

플랫폼 지원: Deep link는 iOS와 Android에서 모두 사용할 수 있다.

Universal link는 iOS와 Android에서 모두 지원되지만, iOS에서 더 통합적인 웹과 앱 간의 경험을 제공한다.

설치 여부: Deep link는 항상 앱으로 연결.

Universal link는 앱이 설치되어 있을 경우 앱으로 연결되고, 앱이 없는 경우 웹 페이지로 이동한다.

 

MyData vs. Open Banking API

마이데이터(MyData)

마이데이터는 개인이 자신의 소유권을 가진 금융 데이터를 의미한다.

개인이 금융 기관으로부터 발생하는 자신의 금융 데이터를 직접 소유하고 관리할 수 있는 개념.

이는 개인의 금융 거래, 계좌 정보, 결제 내역, 보험 가입 정보 등 다양한 금융 데이터를 포함한다.

마이데이터의 목적은 개인이 자신의 데이터에 대한 통제권을 가지고,

필요에 따라 다양한 금융 서비스에 접근하거나 개인화된 서비스를 받을 수 있도록 하는 것.

마이데이터 테스트베드 링크

 

오픈뱅킹 API

오픈뱅킹 API는 금융 기관이 제공하는 프로그래밍 인터페이스(API)로,

외부 개발자나 서비스 업체가 해당 금융 기관의 계정 정보, 거래 내역, 결제 기능 등을 활용할 수 있도록 한다.

이 API를 통해 외부 서비스는 사용자의 금융 데이터를 요청하고 처리할 수 있으며, 금융 기관과 연동이 가능해진다.

주요 목적은 금융 데이터의 공유와 개방을 통해 혁신적인 금융 서비스를 제공하고 사용자 경험을 개선하는 것.

금융결제원 오픈뱅킹 테스트베드 링크

 

차이점

마이데이터는 개인의 금융 데이터에 대한 소유권과 통제권을 강조하는 개념이며,

개인의 데이터를 중심으로 한 개인화된 금융 서비스를 위해 활용된다.

오픈뱅킹 API는 금융 기관의 데이터를 외부로 개방하여 다양한 애플리케이션이나 서비스가 이를 활용해

개인화된 금융 서비스를 제공하는 데 사용된다.

마이데이터도 내부적으로는 오픈뱅킹 API를 활용하여 제작되었으며,

현재는 오히려 오픈뱅킹 API가 마이데이터 형식을 역으로 따라가는 구조라고 전해들었다.