거래소 수수료 페이백 정산 콘솔

사용자 대시보드

거래소 UID 연동 상태 · 누적 페이백/거래대금 통계 · 거래내역 · 출금 신청. (표시 회원: 가상 계정 김하늘 · M001)

거래소별 페이백 요율 안내

※ 요율은 가상 예시값입니다.

UID 연동 3단계 가이드

1거래소 가입본 서비스의 파트너 레퍼럴 링크로 거래소에 가입해야 수수료 리베이트가 이 서비스로 귀속됩니다. 기존 계정은 귀속이 제한될 수 있어 "UID 연동·인증" 탭에서 먼저 확인합니다.

2UID 등록·본인인증거래소에서 발급한 UID를 입력하고 이메일 인증으로 본인을 확인합니다. 형식 검증과 레퍼럴 귀속 확인을 통과하면 매칭 대기로 등록됩니다.

3자동 정산·출금파트너 API/CSV로 수집된 수수료가 회원 매칭을 거쳐 페이백으로 적립되고, 지갑주소를 등록해 출금을 신청하면 관리자 검토 후 지급됩니다.

거래소 UID 연동 상태

누적 페이백 통계

페이백(USDT) 거래대금(USDT, 우축)

예시 누적 추이 · 표시 회원(김하늘) 기준

요약

누적 페이백

— USDT

누적 거래대금

— USDT

연동 거래소

— / 5

출금 가능 잔액

— USDT

거래내역 요약

거래소	정산기간	거래대금	수수료	페이백	정산상태

출금 신청

환급 네트워크 / 지갑주소

지갑주소를 입력하세요.

출금 금액 (USDT)

신청은 상태 대기로 접수되어 관리자 검토 후 승인/반려/완료 처리됩니다.

출금 처리 상태

신청일시	금액	네트워크	상태

관리자 정산 콘솔

거래소 API 목업 응답 수신 → 회원 매칭 → 멱등 정산. 멱등키 = (거래소, 회원UID, 정산기간) unique. 재수집·CSV 폴백이 같은 키 규칙을 타서 중복지급이 0임을 실제로 시연합니다.

정산 레코드

0 건

총 페이백

0.00 USDT

중복 차단 (멱등)

0 건

미매칭 UID

0 건

거래소 API 응답 실패 수수료 데이터 수동 업로드 폴백 (CSV)

API 장애·거래소 정책 변경 시 운영자가 CSV로 수수료 데이터를 올립니다. CSV분도 동일 멱등키 규칙을 타므로 API 재개 후 겹쳐도 이중지급되지 않습니다. (파일 업로드는 브라우저 내에서만 처리 — 외부 전송 없음. 실서비스에서는 엑셀 .xlsx도 동일 파서 계층으로 흡수)

정산 원장 상태머신

수집완료 0

→

검증완료 0

→

지급대기 0

→

지급완료 0

거래소	회원	UID	기간	거래대금	수수료	요율	페이백	소스	멱등키	상태
거래소 API 수집을 실행하세요.

[준비] "거래소 API 수집" 버튼으로 시작합니다.

UID 연동·본인인증

거래소 선택 → UID 입력·형식 검증 → 이메일 본인인증(목업) → 레퍼럴 귀속 확인 → 매칭 결과. 공고의 "사용자 UID 입력 → 본인 인증 → 매칭 결과 출력" 흐름을 실제로 눌러 볼 수 있습니다.

1 거래소

2 UID

3 본인인증

4 매칭 결과

① 거래소 선택

② UID 입력

거래소 UID 기존에 다른 경로로 이미 가입해 UID를 보유하고 있음

③ 이메일 본인인증 목업

실제 서비스에서는 회원 이메일로 일회용 코드를 발송합니다. 이 콘솔에서는 발송 코드가 화면에 표시됩니다.

— — — — — —

④ 매칭 결과

거래소·UID·본인인증을 마치면 레퍼럴 귀속 판정 결과가 표시됩니다.

회원 관리

회원 정보 · 거래소별 UID 등록현황 · 매칭 상태를 조회·필터하고, 행을 눌러 상세를 봅니다. (모든 회원·UID는 가상 데이터)

전체 회원

0 명

UID 등록

0 건

매칭완료

0 건

승인대기·거부

0 건

회원ID	이름	가입일	KYC	연동 거래소	UID	매칭상태

출금 관리

회원 출금 신청을 검토해 승인·반려하고 지급을 완료 처리합니다. 상태 전이: 대기 → 승인 → 완료, 또는 대기 → 반려(사유). (가상 신청·지갑주소)

대기

0 건

승인(지급 전)

0 건

지급완료

0 건

누적 지급액

0.00 USDT

신청ID	회원	금액	네트워크	지갑주소	신청일시	상태	처리

[준비] 대기 중인 출금 신청을 승인/반려하세요.

정산 통계 대시보드

관리자 정산 콘솔 원장과 실시간 연동됩니다 — 수집 전에는 API 초기 배치(5개 거래소 · 2026-W28) 스냅샷을, 수집·CSV 병합 후에는 라이브 원장을 동일 규칙(어댑터·멱등키)으로 집계합니다. 출금 지표는 출금 관리와 연동됩니다.

총 정산 페이백

—

5개 거래소 · 15건 수집

매칭 지급대상

—

회원 매칭 통과분

미매칭 보류

—

지급 차단(무결성 가드)

이번주 지급완료

—

출금 관리 완료분

거래소별 페이백 분포

기간별 정산 추이 (주간)

페이백(USDT) 거래대금(우축)

※ 추이는 예시 시계열입니다(상단 KPI는 이번 배치 스냅샷 기준).

출금 상태 분포

거래소별 정산 요약

거래소	요율	건수	수수료	페이백

감사 로그 (audit_log)

정산·출금·회원 매칭의 모든 상태 변경을 append-only로 기록합니다 — 누가·언제·무엇을 바꿨는지 되짚어 데이터 무결성과 추적성을 보장합니다. 다른 탭에서 정산 상태를 전이하거나 출금을 승인하면 여기에 즉시 append됩니다. (총 0건 · 가상)

시각	유형	대상	액션	행위자	상세

수집·정산 아키텍처

API 호출 수를 사용자 수가 아니라 (거래소 수 × 폴링주기)로 고정하는 마스터계정 배치 수집 + 거래소별 워커 큐 + rate limit 동시성 제어 + 멱등 UPSERT + append-only 원장.

① 마스터계정 배치 수집 — 사용자별 개별 폴링이 아니라 거래소 제휴/브로커 마스터 계정 단위로 affiliate-user-list를 페이지네이션 조회. 호출 수 = 거래소 수 × 폴링주기(예 5~15분)로 상수화되어 사용자 급증과 무관.

② 거래소별 워커 큐 — 거래소마다 인증방식·응답스키마·레이트리밋이 달라 어댑터 패턴으로 분리하고, 거래소별 독립 큐/워커로 장애를 격리(한 거래소 429가 전체 정산을 멈추지 않음).

③ Rate limit 동시성 제어 — Binance는 IP당 weight 예산, Bybit는 IP당 5초/600건 등 상한이 제각각. 거래소별 토큰버킷/세마포어로 동시성을 상한 이하로 유지하고, 429/418 시 지수 백오프 + 지터로 재시도.

④ 어댑터 정규화 — 거래소별 원시 응답(필드명·수수료 단위·소수점·타임스탬프 형식 상이)을 공통 정산 모델로 정규화. maker/taker 분리 수수료 합산, epoch→정산기간 변환, 소수점 반올림 통일.

⑤ 멱등 UPSERT — 정산 레코드는 (거래소, 회원UID, 정산기간) unique 제약. 재수집·재처리·CSV 폴백이 겹쳐도 UPSERT만 일어나 중복 지급이 원천 차단(이 콘솔의 관리자 화면에서 실제로 시연).

⑥ Append-only 원장 + 상태머신 — 수집완료→검증완료→지급대기→지급완료로만 전이하는 append-only 정산 원장. 미매칭·검증 실패는 지급 단계로 넘어가지 못하게 막아 데이터 무결성 확보.

데이터 모델 (ERD)

정산 무결성의 핵심은 settlement_ledger의 UNIQUE(exchange, member_uid, period) 제약입니다 — 재수집·CSV 폴백이 겹쳐도 이 제약이 중복 정산을 DB 레벨에서 원천 차단합니다.

members 회원

PKmember_idvarchar

namevarchar

kyc_statusenum

joined_attimestamptz

exchange_accounts UID 등록

PKaccount_idbigint

FKmember_id→ members

UKexchangevarchar

UKuidvarchar

statusenum

UNIQUE(exchange, uid) — 한 UID는 한 회원에만 귀속

settlement_ledger 정산 원장

PKledger_idbigint

UKexchangevarchar

UKmember_uidvarchar

UKperiodvarchar

fee · rate · paybacknumeric

source · stateenum

UNIQUE(exchange, member_uid, period) = 멱등키 → 중복지급 0

withdrawals 출금

PKwithdrawal_idvarchar

FKmember_id→ members

amount · networknumeric

state · reasonenum

requested_attimestamptz

audit_log 감사 로그

PKaudit_idbigint

entity · entity_idvarchar

action · actorvarchar

attimestamptz

append-only — 정산·출금 상태 변경 추적

관계: members 1—N exchange_accounts · exchange_accounts.uid → settlement_ledger.member_uid(매칭) · members 1—N withdrawals. 정산 원장과 출금은 덮어쓰지 않고 상태만 전이하며, 모든 상태 변경은 audit_log에 append됩니다.

정산 원장 상태 전이

수집완료 API·CSV 정규화 후 적재

→

검증완료 회원 매칭·금액 검증

→

지급대기 지급 승인 큐

→

지급완료 append 기록

미매칭 UID·검증 실패 레코드는 검증완료로 넘어가지 못하고 수집완료에 잔류합니다(지급 차단 = 무결성 가드). 재수집이 이미 지급완료된 레코드를 만나도 멱등 UPSERT라 상태를 되돌리지 않습니다.

거래소별 연동 규격 대조 (어댑터 설계 근거)

거래소	파트너/인증	응답 스키마 특징	수수료 단위	Rate limit(공개 기준)
Binance	Api-Agent(apiAgentCode)	payload[].customerId·feeUsdt	USDT 문자열	IP당 weight 예산제(초과 시 429/418)
Bybit	Affiliate(API key+마스터 UID)	result.list[].maker/takerFee	maker/taker 분리 → 합산	기본 IP당 5초 / 600건
OKX	파트너/브로커 (구현 가정)	data[].commission·ts(epoch ms)	USDT · epoch→기간 변환	엔드포인트별 요청 상한
Bitget	파트너 (구현 가정)	data[].feeCents(정수)	센트(1/100) → USDT	엔드포인트별 요청 상한
Gate	파트너 (구현 가정)	data.list[].fee.amount(중첩)	중첩 객체 → amount 추출	엔드포인트별 요청 상한

Binance Api-Agent·Bybit Affiliate의 파트너 전제·Rate limit(IP weight·5초/600건)은 공개 문서 기준이고, OKX·Bitget·Gate 행의 파트너 구조·응답 스키마·수수료 단위는 이 구현의 목업 어댑터가 정규화하는 예시 형태입니다(실제 규격은 각 거래소 파트너 문서 확인 필요). 거래소마다 인증·필드명·수수료 단위·타임스탬프·호출 한도가 달라, 정산 로직이 거래소를 가리지 않도록 어댑터 계층에서 공통 정산 모델 {exchange, uid, period, volume, fee}로 정규화합니다.