13. 결제 서비스 구현하기 (feat. iamport)
모든 인터넷 쇼핑몰, 꼭 쇼핑몰 뿐만아니라 결제가 필요한 그 어느 사이트에서든 우리는 결제를 도와주는 창을 본적이 있을것이다. 어느 사이트에서 결제하던 결제 창은 대부분 비슷한 창이 뜨게 되는데 어렴풋이 음 어딘가 결제 창을 띄워주는 라이브러리를 쓰고있구나 하고 생각만 했는데 이번에 내 프로젝트에 실습해보면서 더 자세히 공부해 보았다. 아직 훨씬 더 많이 배우고 적용해야겠지만 일단 배운내용까지만 정리해봐야지
PaymentGateway
Br -> PG사 (payment Gateway) -> 해당 카드사에 실제 결제를 요청, 우리가 해야할것은 이 PG사와 결제를 하기 위한 계약을 해야한다. 하지만 소규모 결제가 이루어지는 곳은 조금 다르다. PG사에서 제공해주는 코드를 가지고 자사 서비스에 적합하게 구현하기에는 시간이 오래걸린다. 여차저차해서 PG사의 pdf를 보고 열심히 만들어도 다른 PG사로 옮기려 할때 또 그 고생을 해야하는 문제점이 있다. 그러다보니 큰 회사에서는 가능하지만 스타트업에서는 현실적으로 어려움이 있다. 이 사이의 간극을 매꿔주기 위해 결제 솔루션 회사가 등장했다. 즉, 이 결제 솔루션 회사에서 각각의 PG사별로 결제관련 API들을 만들어주기 시작했다. 역시 사업하는 분들은 대단하다. 따라서 결제를 원하는 회사에서 이 결제솔루션 회사로 결제할 금액과 어떤 PG사를 이용하는지에 대한 key값만 넘겨주면 실제 결제는 이 값을 넘겨받은 결제 솔루션회사 내에서 이루어진다. 이 결제 솔루션 회사의 대표적인 예시로는 아임포트, 부트페이 등등이 있다. 일반적으로는 대부분 아임포트를 쓴다고 보면 된다. 물론 이는 스타트업같은 개발인력이 적은 소규모 회사에서 해당하는 말이고 사실 돈많고 사람많은 큰 기업에서는 자기들이 직접 결제API만들어서 쓰면 그만이다. 나중에 CTO가 되기 위해서는 물론 직접 결제 API를 하나하나 만들줄 알아야 하겠지만 아직 내 수준에서는 아임포트를 잘 이용해보는것으로 대체해서 활용해볼 예정이다. 나중엔 꼭 배워보고 싶다.
아임포트를 이용한 결제 과정
사용자가 상품을 구매하기 위해 로그인을 한다면 access 토큰을 발급해주고 이 토큰을 지닌 사용자가 실제 상품을 구매하게 되면 아임포트id값이 주어지게 된다. 이 아임포트 id값을 통해 아임포트에서 필요한 결제관련 API를 실행시켜서 그 결과값을 보내준다. 말로는 간단해보이는데 실제 코드에서도 그럴까? 실제 아임포트 홈페이지에 접속해서 가입하고 아임포트에서 제공하는 결제대행 서비스에 대해서 좀 더 자세히 알아보자! 아임포트에서 회원가입 후에 로그인 하면 관리자 페이지를 통해서 제공되고 있는 REST API 목록을 확인할 수가 있다.
이제 아임포트에서 제공받은 결제 화면을 import하면 우리가 자주 보았던 결제창 모듈이 우리의 서비스에서 뜨는 신기한 경험을 할 수 있다. UI를 만들필요도 없다. 결제를 테스트해보기 위해선 아임포트docs에 있는 예제를 활용해 볼 수 있다. 모든건 docs에..
https://docs.iamport.kr/implementation/payment
[결제연동] 일반결제
일반결제 연동하기 이 문서는 일반 결제 기능을 구현하는 방법을 설명합니다. STEP1아임포트 라이브러리 추가하기 client-side 주문 페이지에 아임포트 라이브러리를 추가합니다.최신 라이브러리
docs.iamport.kr
docs에 있는 예제 코드를 활용해서 실제로 아임포트 결제모듈창을 띄워보면 아래와 같은 창을 볼 수 있다.
이렇게 결제한 결제 내역들을 확인하기 위해서 결제 내역을 DB에 저장하는 API를 따로 만들어주었다. 이 때 주의할 점은 거래내역은 업데이트해서 지난 거래 내역을 새로운 거래 내역으로 덮어씌우지 않고 추가로 저장만 가능하도록 하기 위해서 UpdateDateColumn은 사용하지 않고 insert only 테이블로 entity를 구성하였다. 추가적으로 결제의 상태를 입력해 줄때 선택된 값만 지정해주도록 status는 enum 타입으로 지정해주었다. 그리고 이 enum type을 GraphQL에서 활용하기 위해서 registerEnumType을 추가해주었다.
Webhook & Webhook notification
아임포트에서 제공하는 REST API중 가상계좌 관련한 API가 있다. 이 가상 계좌 API 를 통해 결제가 이루어질때는 우리의 DB에 결제정보를 저장할 수 없게 될 수 있다. 이럴 때 아임포트로부터 결제 알림을 받을 API주소를 만들어서 실제 아임포트에서 결제가 이뤄졌을 때 우리의 백엔드 노트북이 꺼져있더라도 알림을 받을 수 있어야 한다. 그 알림받을 API를 webhook이라고 부르며 이 곳으로 알림을 전달하는 프로세스를 webhook notification이라고 한다. 이로써 우리의 백엔드 노트북이 꺼져있더라도 DB에 결제 정보를 저장할 수 있게 된다.
결제 기획 시 주의사항
경매, 도박 등과 같은 곳에 사용되는 결제를 하는 경우에는 아임포트에서 계약 승인이 안될 수 있다. 이때 약 PPT5장에 해당하는 본인서비스 결제 동작과정과 사이트 동작 시연영상을 보내주어야 하는데 이를 토대로 솔루션 회사에서 각각의 카드사에 승인여부를 묻게 되고 만약 여기서 승인이 떨어지지 않는다면 결제시스템을 구축하지 못하게 될 수 도 있다. 또한 상품 금액을 소비자가 직접입력하도록 해서도 안된다. 따라서 기획단계에서 부터 결제 승인이 될지에 대한 주의사항을 염두에 두고 설계해야한다.
아임포트와 PG사와 계약이 체결되는데 까지 약 1주일 걸리고 카드사에서 카드심사 통과받는 것이 약 2주정도 소요된다. (이 과정은 PPT 5장이 만들어진 이후여야할테니 배포까지 완료되어야 하는것) 따라서 기능만들고 나서 3주의 물리적인 시간이 필요하다. 심지어 한번에 통과되면 운좋은거지만 그렇지 못한경우가 더 많기 때문에 사실상 한달정도 걸린다고 봐야한다. 너무 오래걸리는것 아닌가 싶지만 실제로 결제 시스템 구축을 직접 하게 되면 3달에서 길게는 6개월까지도 걸린다고 하니 그냥 잠자코 기다리자.. 이 물리적인 기다림을 서비스 기획, 개발단계중에 고려하지 않은채로 최종 결제시스템까지 포함한 서비스 개발 완료 예상시점을 잡게 되면 그 일정에 맞추어 잡아놓은 마케팅, 광고 등등의 일정취소에 따른 어마무시한 금전적 손실을 감수하게 될 수 있으니 꼭 명심하고 기억하자! (일정 하나 잘못 짯다가는 회사가 많이 아파질 수 있다 ..)
이는 결제 뿐 아니라 모든 API에서 적용되는 말이다. 따라서 모든 API를 만들때 항상 언제까지 완료될것 같은지에 대해서 명확하게 말을 해주어야 다른 분들과의 협업에 있어서도 혼동이 없고 실제 서비스의 완성도에 큰 영향을 미치게 될 수 있으니 개발자의 마인드를 가지고 일을 해야한다.