프로젝트 ERD
⭐️ 해당 포스팅에는 위 시트에서 본인이 맡은 파트에 관해서만 정리했습니다.
(결제,포인트,보증금 이 외의 기능은 부분은 따로 작성하여 링크 첨부할 예정)
📌 결제 서비스
- 포인트 부족시 결제 진행
- 결제와 포인트 정비례 관계
➡️ 데이터 저장 순서: 데이터 저장 박스처리
1. 사용자 결제 요청 데이터 저장
2. 요청 데이터 확인 view (클라이언트 결제 진행)
3. 결제 API (success / fail 리다이렉트 Url) 요청
4. 사용자 결제 요청 금액 & 결제 API amount 일치 여부 확인
5. 결제 API 호출
6. 결제 승인 데이터 저장
7. 결제 상세내역 이벤트 로그 저장
8. 사용자 포인트 정보 업데이트
📌 정산 서비스
- 전자계약 체결 완료 후 정산 버튼 클릭
- 관리자 -> 사용자에게 계좌이체
➡️ 데이터 저장 순서: 데이터 저장 박스처리
1-1) 정산 대상 사용자 이메일을 포함한 관리자 정산 요청
1-2) 관리자 결제 고유 번호 생성
ADMIN-TRANSFER-현재시간-UUID
1-3) 정산 금액에서 18% 수수료 차감
1-4) 정산 데이터 저장
- 정산 요청 데이터 확인 view (클라이언트(관리자) 계좌이체 진행)
- 결제 API (success / fail 리다이렉트 Url) 요청
- 관리자 이체 요청 금액 & 결제 API amount 금액 일치 여부 확인
- 결제 API 호출 (계좌이체)
- 이제 승인 데이터 저장
- 결제 상세내역 이벤트 로그 저장(pointEventStatus : ADMIN-TRANSFER 저장하여 나중에 event 테이블에서 관리자 구분)
- 등록된 보증금 정산처리 계산 후 사용자 포인트 정보 업데이트
- 사용자 전체 보증금 - 예치된 보증금
- 사용자 전체 포인트 - 예치된 보증금
- 보증금 상세페이지 상태 변경
PENDING -> TRANSFER
📌예치금 서비스
- 기업 농산물 모집글) 모집 인원이 완료되어야 계약 진행 가능, 바로 결제하는 시스템이 아닌 보증금 예치 서비스를 제공하고 있습니다
- 기업이 농산물 모집글 작성 후 결제(포인트)를 통해 Deposit을 예치)
- 기업 입찰 참여시 진행 가능합니다
- 모집 실패 혹은 패찰된 경우 예치금 상태에서 포인트로 전환
➡️ 데이터 저장 순서
1. 모집 게시글 작성 완료 / 경매 입찰시 보증금 예치 신청
2. 사용자 잔여 포인트 & 보증금 요청 금액 비교
3. 사용자 보증금 요청 정보 저장
4. 사용자 포인트 테이블 업데이트
5. 게시글 활성화 상태 업데이트
1) 결제
📌 사용자 결제 요청(T)
토스 API 결제 요청전 결제 성공/실패 결과 여부 상관없이 사용자가 결제 요청한 로그 데이터를 남기기 위해서 결제와 사용자 결제 요청 테이블을 따로 설계 했습니다.
- 결제와 사용자 결제 요청 테이블을 하나로 설계할 경우의 문제점
- case1) 사용자 결제 요청 -> 결제 -> 요청 성공
- case2) 사용자 결제 요청 -> 실패 -> 결제 실패시 사용자 요청도 rollback ????
➡️ 데이터 저장이 되지 않는다
➡️ 사용자 결제 요청마저 알 수 없는 문제 발생
결제와 사용자결제요청 테이블을 따로 설계함으로써
사용자 결제 요청 -> 실패해도 로그 저장 -> 실패 확인 가능
게시글 고유 아이디의 경우UUID4를 사용하여 결제 요청마다 결제 고유 문자를 부여하도록 Varchar로 설계- 사용자: POST-사용자타입-요청일-UUID
- 관리자: ADMIN-I5E2-요청일-UUID
참여 게시글 타이틀을 게시글번호가 아닌 제목으로 한 이유는농가 경매글또는기업 모집글로 두가지로 index 번호가 겹쳐 데이터 혼동이 오는 상황이 존재합니다
따라서 결제 요청시 참여 게시글 타이틀로 작성하도록 하였습니다.
타이틀의 경우 긴 문장일 수 있기 때문에 검색 성능이 좋지 않을거라 생각하여- 게시글 등록 시 입력되는 PK 값을 varchar로 변경하고
게시글타입-번호로 변경하여 검색 시간을 줄일 수 있도록 리팩토링할 예정입니다.
- 게시글 등록 시 입력되는 PK 값을 varchar로 변경하고
📌 결제(T)
결제 테이블은 토스 API 요청하여 성공 시 결제 데이터를 필요한 내용만 추출하여 저장한 테이블입니다.
- 결제는 하나의 요청당 단 한번의 처리만 가능해야하기 때문에 사용자 결제 요청 테이블의 결제 요청 고유 번호를 가지고 있는
user_payment_order_id또는admin_payment_order_id컬럼과 외래키 참조를 했습니다.
2) 포인트
📌 사용자 포인트(T)
검증된 정회원만 포인트 사용이 가능하며,
검증 완료시유저 기본키/ 포인트 현재잔액 0원 /총 예치금 0원으로 포인트 테이블이 생성됩니다.
- 마이페이지에서 확인 가능한 테이블로 현재잔액과 총 예치금은 insert, update가 가능합니다.
📌 포인트 이벤트 로그(T)
결제, 정산으로인한 차감, 환불 등 사용자 포인트의 모든 이벤트가 등록되며 해당 테이블은 ㅕinsert, select이 외 update, delete가 불가능하도록 설계 했습니다
- insert, select만 가능한 테이블로 설계 했습니다
- 결제시 양수로 등록, 정산시 음수로 등록 됩니다.
3) 보증금
📌 예치금(보증금)(T)
예치금으로 테이블 명을 정한 이유는 모집 혹은 경매중에만 잠시 예치해 놓는 개념이기 때문에 예치금테이블로 명명했습니다.
예치금은 사용자 포인트 테이블과 일대다 관계로 예치해 놓은 포스트 아이디 값을 가지고 있습니다.
예치 상태는 Enum 타입으로 예치상태(PENDING), 정산완료(TRANSFER)로 서버에서 처리하여 넣어줍니다.모집참여/경매입찰 여부컬럼을 통해 모집/경매로 구분해줍니다.예치금소멸일은 정산시 소멸일이 저장됩니다
