테스트 모드로 결제하기 진행.
일단 결제 시스템이 어떻게 돌아가는 지를 알아보자
PG사
페이먼트 게이트 회사라고 결제를 하기위한 입구라 할 수 있다.
PG가 회사명은 아니고, 여러군데게 존재한다. 이곳을통해 카드사와 연결 될 수 있는데
과정은 아래와 같다.
PG사중 하나와 연락 ==> 계약서 작성 ==> PDF문서 받음 ==> 해당 PG사의 결제연결등의 사용설명서라고 할 수 있는 이 PDF는 엄청 많은양의 페이지가 있음. ===> 해당자료를 보고 공부하며 적용
그런데 이 과정에서 문제가 있다. 보면 알겠지만 자료양이 많아 익혀야할 시간이 많이 필요하며, 만일 PG사를 바꾸려 할 경우 그 사의 파일도 익히면서 현재의 시스템을 뜯어 고쳐야하기때문에 쉽지는 않다.
이러한 이유로 대기업의 경우에는 할인혜택등을 받을 수 있는 PG사를 이용하기도 하지만 스타트업 등 중소기업에서는 PG사 이용보다는 결제 솔루션사 라는것을 이용한다.
결제솔루션사
결제 솔루션 사에는 아임포트, 부트페이 등이있다.우리는 아임포트를 사용했다.
결제 솔루션사를 이용하면 미리 PG사와 연결시켜놓았기에 이용하기 편하다.
미리연결시켜놓고 API를 열어주어 고유비밀키(imp_12343242 이런형태)와 어떤 PG사를 이용하는지, 결제금액을 입력해 보내면 고유 아이디를 주고 어떤 아이디로 결제를 했는지 얼마를 했는지를 브라우저로 주고 브라누저는 데이터를 DB에 저장하기위해 벡엔드로 요청을하고 DB에 저장이된다.
물론 아임포트에서도 결제목록등을 볼 수 있으나 우리가 원하는데로 보기위해서는 벡엔드 저장도 필요한것이다.
결제솔루션사는 솔루션사 계약과 PG사 계약을 같이 진행한다
물론 계약체결 이전에 결제를 위한 페이지는 미리 만들어두어야한다. 즉, 상품목록, 메뉴, DB, 결제하기버튼 등이 다만들어진 상태에서 계약후에 결제버튼을 클릭하면 바로 솔루션사의 결제 화면을 보여주는 식이다.
=> 그렇게 구현한 화면들을 일일이 사진으로 찍어 PPT로 만들어 PG사로 보내면 ==> 솔루션 사에서 카드사에 이 PPT를 뿌린다. ==> 카드사는 이 실제 사이트에 들어가 기능들이 문제가없는지, 결제가 진행이되는지 등을 확인하고==> 승인/거절 을 보내 ==> 거절이라면 재심사가, 승인의 경우에는실제 결제가 적용되는 실 서비스로 사용이 가능하게된다.
그런데, 이 심사과정에는 일단 아임포트(솔루션사)에서 PG사와 계약을 하는데 약 1주일, PG사에서 카드사로계약을 하는게(승인을 받는 과정) 약 3주 정도 걸린다.
물론 결제를 위한 기능구현이 완료된 후에 심사를 거치게되니 그 부분은 빼고 말이다.
거기다가 만약 심사가 거절되게 될경우 재심사의 시간도 있다.
따라서 최소 1~2달은 잡아야한다고 하셨다
심사 거절의 사유
내부에서 경매를 진행중인경우, 도박사이트, 결제 금액을 직접 입력해야하는 방식의 경우
기획이 좋아도 결제에서 심사가 거절 될 수 있기에 잘 알아둬야한다.
이런문제들때문에 개발자들은 일정관리가 중요하다
일정관리하기
- 가능하면 쪼개서 대화하자.
비개발자와 개발자의 소통문제에 있어 갈등이 발생한다.
만약 비개발자쪽에서 게시판을 만들어 달라고 요청했다고하고 얼마나걸려요? 라고 묻는다.
그럼 개발자는 등록하기 부분만 말하는것인지, 상세보기까지인지, 검색하기 기능까지인지, 목록조회인지... 이렇게 상세하게 질문하고 답변해야 최대한 트러블을 줄일 수 있다.
2.일정 관련 예측치는 항상 따로 기록해두자
각 기능이 얼마나 걸릴지 예측해보아야한다.
사람마다 편차가 있기에 많이 해보는 것이 중요하다. 그리고 각 기능이 얼마나 걸리는지 기록해두자.
적어도 시간이 너무 늘어나는것은 막을 수 있다.
3.조율된 일정에 대해서는 반드시 지키자.
개발자 일정이 중요한 이유는 그에따른 마케팅 , 광고 등이 밀릴 수 있기때문이다. 그외에도 여러가지가 개발에따라붙기에 일정관리를 잘 해야한다.
아임포트
IamPort사용하기
회원가입이 필요하다. 회원가입을 진행후 시작하기를 누르면 화면이 바뀐다. 결제내역등을 확인할 수 있는 페이지이다.
멘토님의 화면을 보니 결제 내역부분에 nobody라고 작게 쓰여있는 곳이 있었다. imp_.. 이부분 아래에 있었는데 상품 번호 부분이다. 원한다면 바꿀 수 있으나 중복되면 결제가 진행되지 않으니 주의할것.
결제에도 일반결제, 정기결제 가 있다. 정기결제는 일정기간마다 결제 하는것을 의미한다. subscribe 이라고 한다.
vbanks라는 부분이 있는것을 발견했다. 이부분은 가상계좌를 의미한다.
결제하기 -->결제창에 금액이 나오고 무통장 입금클릭 --> 가상계좌 발급됨 --> 여기에 입금
이 가상계좌 사용시 웹훅 이라는것이 필요하나고 한다.
원래는 결제를 하면 아임포트 키를 받아와 벡엔드로 요청되어 DB에 저장된다.
그런데 가상계좌를 발급받을경우에는 결제가 바로 진행되지 않아 아임포트키를 받아오지 못한다. 따라서 이때 웹훅이 필요하게된다.
벡엔드에 아임포트키 전용 API를 만들고 이 주소를 아임포트 웹훅에 기록한다. 그럼 입금완료시 아임포트에서 저장된 주소로 바로 아임포트 키와 금액이 저장된다
구관리자콘솔(기존관리자콘솔)바로가기 => 사용자 메뉴얼 => 일반결제 연동하기.
우리는 1단계부터 3단계 까지 진행했다.
먼저 1단계를 보니 제이쿼리를 이용하는 부분이 있는것이 보인다. 그냥 그렇구나~ 하며 코드를 복사해준다.
그런데 스크립트태그이니 next에서 Head태그를 import 해 만들어준다음 그 안에 붙여넣기해주자
<Head> {/* <!-- jQuery --> */} <script type="text/javascript" src="https://code.jquery.com/jquery-1.12.4.min.js"></script> {/* <!-- iamport.payment.js --> */} <script type="text/javascript" src="https://cdn.iamport.kr/js/iamport.payment-1.2.0.js"></script> </Head>
이렇게 적어주면되는데 원래 payment.js 부분은
<script type="text/javascript" src="https://cdn.iamport.kr/js/iamport.payment-{SDK-최신버전}.js"></script>이렇게 나와있었다. .js앞에 SDK최신버전이라고 되어있다.
SDK란?
소프트웨어 디벨리먼트 키트. 즉 라이브러리를 의미한다.
따라서 SDK버전은 라이브러리 버전을 의미한다. 그부분의 최신버전을 넣으라는 의미로 아임포트의 최신버전을 확인해 넣어준다.
현재 최신버전은 1.2.0 이었다.
{SDK-최신버전}.js 해당부분을
==>1.2.0.js 이렇게 바꿔준다
2단계 적용
결제준비하기.
결제는 버튼이 클릭되었을때 실행되기에 버튼 클릭함수안에 적어준다.
자바스크립트 ES Next 부분을 사용해 적용(자바스크립트 최신버전임)한다.
const IMP = window.IMP; // 생략 가능
IMP.init("{Merchant ID}"); // Example: imp00000000
{Merchant ID} 부분은 결제연동 부분에서 결제 대행사설정밑 추가부분에서 테스트 결제용 체크하고 PG사를 선택하고결제 모듈은 API가 아닌것을 선택한다. 그렇게해서 입력사항 입력후 저장을 누르면 테스트용 결제연동.. 뭐가 생성된다.
다 생성 후에 위쪽에 내 식별코드를 클릭해보면 가맹점 식별코드가 나온다.
그부분을 적용하면 된다.
대괄호까지 지우고 그안에 작성해주면된다.
3단계
그다음 결제를 요청하는 부분.
리엑트부분의 코드를 함수 안의 로직만else까지 뽑아와 클릭시에 실행될 함수니 마찬가지로 클릭함수안에 넣어준다.
if (rsp.success )부분에 결제 성공시의 로직이 들어온다. 이때 mutation도 요청하면 된다.
그런데 IMP 부분에 빨간줄이 그어졌다 윈도우 기능인데 프리랜더링 문제가 있는것같다. 이전에 카카오맵할때 처럼 맨위에 declare로 윈도우 는 타입이 글로벌 this인데 거기에 IMP도 any의 타입으로 있다고 선언해준다.
declare const window: typeof globalThis & { IMP: any; };
우리는 포인트를 결제하는 방식으로 실습했다.
pg: "html5_inicis",
pay_method: "card",
merchant_uid: "ORD20180131-0000011",
name: "노르웨이 회전 의자",
amount: 64900,
buyer_email: "gildong@gmail.com",
buyer_name: "홍길동",
buyer_tel: "010-4242-4242",
buyer_addr: "서울특별시 강남구 신사동",
buyer_postcode: "01181"
pg 부분에는 우리가 처음 선택한 PG 사를 말하는데 3단계의 IMP.request pay부분을 클릭하면 Docs가 나온다. 그부분의 PG사 코드를 찾아 적어 넣어주면 된다.
상세보기에서 nobody로 적혀있던 부분이 merchant_uid 부분이다. 이부분을 직접 수정해 넣어줄 수는 있으나 주석처리하면 nobody로 뜨게된다. 어차피 겹치지 않아야하기에 주석하여 아임포트에서 아무아이디나 랜덤생성되도록 만들어 놓는다.
그런데 여기서, 웹결제와 모바일 결제는 다르다는것을 짚고 넘어가자.
웹결제의 경우에는 결제후에 imp_uid를 받을 수 있다. 그래서 따로 문제될 것은 없는데 모바일에서는 결제하기를 누르면 결재 사이트로 들어간다. 따라서 결제후에 돌아갈곳(redirect)을 찾지 못한다. 직접 입력해주어야한다.
m_redirect_url: 이부분을 추가해주어 문자열로 결제후 돌아갈페이지 주소를 적어준다.
=>pg: "html5_inicis",
pay_method: "card",
merchant_uid: "ORD20180131-0000011",
name: "노르웨이 회전 의자",
amount: 64900,
buyer_email: "gildong@gmail.com",
buyer_name: "홍길동",
buyer_tel: "010-4242-4242",
buyer_addr: "서울특별시 강남구 신사동",
buyer_postcode: "01181",
m_redirect_url:"모바일에서 결제후 돌아갈페이지(이동할 페이지)"
Iamport 로 결제부분을 실습해보았다.
실제 결제가 진행되긴 하지만 테스트 모드로 진행하니 상세내역에서 테스트결제 모드를 체크하면 테스트로 결제한 내역을 볼 수 있고 거기서 취소를 누르거나, 아니면 그냥 두어도 오늘이 지나기전에 환불이 된다. 11 시 이전에 된다고 하셨는데 취소하자마자 바로 환불이 되었다.
이벤트 루프 쓰레드
콜스텍(마지막에 들어간게 먼저 나옴)에 실행시킨 함수가 하나씩 쌓이고 그중 시간이 걸리는 작업 setTimeout, setInterval , axios 등 외부 API등 보내는 작업 은 콜스택에 쌓이면 그 다음 작업이 시작되지못하기에 외부로 따로 빼서 사용하게된다. 이 외부를 백그라운드나 웹API 등으로 부른다. 이 외부에 두었던 시간이 걸리는 작업은 정해준 시간이 지나면 큐에 들어가 대기상태가된다(먼저들어간게 먼저 나오는 구조)
기다리는 동안 콜스텍에서 일단 그 다음것을 진행하고 콜스텍이 다 끝나고서야 즉, 콜스텍이 다 비워지고 나서야 돌다가 큐를 확인하게되고 따라서 큐부분에 들어가게되는 시간이 걸리는 함수나 요청등은 가장 마지막에 실행된다!
이렇게 계속 도는 과정을 이벤트 루프라고한다. 그리고 이것을 해주는 일꾼을 이벤트 루프 쓰레드 라고 한다.
자바스프레드에서는 이 이벤트 루프 쓰레드가 하나라
싱글 이벤트 루프 쓰레드 라고한다.
물론 이 쓰레드안에 메인과 서브로 나눠 쓰래드가 많이 있으나 핵심이 하나이기에 그렇게 부른다
즉, 콜스텍에서 일하는 애를
싱글 이벤트 루프 쓰레드 라고 하는것.
물론 자바스크립트에서도 쓰레드를 추가적으로 생성가능하나 일단 default 값이 이벤트루프쓰레드라는것
다른언어는 싱글이 아니라 멀티로 되어있는데 실제 일하는 CPU에따라 동시에 일하거나 동시에 일하는것처럼 보이게 양쪽을 왔다갔다하면서 실행하는 컨텍스트 스위칭이 일어난다.
따라서 어떤일을 하기위해 그 일이끝날때까지 기다려야한다.
CPU가 많거나 같을때는 멀티가 더 성능이 좋으나 그렇지 않는경우 컨텍스트 스위칭 이 일어나지 않는 싱글이 더 성능이 빠르다. 상황에따라 사용하도록하자.
