개요
다양한 경험을 통해 실력을 높이고 싶은 인턴 디자이너들과 저렴한 가격으로 디자인을 받고 싶은 고객들을 연결해주는 예약 사이트인 GlowGrow 프로젝트에서 결제 후 정산 시스템을 도입했습니다.
GlowGrow 프로젝트에서는 프로모션을 통해 다양한 할인 혜택을 제공합니다. 서비스 제공자인 디자이너가 자신의 서비스에 대해 쿠폰을 발급할 수 있을 뿐만 아니라, GlowGrow 운영 측에서도 직접 쿠폰을 발행하여 고객에게 제공할 수 있습니다.
고민 사항
프로모션 서비스의 쿠폰에는 2가지 종류가 있는데, 운영 측(Glowgrow)에서 제공하는 쿠폰과 서비스 제공자(PROVIDER)가 제공하는 쿠폰이 있습니다.
이에 따라 쿠폰의 종류에 따라 정산 방식도 달라져야 한다고 판단했습니다.
운영 측에서 제공한 쿠폰을 사용한 경우에는 그 할인액을 운영 측에서 부담해야 하며, 서비스 제공자가 발급한 쿠폰의 할인액은 해당 서비스 제공자가 부담하는 것이 적절하다고 생각했습니다.
따라서 쿠폰 종류에 따라 할인 전 금액과 할인 후 금액을이 이루어져야 합니다.
로직 수정 - 쿠폰
현재 운영측에서 발급한 쿠폰인지, 서비스 제공자가 발급한 쿠폰인지를 구분할 필드가 없었습니다. 이를 해결하기 위해 쿠폰의 종류를 구분할 필드를 새로 추가하거나 다른 방법이 필요했습니다.
프로젝트가 막바지에 이르러 기존 로직을 크게 수정하는 것이 어려웠기에, 현재 응답 DTO에서 사용할 수 있는 CouponCode를 활용하여 쿠폰의 종류를 구분하는 방법을 선택했습니다.
따라서 현재 쿠폰의 응답 DTO에서 쿠폰의 종류를 구분할 수 있는 필드는 CouponCode가 있기 때문에 이 CouponCode를 수정요청을 했습니다.
프로모션을 담당하는 팀원과 의사소통을 통해 쿠폰 생성자에 따른 쿠폰 Code를 구분하도록 수정요청을 했습니다.
프로모션 팀과의 협의를 통해 쿠폰 생성자의 권한에 따라 CouponCode를 구분하도록 요청했습니다. 이에 따라, 쿠폰 생성 로직에서 다음과 같은 방식을 적용했습니다.
- 쿠폰 생성 주체가 MASTER(SYSTEM) 권한일 경우, GlowGrow + UUID 형태로 코드 생성 ➡️ 운영측 발급 쿠폰
- 쿠폰 생성 주체가 PROVIDER 권한일 경우, userID + UUID 형태로 코드 생성 ➡️ 디자이너 발급 쿠폰
로직 수정 - 정산
정산 로직을 다음과 같이 수정했습니다.
calculateSettlementAmountForPayment 메서드는 결제(Payment) 정보에서 쿠폰 사용 여부와 쿠폰 종류에 따라 정산 금액을 계산합니다.
private long calculateSettlementAmountForPayment(Payment payment) {
// 쿠폰을 사용하지 않은 경우 또는 PROVIDER 쿠폰을 사용한 경우
if (payment.getCouponId() == null || payment.getCouponType() == CouponType.PROVIDER) {
return payment.getAmount();
}
// GLOWGROW 쿠폰을 사용한 경우
if (payment.getCouponType() == CouponType.GLOWGROW) {
return payment.getOriginalAmount();
}
// 알 수 없는 쿠폰 타입
throw new IllegalStateException("Unknown coupon type: " + payment.getCouponType());
}
이 로직에 따라 쿠폰이 없거나 PROVIDER 쿠폰을 사용한 경우 payment.getAmount() 값을 반환하고, GLOWGROW 쿠폰을 사용한 경우 원래 결제 금액인 payment.getOriginalAmount()를 반환하도록 합니다.
총 정산 금액을 계산하는 calculateTotalAmount 메서드는 각 결제 내역에 대해 위의 로직을 적용하여 정산 금액을 합산합니다.
private long calculateTotalAmount(List<Payment> payments) {
return payments.stream()
.mapToLong(this::calculateSettlementAmountForPayment)
.sum();
}
이렇게 해서, calculateTotalAmount 메서드는 각 결제의 쿠폰 유무와 종류에 따라 계산된 금액을 합산하여 최종 정산 금액을 산출하게 됩니다.
테스트 결과, PROVIDER가 제공한 쿠폰을 사용한 결제 금액은 할인 후 금액인 36,000원으로, 운영 측(GLOWGROW)에서 제공한 쿠폰을 사용한 결제 금액은 원래 결제 금액인 50,000원으로 정상적으로 계산되었습니다.
따라서 최종 정산 금액은 50,000 + 36,000 = 86,000원으로 산출됨을 확인할 수 있었습니다.
이번 작업을 통해 GlowGrow 플랫폼의 결제 정산 로직을 쿠폰 종류에 따라 효과적으로 분리해 운영할 수 있었습니다. 운영 측과 서비스 제공자 부담을 명확히 구분함으로써, 각자의 할인 정책을 유연하게 적용할 수 있는 체계를 마련했습니다.
'TIL,일일 회고' 카테고리의 다른 글
[TIL, 일일 회고] 2024.11.04 - 코딩 관련 기초 지식 (등차수열) (0) | 2024.11.04 |
---|---|
[TIL, 일일 회고] 2024.11.04 - 게시판 좋아요 기능 동시성 문제 해결 및 고도화된 부하 테스트 (0) | 2024.11.04 |
[TIL, 일일 회고] 2024.11.02 - JWT 인증을 위한 Swagger 설정방법 (0) | 2024.11.02 |
[TIL, 일일 회고] 2024.11.01 - springdoc-openapi-ui (0) | 2024.11.01 |
[TIL, 일일 회고] 2024.10.31 - 효율적인 MSA 배포를 위한 GitHub Actions의 Matrix Strategy 활용 (0) | 2024.10.31 |