#payment
-
정산 수수료 누적 구조와 멱등성·상태 전환 설계 정리
feat: 정산 및 웰컴페이(payment/settlement) 스킬 문서 추가 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 |
읽기 → -
수수료 단계별 정산 로직과 멱등성 처리 구현
docs: 수수료 시스템 구현 지시서 및 결과 보고서 추가 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 | 수익 | |-----
읽기 → -
파트너 실시간 문의용 PIP 채팅 위젯 구현
feat: PIP 채팅 위젯 기능 추가 관리자 채팅 기능 추가 작업임. 파트너가 관리자에게 실시간으로 문의할 수 있는 PIP 채팅 위젯 구현. 채팅 아키텍처 WebSocket 대신 Polling 방식으로 구현함. 실시간성이 중요한 채팅이 아니라 문의/답변 형태여서 30초 폴링으로 충분함. javascript // 30초마다 새 메시지 확인 set
읽기 → -
위젯 스타일 디자인 토큰 통일
feat: 신규 SCSS 기반 위젯 스타일 추가 CSS/SCSS 작업은 눈에 잘 안 보이지만 쌓이면 시스템 전체 일관성에 영향 줌. 이번엔 디자인 토큰 통일과 반응형 최적화가 메인이었음. CSS 변수 통일 작업 컴포넌트마다 4px, 6px, 8px, 12px이 혼재해있었음. 디자인 시스템 기준을 잡고 CSS 변수로 통일함. scss :root {
읽기 → -
정산 수수료 단계별 누적 구조와 멱등성 처리 개선
feat: 정산 로직(수수료/마진) 및 Pay 정책 등급 기반 개선 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 | 수익 | |
읽기 → -
결제 알림 채널별 발송
feat: Pay 알림 헬퍼 클래스 추가 알림 시스템 구현 작업임. 거래 이벤트마다 적절한 채널로 알림을 발송하는 구조를 잡았음. 알림 채널 | 채널 | 용도 | 특징 | |------|------|------| | 앱 PUSH | 실시간 거래 알림 | FCM 사용 | | SMS | 중요 인증/보안 | 비용 발생 | | 이메일 | 정산/명세서 |
읽기 → -
보이스피싱 방지
보이스피싱 방지 기능 및 이용중지 체크 로직 추가 2026-02-06에 마무리한 기능 구현 작업. 컨트롤러, 인터셉터 영역을 중심으로 end-to-end 흐름을 완성했음. 작업 배경 요구사항이 확정된 후 어느 레이어부터 건드릴지 먼저 정했음. 이번엔 API 스펙을 먼저 잡고 역방향으로 내려가는 방식을 택했음. 외부 연동이 있거나 응답 포맷이 먼저
읽기 → -
이커머스 결제 API 문서 전면 보완으로 코드 불일치까지 해결
이커머스 결제 연동 플랫폼 API 명세 전체 보완 및 신규 섹션 추가 2026-02-06. API 문서 작업. 코드가 아무리 잘 짜여 있어도 문서가 없으면 다른 사람이, 또는 미래의 내가 쓰기 어려움. 문서화 범위 - **API 엔드포인트**: 경로, HTTP 메서드, 요청/응답 스펙 - **파라미터 명세**: 필수/선택 여부, 타입, 유효성 규칙
읽기 → -
파트너 포털 결제 API 문서 정비로 온보딩 시간 단축
Pay 관리 및 파트너 포털 관련 API 문서 업데이트 2026-02-06. 내부 문서 정비 작업. 신규 멤버가 왔을 때 온보딩 시간을 줄이는 게 목표였음. 왜 지금 했나 기능 개발이 어느 정도 안정됐고, 이 시점에 문서를 안 쓰면 나중에는 더 안 쓰게 됨. 코드를 짤 때의 맥락과 결정 이유는 시간이 지나면 희미해지기 때문에, 그 기억이 남아 있을
읽기 → -
뷰 템플릿 리팩토링으로 중복 제거와 책임 분리 완료
스타일 제거 및 메뉴 구조 업데이트 2026-02-06. 코드 품질 개선 작업. 기능은 그대로 유지하면서 구조를 다듬었음. 리팩토링 동기 기능이 계속 추가되면서 뷰 템플릿 영역의 코드가 비대해지기 시작했음. 하나의 함수가 너무 많은 일을 하거나, 같은 로직이 여러 파일에 흩어져 있거나, 네이밍이 실제 역할을 반영 못 하는 케이스들이 쌓였음. 무
읽기 → -
후원 관리 페이지와 API를 처음부터 구현한 과정
후원 관리 페이지 및 API 구현 2026-02-06. 컨트롤러, SQL 쿼리 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API 연결** — 외부에서 호출
읽기 → -
Pay 잔액 상세 페이지 추가와 결제 관련 코드 정리로 유지보수성 개선
KYC 및 영수증 관리 페이지 삭제, Pay 잔액 상세 페이지 추가 2026-02-06에 진행한 코드베이스 정리. 당장 눈에 띄는 효과는 없지만 장기적으로 개발 속도를 유지시켜 주는 핵심 작업임. 리팩토링 원칙 이번 작업에서 적용한 원칙들: 1. **단일 책임**: 하나의 함수/클래스는 하나의 일만 2. **DRY**: 중복 코드는 반드시 추출
읽기 → -
Quick Send 목록 조회 기능을 컨트롤러와 뷰까지 완전 연동
Quick Send 목록 조회 기능 추가 2026-02-05. 컨트롤러, 뷰 템플릿 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API 연결** — 외부에서
읽기 → -
선물 내역 조회 기능을 컨트롤러·쿼리·뷰 전 레이어에 구현
선물 내역 조회 추가 및 연관 스타일 파일 작성 2026-02-05. 컨트롤러, SQL 쿼리, 뷰 템플릿 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API
읽기 → -
이커머스 결제 플랫폼에 공지 티커와 푸터 정보 로드 기능 추가
이커머스 결제 연동 플랫폼 사이트 공지사항 티커 및 푸터 정보 로드 기능 추가 2026-02-05. 컨트롤러, 뷰 템플릿 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작
읽기 → -
이커머스 결제 연동 서비스 전체 레이어 신규 구현
이커머스 결제 연동 플랫폼 Pay 서비스 전체 구현 (Controller + Mapper + JSP + DDL) 2026-02-05. 비즈니스 로직 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구
읽기 → -
카카오 Webhook 계정 해제 로직에 트랜잭션 처리 추가
카카오 Webhook 계정 해제 로직 트랜잭션 처리 추가 2026-02-04. 컨트롤러 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API 연결** — 외부
읽기 → -
결제대행사페이 웹훅 컨트롤러 신규 연동
결제대행사페이 연동 및 Webhook 컨트롤러 추가 2026-02-04. 컨트롤러 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API 연결** — 외부에서
읽기 → -
결제 연동 코드 리팩토링으로 중복 제거
결제대행사페이 notiUrl 제거 및 API V1.5 명세 반영 2026-02-03. 코드 품질 개선 작업. 기능은 그대로 유지하면서 구조를 다듬었음. 리팩토링 동기 기능이 계속 추가되면서 컨트롤러, 유틸리티, 서비스 레이어 영역의 코드가 비대해지기 시작했음. 하나의 함수가 너무 많은 일을 하거나, 같은 로직이 여러 파일에 흩어져 있거나, 네이밍이
읽기 → -
결제대행사머니 충전·취소·사용 로직 구현
결제대행사머니 충전, 취소 및 사용 관련 로직 추가 2026-02-03. 서비스 레이어, 유틸리티 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 서비스 레이어부터 시작 3. **API
읽기 →