TIL

개발 목표 중 하나인 결제 기능을 구현해보았다.

KANG_G1 2024. 8. 8. 16:13

외주 프로젝트에서 결제 기능을 구현하며 값진 경험을 했습니다.

개발자라는 길을 선택하며 꼭 직접 구현해보고 싶었던 기능이었는데

외주로 목표를 이뤄 조금 아쉽지만.. 그래도 좋네요!

 

더 베스트페이라는 PG사에서 제공하는 결제 모듈을 사용해 개발을 진행했고,

이번 포스팅에서는 결제를 위한 세팅 과정과

결제 기능을 쉽게 구현하던 때는 몰랐던 부분들에 대해

배운 점을 작성해보고자 합니다.


불친절했던 PG사의 정보를 최대한 활용하자

PG사와 결제는 어떻게 이루어지는지, 문서화된 자료는 어떤 것이 있는지 등의

논의를 40분 정도 진행한 후 자료를 받아봤는데요,

함수명만 명시된 js 파일 하나(= 로직 X), 카드 정보 요청과 결제 단말기 시작과 관련된

restAPI 응답.txt가 끝이었습니다.

 

처음엔 잘못 받은 건가 싶어 PG사에 문의해 보니

"보유하고 있는 문서는 그게 전부다"라는 답변이 돌아왔습니다.

 

임시 단말기, js파일 하나, txt파일 하나.

최소한의 자료로 결제를 구현해야 했습니다.


결제는 하나의 단계가 아니었다

완성된 결제 기능을 사용할 땐 버튼 클릭 한두 번만으로 결제가 이뤄져

결제 API를 통해 한 번만 통신하면 결제가 완료되겠구나 싶었지만 그게 아녔습니다.

 

이번에 개발하게 된 키오스크를 기준으로 말씀드리면

 

키오스크 결제 단말기 시작 API 통신 -> 카드 정보 API 통신 -> 카드를 단말기에 삽입

-> 카드 정보 API 통신 응답 -> 카드정보 응답값을 기반으로 결제 승인 API 통신

-> 카드 결제 처리 후 응답 -> 키오스크 결제 단말기 종료 API 통신

순으로 이뤄졌습니다.

 

척 봐도 버튼 하나의 이벤트 핸들러로 처리하기 힘든 프로세스입니다.

위의 결제 과정 이외에도 추가적인 과정이 더 존재하지만,

결제만을 위한 과정을 설명드렸는데요.

 

결제 프로세스를 확립했다면, 다음으로 결제 기능 개발을 진행해야죠.


첫 결제 프로세스

처음엔 모두 프론트에서 처리되는 프로세스로 진행해 봤습니다.

결제 프로세스를 파악 후 코드를 작성하는 건 어렵지 않았지만

이후 걷잡을 수 없이 문제가 발생했는데요.

 

조금 더 생각해 보니 결제 정보와 같은 개인 데이터를

클라이언트 측에서 관리하는 것은 보안상 말이 안 되고

state를 사용해 관리한다고 해도, 상태 변경 시 관련 컴포넌트가

다시 렌더링되기 때문에 렌더링을 발생시키는 요소의 범위가 늘어나 골치가 아팠습니다.

 

결제 순간에만 사용할 데이터를 클라이언트 전역 상태로

관리하는 것도 비효율적이었고요.

 

이러한 이유로 프론트에서만 결제를 구현하는 것은 어렵다는 판단이 들어

백엔드에게 프로세스를 설명 후, 협업해 진행하기로 결정했습니다.


두 번째 결제 프로세스

결제 단말기 시작 API 통신, 카드정보 API 통신만 프론트에서 처리하고

결제 승인 API, 결제 단말기 종료 통신는 백엔드에서 처리하는 방식입니다.

 

개발을 진행하며 웹 브라우저의 기본 동작을 막고, 전체 화면으로 처리했지만

여전히 카드 정보 API에 대한 데이터가 클라이언트 측에서 처리되며

정보가 빠져나갈 가능성이 존재했습니다.

 


세 번째, 마침내 완전해진 결제 프로세스

모두 서버에서 처리하는 프로세스로 진행하기로 재설계했습니다.

 

클라이언트는 결제 요청 API만 호출하고

서버에서는 결제 단말기 시작 -> 결제 요청 ->

결제 승인 -> 결제 단말기 비활성화까지 처리하는 거죠.

 

클라이언트에서는 결제 요청 API와 결제 요청 API에 들어갈

가격 value만 관리하면 되어서 소스 코드 관리가 간편해짐과 동시에

코드의 보안도 챙길 수 있게 되었습니다!


보면서 이해하는 결제 프로세스

1. 카드를 클릭 시, 가격 데이터를 실은 결제 요청 API 통신이 이뤄집니다.

카드를 클릭하면 결제 요청 API 통신이 이뤄집니다.

 

결제 요청에 따라 카드 정보 API가 호출되고,

단말기에 카드를 삽입해 response를 전달받습니다.

카드 삽입을 하면 카드정보 API 통신의 response가 거래 승인 API 통신에 실려 전달됩니다.

 

결제 정보가 승인되면 클라이언트에서는 특정 페이지로
라우팅 처리를 합니다.

거래 승인 API 통신에 대한 response가 전달되면 서버는 결제 요청에 대한 response를 클라이언트에 전달해주고, 클라이언트에서는 페이지를 이동시킵니다.

 

 

GIF로 보면 참 짧은 과정인데, 우여곡절이 많았네요😎


고찰

 

돈의 세상에서, 결제만큼 중요한 것이 없지만 결제만큼 외면당하는 것도 없다

 

"결제는 어떻게 세상을 바꾸는가"라는 책의 소개 중 일부를 발췌한 내용입니다.

 

결제가 하나의 단계로 쉽게 이뤄지는 것처럼 보였지만

내부를 들여다보면 여러 단계들로 구성되어 있다는 것을 알게 되었는데요.

 

실제로 개발 단계에서 결제를 마주하니 예상치 못한 문제와

프로세스가 많았고, 결제 기능의 단순화를 위해

얼마나 많은 사람들의 노력이 들어갔을까 생각이 들었습니다.

 

대부분의 사람들은 결제에 대해 당연하게 생각하며

결제라는 이름 뒤에서 이뤄지는 일련의 프로세스에 대해서는

생각하지 않습니다. 저 또한 마찬가지였고요.

 

그러나 개발을 통해 결제 시스템과 복잡성을 직접 경험하게 되며

결제에 대한 관심이 생기기 시작했습니다.

 

추가로, 결제 이면에 숨겨진 기술적 발전과 혁신의 중요성을 느끼게 되었습니다.

특히, 토스와 같은 메이저 PG사들은 결제 시스템에 대한 지속적인 고도화를 통해

UX, DX를 향상시키는데요.

 

단순히 결제의 속도와 편리함을 높이는 데 그치지 않고 사용자 데이터를 분석해

맞춤형 서비스로 나아가는 모습을 보며 언젠가 저도 핀테크 분야에서

일해보고 싶다는 욕심이 생겼습니다.