주문 결제에 쿠폰 서버 재검증과 결제대행사 파라미터 통합

쿠폰 적용을 주문 흐름에 끼워넣기

하루 종일 주문 처리 흐름 만지작거림. 이커머스에서 쿠폰은 "할인액 빼면 끝"이 아니라 결제 직전에 금액을 다시 계산해야 하는 까다로운 친구임.

• 쿠폰 유효성: 만료, 최소 주문금액, 중복 사용 여부
• 적용 순서: 상품 할인 → 쿠폰 → 포인트 → 결제대행사로 넘길 최종 금액
• 클라이언트가 보낸 할인액을 그대로 믿으면 안 됨. 서버가 재계산해서 불일치 시 거절

처음에 클라이언트 계산값을 그대로 받는 코드를 봤는데, 이대로 두면 누가 임의로 0원 결제를 만들 수 있음. 서버 재계산 + 검증 단계를 강제로 끼워넣음. 페이지 빌더와 위젯 쪽에서 쿠폰 노출 영역을 만들어두고, 주문 흐름에서는 코드 입력만 받아 백엔드가 끝까지 책임지는 구조로 정리.

결제대행사 API 파라미터 정리

파라미터가 산만하게 흩어져 있어서 호출할 때마다 키 이름 헷갈렸음. 카멜/스네이크 혼재라 더 짜증.

DTO 한 곳으로 모으고 직렬화 규칙도 하나로 못박음. 빌더로 빠뜨린 필드 컴파일 타임에 잡히게 함.

- 요청 DTO 단일 클래스 통합
- 응답 DTO 분리, 매핑 명확화
- 빌더 패턴으로 필수값 누락 방지

SQL 매퍼명 수정

오타 + 케이스 불일치 때문에 매퍼를 못 찾는 사고가 있었음. selectOrderlist → selectOrderList 같은 자잘한 거. 매퍼 ID는 호출부 메서드명과 1:1로 맞추는 게 디버깅 속도에서 가장 차이남. grep 한 번으로 양쪽이 동시에 잡혀야 함.

내 API 영역에서 쓰던 매퍼도 같은 규칙으로 일괄 정리. 자동 매핑에 의존하다 보면 IDE 리팩터링이 매퍼 XML까지 따라오지 않아서, 명명 규칙을 사람이 직접 지키는 수밖에 없음.

회고

오늘 만진 영역이 4개. 페이지 빌더, 위젯, 주문, 내 API. 주제는 다른데 결국 한 줄로 수렴함 — "사용자 입력을 믿지 말고 서버 경계에서 다시 검증". 쿠폰도, 결제 파라미터도, 매퍼명도 전부 신뢰 경계와 명명 일관성 문제였음.

내일은 쿠폰 중복 사용 케이스 테스트 더 깎고, 결제대행사 응답 실패 시나리오 회귀 테스트 붙일 예정. 끝