🛒 Backend Engineering · 1/9 · 약 7분

Backend Engineering 시리즈 전체 보기

가격이 고정되지 않은 상품은 주문 버튼을 누르는 순간 최종 금액을 확정하기 어렵다. 화면에 보인 예상과 실제 준비 결과가 달라질 수 있는데, 두 값을 같은 약속으로 취급하면 변경과 취소가 모두 예외가 된다.

서로 독립적인 가상 상거래 사례를 놓고 결제 가능성 확인과 실제 청구 확정을 나눠 보았다. 관점을 두 시점으로 분리하자 각 단계의 불변 조건, 실패 뒤 책임, 사용자에게 보여 줄 문장이 선명해졌다.

#Backend · #Payment · #StateMachine · #Architecture

이 글에서 다룰 것

• 예상 금액과 확정 금액이 답해야 하는 서로 다른 질문
• 가승인부터 최종 결제까지 상태와 실패를 연결하는 방법
• 해제와 재시도를 정상 경로로 설계하는 기준

1. 예상과 확정은 서로 다른 약속이다

가상의 포장 상품 주문을 생각해 보자. 주문 시점에는 구성 범위만 알 수 있고, 준비가 끝나야 최종 결과가 정해진다. 예상값을 바로 청구하면 차이가 생길 때마다 추가 결제나 환불이 뒤따른다.

반대로 아무 확인 없이 준비를 시작하면 결제 가능성을 너무 늦게 알게 된다. 그래서 예상 금액은 구매 판단을 돕고 결제 가능성을 확인하는 값으로, 확정 금액은 실제 결과를 근거로 청구하는 값으로 구분한다.

이 흐름의 핵심 불변 조건은 세 가지다.

• 가승인만 성공한 주문을 결제 완료로 표시하지 않는다.
• 최종 확정은 실제 결과와 한 번만 연결한다.
• 취소된 주문에 남은 가승인은 반드시 해제 대상으로 기록한다.

2. 상태 흐름으로 두 시점을 연결한다

두 단계는 결제 API를 두 번 호출한다는 뜻에 그치지 않는다. 각 단계가 어떤 상태를 만들고 다음 단계에 무엇을 약속하는지 정의해야 한다.

예상 범위 안내
      ↓
결제 가능성 확인 ── 실패 ──→ 주문 종료
      ↓
실제 구성 확인
      ↓
최종 청구 확정 ── 실패 ──→ 재시도 또는 검토 대기
      ↓
주문 완료