마무리 이렇게 나의 서비스에 속한 판매자들이 자신의 상점을 등록하기 위한 서브몰 등록/수정/삭제/조회 API 개발을 모두 완료하였다. 중간에 공식문서의 문제로 인한 우여곡절도 있었지만 최종적으로 필요한 API는 모두 개발을 완료하였다. 물론 추후 정산 관련 API도 개발해야 되지만 이 부분은 차후 MVP모델에서 실제 비지니스 모델로 발전시킬 때 필요한 부분이라 나중에 개발할 예정이다. 결제 시스템을 개발하기 위해 외부 PG 업체의 API를 뜯어보면서 나의 서비스와 연결하는 과정이 순탄치는 않았지만 에러 처리나 안정적인 요청을 위한 로직 설계등을 하면서 많은 부분들을 배울 수 있어서 좋았다. 토스페이먼츠에 최종적으로 서비스 계약을 위해 신청까지 넣었는데 카드사 결제 까지 승인이 나기위해서는 영업일 기준 최..
토스페이먼츠 서브몰 관련 문제를 해결하여 등록은 완성되었으니 추가적으로 조회, 수정, 삭제까지 구현해보겠다. 서브몰 조회 Controller Submall 조회 @GetMapping @ApiOperation(value = "서브몰 조회", notes = "판매자의 서브몰을 조회합니다.") public SingleResult registSubmall( @ApiParam(value = "코디네이터 이메일", required = true) @RequestParam String crdiEmail ) { try { return responseService.getSingleResult( submallService.getSubmall(crdiEmail) ); } catch (Exception e) { e.printS..
지급대행 앞에서 우리 서비스에 등록된 판매자들이 정산받기 위해 등록하는 계좌에 대한 검증을 금융결제원의 계좌실명조회 API를 통해 하려고 했었다. 하지만 이는 일반적인 가맹점에서는 불가능하고 토스페이먼츠에서 제공하는 API를 통해서 서브몰들을 등록/조회/정산 등을 할 수 있다. 따라서 기존 금융결제원 방식의 계좌번호 실명조회 기능을 버리고 토스페이먼츠에서 제공하는 지급대행 API를 통해서 서브몰을 등록하고 조회 후 정산 관련 업무를 위한 기능까지 만들어보겠다. 서브몰 구조 & 등록 구현 우리 서비스를 이용하는 판매자는 우선적으로 자신의 은행, 계좌번호 등을 등록하여 서브몰을 등록해줘야 한다. 이때 서브몰의 고유한 아이디, 상호명, 대표명, 사업자 등록번호, 개인/법인 등이 필요하고 정산을 받기 위한 은행..
가상결제를 완료했으니 취소까지 이어서 해보겠다. 이 부분은 이전 카드 결제취소 부분과 매우 흡사다. 다만 계좌이체로 금액을 지불하였으므로 환불도 환불계좌로 돌려주는 방식으로 해줘야 한다는 점이다. 따라서 결제 취소 때 cancelReason 외에도 cancelAmount와 환불입금계좌 정보를 입력해서 요청해줘야 한다. 토스페이먼츠에서 명시하고 있는 환불 요청 양식을 봐보자. 토스페이먼츠 환불요청 HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://api.tosspayments.com/v1/payments/{_페이먼트키_}/cancel")) .header("Authorization", "Basic _클라이언트_키") .header..
앞에서 정리한 내용을 바탕으로 실제 가상계좌 결제를 코드로 만들어보자. 먼저 카드결제만 존재하던 기존의 서비스를 가상결제도 가능하게 변경해줘야겠다. 기존 결제 요청 로직 수정 결제수단 추가 @Getter @RequiredArgsConstructor public enum PayType { CARD("카드"), VIRTUAL_ACCOUNT("가상계좌"); private final String name; } 카드든 가상계좌든 프론트에서 결국 그에 맞게 requestPayment("결제수단", {"결제 파라미터"}) 를 호출해줘야 한다. 이건 일단 프론트에게 맡기도록 하고 이후 사용자가 해당 호출로 뜬 토스페이먼츠의 결제 시스템을 이용해서 카드결제를 진행하거나 또는 가상계좌번호를 발급하게 될것이다. 위 과정이 ..
추가적인 이슈로 인해 가상계좌 결제방식도 추가하게 되었다. 가상계좌 결제와 카드 결제의 대표적인 차이점은 결제완료시점에 있다. 카드결제의 경우 이용자의 결제 요청 후 과정 완료와 함께 결제도 완료가 된다. 반면 가상계좌의 경우 결제 요청 과정이 완료되어도 이용자가 입금할 때 까지 해당 결제는 완료되지 않는다는 것이다. 따라서 비동기적으로 이뤄지는 결제 절차에 대응하기 위해서 입금 또는 취소되는 결제 상태 변화가 발생 할 때 바로 알 수 있도록 토스페이먼츠에서 등록된 콜백 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간선을 지우고, 트리 두개의 지름을 구한 후, 해당 간선의 길이를 더했을때가 해당 간선을 지웠을 때 최대로 가질 수 있는 지름이 된다. 어짜피 트리 + 트리 이므로 어느 노드에 연결할지는 중요하지 않고 간선을 지웠을 때 각 트리가 가지는 최대 지름만 잘 구해주면 된다. 문제..
- Total
- Today
- Yesterday