결제 충전 부분 취소 상태 도입과 취소 가능 여부 사전 검증

결제 플랫폼의 충전 취소 기능을 다루면서, 부분 취소라는 새로운 상태를 도입했다. 단순한 상태 추가가 아니라 결제 수단별 취소 가능 여부를 사전 검증하는 로직까지 함께 들어간 작업이었다.

부분 취소 상태의 필요성

기존에는 충전 거래의 취소가 전부 아니면 전무였다. 하지만 운영 현장에서 보면 상황이 더 복잡하다. 예를 들어 사용자가 실수로 과도한 금액을 충전했을 때, 전액 취소보다는 일부만 되돌려주고 나머지는 유지하는 게 나을 수도 있다. 또는 거래 일부가 정산 실패했을 때 그 부분만 취소 처리해야 하는 경우도 생긴다.

이런 시나리오들을 지원하려고 PARTIAL_CANCELLED 상태를 새로 정의했다. 단순히 UI에 새 상태를 표시하는 것뿐 아니라, 부분 취소로 이동 가능한 조건들을 명확히 하고 데이터 흐름을 일관되게 유지해야 했다.

BrandPay 취소 가능 사전조회의 의미

여기서 흥미로웠던 부분은 "BrandPay cancelable 사전조회"다. 결제 수단마다 취소 정책이 다르다는 뜻이다. 특정 브랜드의 결제 수단(예: 특정 PG의 포인트나 선결제 상품)은 취소 가능 여부가 실시간으로 변한다. 예를 들어 유효기간이 지났거나, 해당 수단의 정산 주기를 넘어서면 취소가 불가능해질 수 있다.

그래서 부분 취소 화면을 보여주기 전에, 미리 취소 가능 여부를 조회해서 UI에 반영하도록 설계했다. 이렇게 하면:

• 사용자가 취소 불가능한 상태에서 버튼을 클릭하는 UX 상황을 사전에 차단
• 취소 시도 시점의 실제 가능 여부와 화면 표시가 일치
• 실패하는 요청 수를 줄여서 서버 부하 감소

구조적 고민

파일 변경 범위를 보면 컨트롤러, 쿼리, 그리고 5개의 JSP 화면이 함께 변경되었다. 이런 광범위한 변경을 할 때는 항상 일관성을 유지하는 게 핵심이다.

예를 들어, 상태 코드 문자열은 한 곳에만 정의해서 모든 계층이 같은 상수를 참조하도록 해야 한다. 쿼리에서도, 자바 코드에서도, JSP에서도 PARTIAL_CANCELLED이라는 문자열을 하드코딩하면 나중에 상태명이 바뀔 때 대참사가 난다. 여러 화면에서 같은 상태를 다루기 때문에 일관된 표시도 중요했다.

또한 부분 취소 가능 여부 조회는 매 요청마다 PG 시스템에 물어봐야 할 수도 있는데, 이게 성능에 미치는 영향을 고려해야 한다. 캐싱을 할 수 있을지, 조회 빈도를 어떻게 제한할지 같은 부분도 함께 검토했다.

회고

이 작업을 통해 느낀 점은, 상태(state) 관련 변경은 단순해 보여도 시스템 곳곳에 파급된다는 거였다. 새로운 거래 상태 하나를 추가할 때는:

• 상태 정의와 전환 규칙을 명확히 하기
• 외부 시스템(PG, 결제 수단)의 정책을 먼저 파악하기
• UI 여러 곳에서 그 상태를 어떻게 표시할지 먼저 설계하기
• 기존 거래 데이터가 새 상태와 어떻게 공존할지 고민하기

특히 BrandPay처럼 외부 시스템과 연동되는 조건들은 사전조회(pre-flight check) 패턴을 통해 UX와 신뢰성을 동시에 확보할 수 있다. 액션을 시도하기 전에 가능 여부를 미리 확인해서 사용자에게 보여주는 방식이 결국 가장 깔끔한 설계다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.