모든 카드사 등의 결제 방법을 하나하나 코딩할 수는 없으니 PG(Payment Gateway)사에서 만든 API를 사용한다
그러나 PG사 또한 서로의 API가 다르기 때문에 이용하는 PG를 옮기려면 다시 코드를 짜고 적용시켜야 하는 문제가 발생했기 때문에 나온게 결제 솔루션이다.
(프로그래밍에서 ‘솔루션’이라함은 보통 프로그램을 말함)
결제 솔루션 업체로 대표적인건 아임포트, 부트페이 등이 있고 이 업체들은 각 PG사의 API를 통합하고 rest-API로 다시 만들어서 exios 요청만 하면 PG사 별로 다른 코드를 작성할 필요 없이 결제가 진행된다.
결제가 완료되면 솔루션에서 결제에 대한 key값(imp_uid)을 Br로 리턴한다
리턴받은 키값을 다시 DB에 저장(Mutation)을 해줘야 한다. 중복 처리 방지를 위해 키 값으로 받은 uid를 키로 설정해 겹치지않게 설정해주고 결제한 금액을 같이 전달한다.
리턴값을 BE로 전달할 때는 가격이 아닌 imp_uid만 전달하는데 악의적인 코드에 의해 금액이 변동될 위험을 제거하기 위함이며 imp_uid로는 결제완료여부 체크, 결제 금액 조회를 할 수가 있으므로 리턴으로 넘어오는 결제 금액은 BE로 전달하지 않아도 Mutation이 가능하다.
그렇다면 핸드폰에서는 ?
모바일 웹에서 결제할경우 PC와 다르게 디바이스의 화면 크기에 따라 표시되는 창이 다르기 때문에 결제가 완료된 후 돌아갈 페이지를 지정해 줘야하며 그 주소는
m_redirect_url < 라는 옵션에 설정해야한다.
물론 리다이렉트를 통해 페이지가 이동될 경우 옵션 밑의 함수부분은 실행되지 않기 떄문에 이때도 웹 훅 노티피케이션을 사용해서 리턴 값을 BE에 직접 전달해야한다.
내장 함수 new Date() 로 만드는 시간은 FE에서는 웬만하면 하지않는게 좋다. PC마다 시간이 조금씩 다를 수 있기 때문인데, new Date는 PC의 시간을 따라가기 때문에 개발자마다 시간이 달라질 수 있다.
(현재 시각을 생성하는 건 FE에서 생성할 경우 신뢰할 만한 데이터가 아니지만 이미 있는 시간 즉, BE에서 받아오거나 하는 등의 데이터를 화면에 출력하는 정도는 괜찮다.)
이런 시간을 결제시간으로 만들어버리면 DB에 저장되는 결제시간이 어지러워질 수 있기에 보통 시간 관련된 내용은 FE가 아닌 BE에서 담당한다.
물론 실제 사용자가 있는 지역에 따라 시차가 발생할 수 있기 때문에 BE 에서도 UTC( 세계표준시)를 사용해 DB에 저장한다.
즉 동작은
FE -결제(UTC)->BE->DB
DB->BE- 결제완료(UTC)->FE
이런 식으로 UTC를 주고받으며 사용자가 있는 지역의 시간으로 바꾸는건 FE에서 발생하고 이는 라이브러리를 통해 쉽게 처리가 가능하다.
moment.js
이 중 2번의 방법을 크론탭(Crontab)이라고 한다.
프로세스 : 스레드
scv
싱글 스레드: 10초의 시간이 필요한 API에 요청하고 10초를 기다린 후 응답을 받음, 기다리는 10초동안은 다른 작업을 진행할 수 없음 그래도 오래 걸리는 일은 스택에서 태스크 큐로 빼서 처리하기 때문에 오래걸리는 작업도 처리가 가능
non-blocking방식을 사용한다.
(JS의 특징인데, 싱글 루프 스레드와 논 블락킹 방식을 사용한다0
멀티 스레드: 사실 싱글 스레드보다 빠르지는 않다. 한가지의 일을 스레드의 개수만큼 분할해 작업하는 식으로 동작하기 때문에(컨텍스트 스위칭) 실제로 여러 동작을 한번에 처리하는 건 아니고 그렇게 보이게끔 동작한다.
멀티 스레드는 blocking방식으로 동작하는데 이는 하나의 스레드가 하나의 긴 작업을 끝낼 때 까지 다른 작업을 하지 못하는 것을 말한다