2025.11.06 외부api 6 + 정산

 

2025.11.01~2 외부API 5

이전 글에 이어서..

사실 어느 정도 끝까지 왔다고 생각했는데, 새로운 요구 사항이 있다.

위의 설계는 주문당 결제의 개념이다. 일반적인 이커머스는 대부분 이럴 것이다.

근데, 지금의 상황은 좀 다르다. 월결제, 주결제로 운영이 되는 업체들이 있다.

 

그럼 이전의 설계에서 이중 결제를 막기 위해서 주문의 결제 상태를 관리했던 것처럼, 가게의 결제를 관리해야 한다.

월 누적 금액을 가게의 장부에 기록하고 있기 때문이다.

(결제 대기 상태의 주문 금액을 모두 더하고, 그걸 결제 시 사용하면 안 되나? 그래야 결제와 주문이 연결 가능할 거 같은데.. 고려해 보자.)

일단 현재 구현되어 있는 사항이 그러니, 구현을 바꾸지 않는 이상 가게의 장부 금액을 결제에 사용한다.

결제 api를 호출하고, 가게의 결제 상태를 변경해야 한다. 이후 콜백에서 상태를 수정해야 한다.

가게의 장부 결제는 주문과 달리 결제 가능 상태 라이프 사이클이 반복해서 돌아오도록 구현해야 하기 때문이다.

결제 가능 -> 결제시작-> 결제 성공 -> 결제 시작 -> 결제 성공

뭐 이런 식이지 않을까?

어드민이 장부의 금액을 유동적으로 결제도 할 수 있기 때문에 클라이언트에서 올라오는 값을 결제에 사용한다.

장부에 누적100만 원이 있어도 클라이언트에서 50만원이 올라오면 50만원을 결제하는 것이다. 100만원이 초과되는 요청은 거부하거나, 100만 원으로 처리해야 한다.

여기서 발생할 수 있는 문제는 콜백으로 처리했을 때 어드민에게 보이는 장부 금액이 실시간으로 줄어들지 않는다는 점이다.

(이건 뭔가 다른 개념으로 처리할 수도 있을 거 같다.)

어드민이 장부 결제 금액을 마이너스로 처리하는지 여부도 확인해 보자. 장부니까 금액을 미리 채워 넣는다는 개념을 사용하고 있을 수 있다.(이게 맞는 처리일까?)

 

또 콜백에서의 비즈니스 로직처리 + 결제응답을 받고 나서의 비즈니스 로직처리. 두 곳에서 처리했을 때의 장점은 무엇일까?

결제응답 이후의 처리는 어드민에게 화면의 즉각적인 장부 금액 변화를 알려줄 수는 있겠다. 콜백으로 비즈니스 로직을 전부 처리해 버리면 화면 반영을 실시간으로 처리하기 힘들기 때문이다.

앞서 말했듯이 현재 장부 결제는 클라이언트에서 올라오는 값을 사용하고 있기 때문에 이는 문제가 될 가능성이 크다.

그래서 클라이언트에서 올라오는 값을 검증해야 하는데, DB장부보다 작은 값이 올라올 경우는 문제가 되지 않겠지만, 큰 값이 들어올 경우는 문제가 될 수 있다. 근데 큰 값이 들어오는 게 말이 되는지부터 봐야 한다. 막을 수는 있지만 비즈니스적으로 원할 수 있다.

 

또 콜백의 순서는 어떠한가? 가게가 여러 번의 결제를 진행한다면 그 결제의 순서는 지켜져야 하는가? 아니면 단순하게 처리되는 구조인가? 단순한 처리가 가장 베스트이긴 하다. 예로 update set amount = amount - {pay} 뭐 이렇게 말이지.

 

또 주문의 결제를 하는 것도 구현의 편의? 성 때문에 장부에 기록하도록 만들어져있다.

그럼 장부의 누적금액을 결제할 때 클라이언트이 요청과 병목이 생길 수 있는 것이다.

이것도 고려해야하는 케이스일까?

 

이전에도 말했지만, 알 수 없음 처리는 백그라운드 워커가 주기마다 pg사에 조회해서 처리할 것이고. 

 

+

정산의 개념으로 관련 설계를 리서치해봐야겠다.

 

정산시스템팀을 소개합니다. | 우아한형제들 기술블로그