구름 개발일기장

추가적인 이슈로 인해 가상계좌 결제방식도 추가하게 되었다. 가상계좌 결제와 카드 결제의 대표적인 차이점은 결제완료시점에 있다. 카드결제의 경우 이용자의 결제 요청 후 과정 완료와 함께 결제도 완료가 된다. 반면 가상계좌의 경우 결제 요청 과정이 완료되어도 이용자가 입금할 때 까지 해당 결제는 완료되지 않는다는 것이다. 따라서 비동기적으로 이뤄지는 결제 절차에 대응하기 위해서 입금 또는 취소되는 결제 상태 변화가 발생 할 때 바로 알 수 있도록 토스페이먼츠에서 등록된 콜백 URL로 알림을 보내준다. 가맹점은 콜백 URL로 입금 완료 알림이 오면 최종적으로 결제 완료를 하게된다. 가상계좌 결제 흐름도 기존의 카드결제와 비교해보면 아래에 가상계좌 입금 -> 입금 완료 통보 -> 결제 결과 안내 로직이 추가된 ..

서버 트래픽 급증으로 인한 DB 커넥션 부족 이슈 OPGG 해커톤 우승 후 기사가 나간날 예상치 못한 서버 트래픽 증가로 인해 DB 커넥션이 부족해지게 되었고, 결과적으로 서버가 느려지는 이슈가 발생했다. 이에 대한 해결법으로 3가지를 적용했는데 이를 정리하고자 한다. 1. EC2, RDS 규모 확장 기존에는 매달 720시간 무료로 사용할 수 있는 t2.micro 크기의 ec2, rds를 사용하고 있었다. 하지만 각 규모마다 가질 수 있는 최대 커넥션 제한이 있었고 이를 파악하지 못해 문제가 발생했다. 따라서, 근본적으로 더 많은 커넥션을 가질 수 있도록 규모를 medium으로 늘려주었다. 2. 커넥션 수립/해제 비용 최적화 스프링부트 2.0 이후 부터는 커넥션 관리를 위해 기본적으로 HikariCP를..

구매자들말고 판매자들이 자신들의 수익금을 정산받기 위한 계좌번호를 등록해야 하는데, 이 계좌번호와 예금주가 동일한지 확인을 해줘야 한다. 실수로 계좌번호를 잘못 입력할 수도 있고, 이름을 잘못 입력할 수도 있으니 수익금이 잘못 입금되거나 거절되면 골치아파지기 때문이다. 그러면 계좌실명조회는 어떻게 할 수 있을까? 이 부분은 토스페이먼츠에서 제공하지 않는다. 금융결제원에서 통합으로 제공하는데 오픈 API를 이용해서 진행할 수 있다. https://developers.kftc.or.kr/dev/doc/open-banking 금융결제원 오픈API 개발자사이트 developers.kftc.or.kr 위 사이트를 들어가서 보면 2.4.1. 계좌실명조회 API 설 명 이용기관이 특정 계좌의 계좌번호와 예금주 실명번..

이제 카드 결제는 완료하였다. 성공한 완료된 카드 결제들에 대해 이제 카드 결제취소를 구현해보자. 결제 취소를 위해서는 결제 승인 시 토스페이먼츠에게서 발급 받은 {paymentKey}와 최소 이유인 {cancelReason}이 필요하다. 이때 paymentKey는 요청 시 pathVariable로 추가하면 되고, cancelReason은 requestParameter로 추가해주면 된다. 물론 이 요청을 보낼 때도 이전에 결제 승인 요청 때 보낸것과 마찬가지로 HTTP 헤더에 시크릿키를 이용한 Basic Authorize를 설정해서 보내야 한다. 결제 취소 구현 Payment Controller @PostMapping("/cancel") @ApiOperation(value = "결제 취소", notes ..

프론트에서 결제 요청 -> 백엔드에서 요청 검증 후 필요한 정보와 함께 반환 -> 프론트에서 토스페이먼츠 호출 -> 토스페이먼츠에서 결제 결과를 성공/실패 콜백 주소로 리다이렉트 하는 과정 중 성공까지 완료하였다. 이제 토스페이먼츠가 실패 시 콜백 주소로 리다이렉트한 요청에 대해 처리를 진행해보자. 실패 시 콜백 응답 처리 Payment Controller @GetMapping("/fail") @ApiOperation(value = "결제 실패 리다이렉트", notes = "결제 실패 시 에러코드 및 에러메시지를 반환합니다.") public SingleResult requestFail( @ApiParam(value = "에러 코드", required = true) @RequestParam(name = "..

저번 포스트를 통해 이제 요청한 값들은 이제 유효함이 검증된 것이고 토스페이먼츠에 전달할 때 필요한 값들도 넣어준 상태이다. 이제 프론트에서 해당 값들을 잘 받았다는 가정하에 이어서 진행해보자. 결제요청 응답 데이터 { "success": true, "code": 1, "message": "성공", "data": { "payType": "카드", "amount": 3000, "orderId": "0023b4e8-2b58-4248-9750-664ce4f7f1db", "orderName": --상품명-- "customerEmail": "test@test.com", "customerName": "김바보", "successUrl": "http://localhost:9090/success", "failUrl": ..

https://www.acmicpc.net/problem/12912 🐢 설명 트리가 있을 때 하나의 간선만을 제거해서 새롭게 연결했을 때 다시 가질 수 있는 최대 지름을 구하면 되는 문제이다. 이때 새로만든 그래프는 트리로서 특성이 유지가 되어야 한다. 그럼 생각해보자. 트리에서 어떤 간선을 제거했다면 어떻게 될까? 바로 트리 두개가 생기게 된다. 그렇다면 문제는 단순해진다. N개의 노드로 이뤄진 트리에서 N-1개의 간선들에 대해서 x간선을 지우고, 트리 두개의 지름을 구한 후, 해당 간선의 길이를 더했을때가 해당 간선을 지웠을 때 최대로 가질 수 있는 지름이 된다. 어짜피 트리 + 트리 이므로 어느 노드에 연결할지는 중요하지 않고 간선을 지웠을 때 각 트리가 가지는 최대 지름만 잘 구해주면 된다. 문제..

https://www.acmicpc.net/problem/4256 🐢 설명 어떤 트리가 존재한다고 하였을 때, pre-order, in-order 순서로 방문한 결과를가지고 post-order 순서로 방문했을 때의 결과를 반환해야 하는 문제이다. 먼저 pre, in 결과를 가지고 트리를 만들고, post 방식으로 방문한 결과를 반환하도록 하면 되겠다. 그럼 pre와 in의 조회 방식 차이를 봐보자. pre-order 현재 방문한 노드의 값을 출력 -> left를 체크, 존재하면 left 방문 -> right를 체크, 존재하면 right 방문 하는 방식으로 이뤄진다. 즉, 처음에 방문하는 노드가 루트임이 보장된다. in-order 현재 방문한 노드 left 체크, 존재하면 방문 -> left 방문 후 현재..

이전 포스트에서 정리했던 내용을 바탕으로 진행해보도록 한다. 필자는 백엔드 파트를 담당하므로 결제 API만 개발하면 되지만 좀더 직관적인 개발 및 테스트를 위해 간단히 화면도 같이 개발하고자 한다. 그럼 소비자들이 결제 시 가장 먼저 만나게 될 결제창을 구현해보겠다. 결제창 연동 이부분은 바로 전 포스트에서 정리한 것과 거의 동일하다. 일반 결제 스크립트 추가 토스페이먼츠에서 결제 시스템을 호출하기 위해 제공하는 라이브러리를 추가한다. // * 테스트용 클라이언트 키로 시작하세요 var clientKey = 'test_ck_클라이언트_키' var tossPayments = TossPayments(clientKey) 테스트를 위해 제공받은 {테스트_클라이언트_키}를 이용해서 TossPayments객체를 생..

https://www.acmicpc.net/problem/12978 🐢 설명 전형적인 트리 DP 문제이다. 먼저 N개의 정점이 있는데 간선이 N-1개라는 말이 있다면 트리를 의미하는건지 의심하면 되는데, 문제에서 보면 N - 1 개의 도로를 이용해 모든 도시들 사이에는 단 한개의 경로만이 존재하도록 이라는말이 있다. N-1개의 간선에 정점 간 단 한개의 경로만이 존재한다 하였으므로 트리구조임을 알 수 있다. 참고로 트리에서 루트 노드를 제외하고는 자신에게 들어오는 간선이 하나이므로 경로도 유일하다. 그러면 이제 트리임을 알았으므로 정점 아무거나 하나골라서 dfs를 통해 경찰서를 설치할지 말지 정해주면 된다. 경우의 수 x정점에 경찰서를 설치할 경우 자식 노드에는 경찰서를 설치해도 된다. 자식 노드에는 경..

https://www.acmicpc.net/problem/1623 🐢 설명 트리DP + 트래킹 문제이다. 문제를 정리해보면 자신의 직속상사가 참가하면 자신은 참가하지 않고, 직속상사가 불참하면 자신은 참가할 수 있으며 && 참가자들의 날나리 정도의 합이 최대가 되도록 하는 멤버 및 그때의 날나리 합을 구하면 된다. 근데 이때 사장이 참여하는 경우 / 참여하지 않는 경우 2가지에 대해 구해야 한다. 먼저, 상사의 참가여부에 부하의 참가여부가 달라지는 경우는 일반적인 트리 DP 문제로 2차원 dp배열을 통해 풀 수 있다. 상사가 참여하는 경우 부하는 참여하지 못함 상사가 참여하지 않는 경우 부하는 참여하거나 부하는 참여하지 않음 이렇게 케이스를 나눠서 dp를 채워주면 된다. 하지만 이 문제에서는 추가적으로 ..

결제 시스템 도입 https://onboarding.tosspayments.com/81403/integration?merchantAccountId=129226 토스페이먼츠 전자결제 onboarding.tosspayments.com 결제가 필요한 앱 서비스를 제작하게 되면서 결제 시스템을 도입해야 했다. KG이니시스, 다날 페이먼트, 토스 페이먼츠 등 다양한 결제 서비스를 제공하는 업체들이 존재한다. 수수료나 가입비들은 다 고만고만하니 더 쉽고 편하게 도입할 수 있는 업체를 고르기로 하였고 이에 토스 페이먼츠로 결정됐다. 홈페이지에 들어가서 전자결제 무료신청을 누르면 위와 같이 결제 서비스 신청하기 창이 뜬다. 그러면 사업자등록번호를 입력하라고 나오는데..! 아직 발급이 되지 않은 관계로 밑에 보이는 개발..