본문 바로가기
프로젝트/장애인 PT 플랫폼, PTFD

결제 과정 완료

by 임지혁코딩 2024. 2. 27.

기존, 결제를 원하는 상품을 즉시 구매하는 형태로 구현하려 하였으나,

기술이 아닌 정책상의 문제(개인 사업자 만이 사용 가능, 사용자의 카드정보를 개인이 보유 금지)로. 이를 해결할 방안을 찾게 되었다. 

대략적인 흐름도

 

해당 과정을 진행하며 주의했던 점

1. 결제 검증

결제 자체는 open api호출 만으로 쉽게 진행할 수 있다.( 앞서 상기한 정책상 이유로, test channel만 가능)

하지만 증권사 시스템을 분석하며, 결제 등의 프로세스에서 가장 중요한 것은

검증이라는 생각을 했다.

front단이 전송한 결제 정보가, 사실과 다를 수도 있다는 가정을 하며 검증을 진행하였다.

 

2. front, backend 단의 분리

사용자의 카드 정보를 backend 단에서 보유할 수 없다. 이러한 이유로 front 단에서 어쩔 수 없이 결제를 진행하여야한다.

해당 결제만을 제외하고는, 모든 역할을 backend 단에서 진행하려 노력하였다.

  

해당 과정을 진행하며 어려웠던 점

1. 비동기적

단순한 모놀리식 구조가 아니라, msa 구조로 진행하는 최종 오픈 마켓의 개발이 목표이므로,

전 호출에 webclinet와 mono객체를 사용하였다.

이때의 문제는, 최종 return 직전까진 작업이 종료되었는지 알 수 없기 때문에 계속해서 

대입할 변수를 찾지 못하는 문제가 발생했고, 중간에 한 작업만 block하여 동기적으로 진행할 수 없었다.

이는  flatmap으로 모든 과정을 cahining 해주어 해결하였다.

 

2. 결제 구조의 변경

기본적으로는 앞서 상기한 대로, 금액을 즉시 결제하려 하였으나, 정책상의 문제로 이를 변경하였다.

이때 가장 많이 참고했던 시스템이, p2p 사이트와 본인 블로그의 증궛나 업무 분석이었다.

p2p 사이트는 로그인 -> 포인트 구매 -> 포인트로 상품 구매 의 과정을 따른다.

주식의 매수 매도 또한, 구매 -> 원장확인 -> 원장 변경(개인 계좌 등) -> 외부 통신 (FEP)

해당 프로세스를 FEP->구매->원장->문제시 FEP의 구조로써 적극 활용하였다. 

 

구현

- 물품 구매시, QR코드를 통한 구매 요청

 

-금액 구매 (테스트 채널이기 때문에 , 금액이 무한대로 설정)

-푸시 알람까지 정상적으로 동작

-해당 USER의 , 포인트 증가(포인트를 현금으로 구매하였음)

-결제 내역 . RETURN

 

++ 카카오 로그인 기능이 추가됨에 따라, 카카오 로그인 기능을 활용하여 로그인하고 

포인트를 구매하여 해당 포인트의 반영을 frontend에서 보여주는 형태까지 기능이 추가 되었다.

느낀점

1. 결제 구조의 어려움

결제 구조는 , 결제를 핀테크로 보았을때 역시나 정책이 가장 큰 문제가 되었다.

먼저 생각했던 카드 정보를 받아 결제 후 RETURN은, 정책상 이루어질 수 없었다. 

금융 관련 기술은 정책을 최우선 파악해야 함을 깨달았다. 

 

2. 비동기적 구조가 , 만능은 아니었다.

 

비동기적 구조는 속도면에서도, 리소스면에서도 좋은 답안이 될 수 있다.

특히 수많은 통신을 해야하는 MSA구조에서는 더욱 그렇다.

하지만 코드의 작성이 너무나도 복잡했으며, 한 작업의 명확한 종료가 없다라는 개념은

다음 작업시의 변수 등을 구하기 어렵게 만들었다.

현재 내가 비동기적 구조를 택한 이유는, MSA 구조를 통해 CLOUD 기반의 서비스를 목표로 하기 때문이다.

비동기적 구조를 무작정 선택하는 것이 아닌, 선택하는 명확한 이유를 가지고 개발에 임해야 한다.