운영 모델 · 데이터 모델
시스템을
떠받치는 테이블
코드 생애주기·정산·온보딩·부정방지가 실제로 어떤 데이터 구조 위에서 돌아가는지 정의합니다. 사이트 개발의 출발점입니다.
설계 원칙은 하나 — 모든 코드는 거치처에 매핑되고, 모든 상태 변화는 로그로 남는다. 역추적·감사·클로백이 데이터 구조 자체에서 보장됩니다.
엔티티 관계
파트너가 거치처를 등록하고, 코드는 묶음 케이스(batch) 단위로 거치처에 매핑됩니다. 파트너는 낱장이 아니라 케이스 대표 QR 하나로 그 배치 전체를 거치처에 등록하고, 본사가 배치를 승인하면 그 안의 코드가 일괄 활성화됩니다. 코드는 전환·정산·상태로그와 연결되어 — 어떤 전환·지급이든 배치 → 거치처 → 파트너까지 역추적됩니다.
핵심 테이블 스키마
venue거치처온보딩·승인 단위
idPKuuid거치처 식별자
partner_idFKuuid등록 파트너
statusenumapplied·verified·approved·active·suspended
categoryenum성인숍·무인숍·이벤트 등 (성인 전용 근거)
geopoint위치(검증·신고 대조용)
verified_atts본사 승인 시각 (null=미승인)
batch묶음 케이스등록·활성화 단위
idPKuuid배치 식별자
case_qrcharUNIQUE케이스 대표 QR/배치번호 (파트너가 이걸로 등록)
venue_idFKuuid비치된 거치처 (등록 시 매핑, null=미배치)
qtyint케이스 내 카드 수 (예: 100매)
stateenumprinted·registered·active·suspended (배치 일괄 상태)
code쿠폰 코드사업의 심장
idPKuuid코드 식별자
code_hashcharUNIQUE코드 해시(원문 비저장)
batch_idFKuuidIDX소속 묶음 케이스 (배치로 일괄 활성화)
venue_idFKuuidIDX발급 거치처 매핑(배치 통해 상속, 역추적 핵심)
stateenumissued·inactive·active·suspended·redeemed
activated_atts본사 활성화 시각 (null=정산 0)
redeemed_byuuid사용한 신규 가입자 (1코드=1가입)
conversion전환정산의 입력
idPKuuid전환 식별자
code_idFKuuid전환을 만든 코드
typeenumsignup·payment (가입/결제 구분)
amountint결제 금액 (payment일 때)
validbool취소·환불·중복 시 false → 정산 제외
settlement정산CPA 지급
idPKuuid정산 식별자
conversion_idFKuuid근거 전환
payee_typeenumvenue·partner (거치처 CPA / 파트너 CPA)
gross / tax / netint총액·원천징수·실지급
statusenumpending·held·paid·clawed_back
code_event상태 로그감사·역추적
idPKbigint이벤트 일련번호
code_idFKuuidIDX대상 코드
from / toenum상태 전이 (예: inactive→active)
actorenum전이 주체 (본사·파트너·시스템)
reason · attext·ts사유·시각 (감사 근거, 불변 append-only)
설계 포인트
코드 원문은 저장하지 않습니다 — 해시만 보관해 유출 시에도 코드를 복원할 수 없습니다. 상태 로그(code_event)는 append-only로 쌓여 감사·클로백의 변조 불가능한 근거가 됩니다.
본 스키마는 설계안이며 컬럼·인덱스·정규화 수준은 구현 단계에서 확정합니다. 개인정보(가입자·결제) 취급은 일본 개인정보보호법, 보존 기간은 세무·감사 요건에 맞춰 설계합니다.