#payment
-
판매자 잔액 조회 기능 추가
20260329 0045 merchant balance feature 2026-03-28에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL
읽기 → -
파트너 주문 입금 처리 안정성 개선
20260328 1925 partner-order-deposit-upgrade 2026-03-28에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 -
읽기 → -
정산 수수료 계층 구조 검증
정산 요약 UI 수정 및 지불 금액 구성 로직 개선 2026-03-28에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|-
읽기 → -
연락처 송금 비회원 주문 누락
연락처송금 사전 매칭에서 비회원 주문 누락 수정 2026-03-27에 연락처 송금 기능의 버그를 수정했음. 연락처 송금은 은행 앱 화면을 자동으로 조작해서 입금 처리를 완료하는 구조임. 각 은행별로 UI가 다르기 때문에 은행별 핸들러가 개별로 존재하고, Playwright로 브라우저를 제어함. 수정 포인트 - 은행 셀렉터 감지 로직 오류 - 계좌
읽기 → -
계층별 수수료율 차등 계산
수수료 유형 및 수수료율 계산 로직 확장 2026-03-27에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|---| |
읽기 → -
연락처 송금 핸들러 자가학습
연락처 송금 비즈니스 로직 동기화 (404_pjt → pg-solution) 2026-03-25에 연락처 송금 관련 기능을 추가하거나 개선했음. 연락처 송금 흐름은 대략 이렇게 됨: 입금 알림 수신 (Android 앱) → 서버로 원본 메시지 전송 → 주문 매칭 (금액 + 발신자 + 시간) → 은행 핸들러 실행 (Playwright)
읽기 → -
송금 푸시 알림 미수신을 재시도 큐로 해결
문제 상황 연락처 기반 송금 기능에서 푸시 알림이 가끔 빠지는 이슈가 보고됨. 로그 까보니 푸시 발송 자체는 호출되는데 토큰 만료/네트워크 일시 단절 같은 케이스에서 그냥 한 번 던지고 끝나는 구조였음. 받는 쪽은 돈 들어왔는지 모르고 있다가 나중에 앱 켜서 알게 되는 흐름. 송금 UX에서 꽤 치명적임. 원인 정리 기존 코드는 단발성 호출. 실패
읽기 → -
결제 웹훅 중복 수신 막고 정산 추적 로그 정비
웹훅 개선하면서 깨달은 것 결제대행사 쪽에서 들어오는 웹훅이 가끔 누락되거나 중복으로 찍히는 이슈가 있었음. 처음엔 "재시도 정책이려니" 하고 넘겼는데, 정산 데이터 검수하다가 같은 거래에 대해 콜백이 3번 들어온 케이스를 발견했음. 더는 못 미루겠다 싶어서 손댐. 무엇을 바꿨나 핵심은 두 가지. **웹훅 수신부 자체의 멱등성 보장**과 **로그를
읽기 → -
결제 앱 APK 변조·정산 탈취 막은 다층 무결성 방어
배경 이커머스 앱이 마켓에 풀린 뒤로 이상한 트래픽이 잡히기 시작했음. 정상 클라이언트로는 절대 나올 수 없는 호출 패턴이 보였고, 추적해 보니 APK 디컴파일 후 재서명한 변종이었음. 단순 난독화로는 한계가 명확했고, 결제 플랫폼 특성상 파트너 정산 데이터에 손대는 게 보여서 더 미룰 수 없었음. 1차: 서명 해시 검증 가장 먼저 한 건 런타임
읽기 → -
결제 웹훅 원장·잔액 대조 배치로 정산 분쟁 추적 가능해짐
웹훅 원장 기록부터 깔았음 결제대행사 웹훅이 들어올 때 처리만 하고 흘려보내던 구조였는데, 정산 분쟁 한 번 터지고 나니 "그때 그 웹훅 진짜 왔었냐"는 질문에 답을 못 했음. 헤더, 페이로드, 서명검증 결과, 처리 결과까지 전부 원장으로 적재하기로 했음. - 들어온 원본은 가공 없이 그대로 저장 - 처리 단계별 상태 코드 분리 (수신완료 / 검증완료
읽기 → -
결제대행사 충전 화면 개선과 조회 쿼리 최적화
무엇을 건드렸나 결제대행사 연동 충전건의 상세 화면과 리스트 화면을 손봤음. 어드민에서 보던 충전 상세는 정작 운영자가 필요한 정보가 흩어져 있어서 매번 DB 스크립트로 까봤는데, 이걸 화면에서 한 번에 확인 가능하게 정리. 작업한 레이어 정리하면 이런 모양: | 레이어 | 변경 포인트 | |---|---| | 어드민 컨트롤러 | 상세 응답 DTO
읽기 → -
결제 수수료 정산을 지연 차감 방식으로 전환해 환불 흐름 단순화
배경 결제 플랫폼에서 파트너에게 부과되는 수수료를 결제 즉시 차감하는 기존 로직이 있었음. 문제는 이커머스 특성상 결제 후에도 환불/취소가 빈번하게 일어난다는 점. 즉시 차감해버리면 환불이 들어왔을 때 수수료를 다시 환원해야 하는데, 이 역방향 흐름이 곳곳에서 깨지고 있었음. 흐름 재설계 결제대행사에서 정산 데이터가 넘어오는 시점을 기준으로 상태를
읽기 → -
결제대행사 연동 제거로 충전 로직 버그까지 발견 정리
결제대행사 연동 삭제와 충전 로직 손질 오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것. 왜 들어냈는가 - 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴 - 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리) - 다른 결제대행
읽기 → -
충전 수수료를 충전 트랜잭션 단위로 매칭해 회계 역추적 해결
충전 수수료 차감, 어느 시점 요율을 따라야 하나 결제 플랫폼에서 파트너가 잔액을 충전할 때 충전 수수료를 떼는 구조인데, 환불·취소 흐름에서 차감 기준이 애매했음. 충전 시점 요율을 박아두는 방식이었는데, 파트너 등급이 중간에 바뀌면 과거 충전건과 현재 차감액이 어긋남. 회계팀에서 "이 충전건이 그 차감인지 매칭이 안 된다"는 컴플레인이 들어와서 손을
읽기 → -
결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선
새 결제 수단 붙이기 이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함. 처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리
읽기 → -
카드 충전 수수료 차감 로직 원자적 처리 구현
feat: 결제대행사 카드 충전 수수료 차감 로직 추가 로직을 구현했음.
읽기 → -
에이전트 산출물 디렉터리를 깃이그노어로 차단해 PR 노이즈 제거
.omc/ 를 .gitignore 에 박은 이유 작업 도중 워킹트리에 .omc/ 디렉터리가 슬금슬금 늘어나는 걸 발견함. 에이전트 상태, 노트패드, 프로젝트 메모리, 플랜 초안, 로그까지 죄다 그 안에 쌓이고 있었음. 깜빡하고 한 번 커밋했다가 PR 디프가 본질 변경 30줄에 부산물 800줄로 부풀어버려서, 리뷰어가 "이거 뭐냐"고 물어본 게 트리거였음
읽기 → -
결제대행사 회원 동기화를 비동기 큐로 전환해 정산 누락 해소
발단 이커머스 결제대행사 연동 작업 중 회원 정보 동기화 스펙 추가 요청 받았음. 신규 가입 시 결제대행사 쪽에 우리 회원 식별값을 함께 넘겨야 환불·정산 매칭이 깔끔해진다는 운영팀 피드백 때문이었음. 기존엔 결제 시점에 임시로 끼워 넣고 있어서 매칭 누락이 가끔 터졌음. 무엇을 추가했는가 가입/수정 흐름에 정식 필드를 박고, 변경 이벤트를 외부로
읽기 → -
가상계좌 수수료 후정산 전환과 충전 상태 머신 정합성 확보
가상계좌 충전 수수료, 결국 후정산이 답 결제대행사 가상계좌로 잔액 충전하는 흐름에서 수수료 처리가 계속 어긋났음. 충전 시점에 수수료까지 한 번에 차감하니까 회계팀에서 "이게 왜 여기서 빠져?"가 반복됨. 가상계좌 건당 부과되는 입금/발급 비용은 **이번 정산 시 차감되는 게 아니라 익월에 별도 청구**되는 구조. 그동안 코드는 충전 직후 머천트 잔
읽기 → -
이커머스 파트너 충전 결제 연동과 잔액 정산 안정화
결제대행사 충전 플로우 붙이기 이커머스 파트너 잔액에 충전 기능 하나 추가하는 일이었음. 단순히 API 한 개 더 까는 줄 알았는데, 결제대행사 쪽 응답 파싱이랑 트랜잭션 경계 잡는 게 생각보다 까다로웠음. 기본 흐름은 이렇게 정리: - 클라이언트 충전 요청 → 서버에서 주문 키 발급 - 결제대행사 팝업 띄워서 결제 진행 - 콜백 수신 → 검증 →
읽기 →