1) 먼저 결론: 스테이블(USDT/USDC)을 베이스로, BTC/ETH는 옵션으로 설계

iGaming 결제에서 분쟁이 커지는 지점은 보통 두 가지입니다.
첫째는 “가격 변동(환율/시세)”이고, 둘째는 “입금 지연(혼잡/컨펌/수수료)”입니다.
BTC/ETH는 글로벌 인지도와 브랜드 신뢰에 강점이 있지만, 변동성이 높아
보너스/캐시백/정산 리포트에 환율 리스크가 들어올 수 있습니다.
반면 스테이블코인은 기준 통화(달러)에 가까운 성격이라 운영이 단순해집니다.

지원 자산 정책은 “결제” 문서와 함께 움직입니다.
전체 결제 구조는 Crypto Payment에서,
실제 운영 흐름(입금/출금/보류/승인)은 Deposit & Withdrawal에서 먼저 고정하는 것이 안전합니다.

2) Supported Assets 표기 규칙(필수): “코인 + 네트워크 + 수수료 + SLA + 컨펌” 한 줄 고정

Supported Assets 페이지가 약하면 결제 화면에서 유저가 “어떻게 보내야 하는지”를 이해하지 못합니다.
그래서 목록은 단순 나열이 아니라, 최소한 아래 정보를 한 줄 템플릿으로 고정해야 합니다.
형식이 고정되면 CS는 같은 문장으로 안내할 수 있고, 운영팀은 장애 공지를 빠르게 만들 수 있습니다.

1. 코인명 (예: USDT)
2. 네트워크 (예: ERC-20 / TRC-20 등)
3. 수수료 정책 (누가 부담? 유저/사업자/혼합)
4. 예상 반영 시간(SLA) (컨펌 기준 포함)
5. 컨펌(Confirmations) (정책 고정 + 상태 표시)

[USDT] Network: (ERC/TRC/...)  Fee: (user/company/mixed)  SLA: (range)  Confirmations: (N)
[USDC] Network: (ERC/...)      Fee: (user/company/mixed)  SLA: (range)  Confirmations: (N)
[BTC ] Network: Bitcoin        Fee: (user/company/mixed)  SLA: (range)  Confirmations: (N)
[ETH ] Network: Ethereum       Fee: (user/company/mixed)  SLA: (range)  Confirmations: (N)

실제 컨펌 수(N)와 SLA는 운영 정책에 따라 달라질 수 있지만,
표기 형식은 고정되어야 합니다. 형식이 흔들리면 유저도 흔들리고 CS도 흔들립니다.
지갑 연동 기준은 Wallet Integration에서,
입금 반영/출금 승인 기준은 Deposit & Withdrawal에서 함께 문서화하세요.

3) 런칭 초기에 권장되는 지원 자산 구성(실전 기준)

지원 코인을 늘리는 것은 매출 기회만 늘리는 것이 아니라,
운영 비용(CS/리스크/정산)도 함께 늘리는 선택입니다.
따라서 초기에는 “운영 가능한 범위”를 먼저 고정하고,
안정화 후 트래픽/티켓 데이터를 보고 확장하는 방식이 가장 안전합니다.

확장 설계는 결제 문서만의 문제가 아니라 플랫폼 확장성과도 연결됩니다.
트래픽 증가/장애 분리 관점은 Scalability,
보안/권한/감사 로그는 Security 문서와 함께 점검하는 것이 좋습니다.

4) 네트워크(체인) 혼동 사고를 줄이는 9가지 UX 규칙(실무 체크리스트)

Supported Assets 페이지가 존재하는 가장 현실적인 이유는,
유저가 네트워크를 잘못 선택해 “입금이 누락된 것처럼 보이는” 상황을 줄이기 위해서입니다.
아래 규칙은 운영 현장에서 티켓을 가장 빠르게 줄이는 방식으로 검증된 항목들입니다.

1. 코인보다 네트워크를 먼저 보여준다(상단 라벨/고정)
2. 주소 + QR + 네트워크 라벨을 한 화면에 묶는다
3. 네트워크 변경 시 “주소가 바뀜” 경고 문구를 즉시 노출
4. 최소 입금액 미만은 반영되지 않을 수 있음을 표기(굵게)
5. 입금 후 TXID(트랜잭션 ID) 제출 경로를 제공
6. 상태 표시(Processing/Confirmed)를 명확히 구분
7. 혼잡 시 공지 템플릿(혼잡/지연/점검)을 미리 준비
8. 사용자에게 “잘못된 네트워크 선택 시 확인이 지연될 수 있음”을 동의 문구로 남긴다
9. CS 동선은 Contact로 단일화(스크린샷/ TXID / 시간 포함 안내)

TXID 기반 추적과 “입금 반영 기준”은 Deposit & Withdrawal 문서와 직접 연결됩니다.
UX 규칙을 지키면 많은 사고가 “기술 문제”가 아니라 “설명 비용”으로 바뀌고,
CS 응대 시간과 분쟁 발생률이 내려갑니다.

5) 컨펌(Confirmations) 기준은 “기술”이 아니라 “운영 정책”이다

컨펌 기준은 운영팀이 반드시 문서로 고정해야 하는 항목입니다.
너무 낮게 잡으면 리버설/재조정 리스크가 커지고,
너무 높게 잡으면 반영 지연으로 이탈이 발생할 수 있습니다.
중요한 것은 “정답 컨펌 수” 자체가 아니라,
기준이 고정되어 있고, 일관되게 안내되는가입니다.

컨펌/반영/보류/승인 정책은 결제 운영 문서로 이어져야 합니다.
실무 워크플로우는 Deposit & Withdrawal에서 먼저 고정하세요.

6) 최소·최대 금액, 수수료, 환율 표기: 분쟁을 줄이는 “문장”이 필요하다

분쟁으로 가장 자주 번지는 이슈는 “최소 입금액 미만”과 “수수료 오해”입니다.
그래서 Supported Assets 페이지에는 자산별 최소/최대 금액, 수수료 부담 주체를
짧고 강하게 표기해야 합니다.
이 규칙은 결제 UI에도 그대로 반영되어야 하고, 운영팀이 바꾸면 문구와 FAQ도 함께 바뀌어야 합니다.

• 최소 입금액: 소액 스팸/수수료 대비를 고려해 설정(미만 입금 처리 방침을 명확히)
• 최대 입금액: 리스크/컴플라이언스/운영 한도 고려(고액 구간은 별도 검증 흐름 가능)
• 수수료 부담: 유저/사업자/혼합을 명확히(혼합이면 예시 문장 포함)
• 환율 표기: 스테이블 기준 정산이면 “정산 기준 시점”을 명시

이 정책들은 컴플라이언스/리스크 문서와 함께 정리되어야 일관성이 생깁니다.
운영 준수 항목은 Compliance와 연결해 문서 구조를 맞추고,
파트너 협업/정산 범위는 Partnership에서 “책임 범위”를 명확히 하는 것이 좋습니다.

7) 운영 관점에서 반드시 보는 KPI(자산/네트워크별 분리)

코인을 추가하면 매출 기회는 늘 수 있지만, 문제도 같이 늘 수 있습니다.
따라서 Supported Assets 확장을 고민한다면 “감”이 아니라
자산/네트워크별로 아래 지표를 분리해 보는 습관이 필요합니다.
그래야 특정 코인/체인에서만 반복되는 지연/혼동/티켓 폭증을 빠르게 잡을 수 있습니다.

이런 운영 지표가 의미 있으려면 보안/권한/로그가 받쳐줘야 합니다.
관리자 접근과 감사 로그 기준은 Security에서,
전체 플랫폼 개요는 Platform에서 함께 점검하세요.

8) 자주 발생하는 문제 FAQ(지원 자산 관점)

Q1. 같은 USDT인데 왜 입금 주소가 다르죠?

USDT는 “코인 이름”이고, 실제 전송은 “네트워크(체인)” 위에서 일어납니다.
네트워크가 다르면 주소 형식과 전송 경로가 달라질 수 있습니다.
그래서 PowerChain은 결제 화면에서 코인/네트워크를 분리해서 안내하고,
Supported Assets 문서에서도 동일한 규칙으로 표기합니다.

Q2. 입금했는데 바로 반영이 안 됩니다.

대부분 네트워크 혼잡 또는 컨펌 미충족 상태입니다.
“반영이 안 됨”이 아니라 “진행 중(Processing)”으로 표시되는지 먼저 확인하세요.
TXID(트랜잭션 ID)를 제출하면 확인이 빨라지며,
반영 기준/상태 표시는 Deposit & Withdrawal에서 상세히 다룹니다.

Q3. 지원 자산을 늘리면 매출이 무조건 늘까요?

늘 수도 있지만, 동시에 운영 비용(CS/리스크/정산)이 늘어납니다.
특히 네트워크가 늘수록 혼동 사고가 늘 가능성이 커집니다.
그래서 확장은 “요구가 많은 코인”보다 “지원해도 안전한 구성”부터 단계적으로 진행하는 것이 좋습니다.
더 깊은 기술 통합은 API Integration에서 확인하세요.

9) 운영팀/CS용 안내 문구 템플릿(복붙용)

아래 문구는 Supported Assets 페이지와 결제 화면에 함께 넣는 것을 권장합니다.
핵심은 “짧고, 같은 문장으로, 항상 같은 위치에”입니다.
문구가 통일되면 CS가 흔들리지 않고, 유저가 스크린샷을 보내도 담당자가 즉시 판단할 수 있습니다.

• 네트워크 확인: 코인과 네트워크를 반드시 일치시키세요. 네트워크가 다르면 입금 확인이 지연될 수 있습니다.
• 최소 입금액: 최소 금액 미만 입금은 자동 반영되지 않을 수 있으며, 네트워크 수수료는 별도로 발생합니다.
• 처리 시간: 네트워크 혼잡에 따라 반영 시간이 늘어날 수 있습니다. “Processing”이면 정상 진행 중입니다.
• TXID 제출: 반영이 지연될 경우 TXID(트랜잭션 ID)와 입금 시간/금액을 함께 제출하면 확인이 빠릅니다.
• 문의 동선: 확인이 필요한 경우 Contact로 문의해 주세요(스크린샷/ TXID 포함 권장).

출금 보류/심사 기준처럼 민감한 항목은 컴플라이언스 정책과 함께 문서화되어야 일관성이 생깁니다.
내부 기준은 Compliance와 연결해 운영 문서 구조를 맞추는 것을 권장합니다.

10) 런칭 전 체크리스트(지원 자산 페이지 기준)

1. 각 자산에 대해 코인명·네트워크·수수료·SLA·컨펌 기준이 “한 줄”로 보이는가
2. 네트워크 변경 시 주소가 바뀐다는 경고 문구가 명확히 노출되는가
3. 최소 입금액·최대 입금액이 눈에 띄게 표기되어 있는가
4. Processing/Confirmed 상태가 사용자에게 이해되도록 설명되어 있는가
5. TXID 제출 경로와 문의 동선이 Contact로 단일화되어 있는가
6. 운영팀이 장애 공지를 작성할 때 “같은 문장”으로 대응할 수 있는 템플릿이 준비되어 있는가
7. 자산/네트워크별 KPI(지연·미스매치·티켓)를 분리해 볼 수 있는 기준이 있는가

위 항목을 지키면 Supported Assets 페이지는 “기능 소개”가 아니라 “운영 문서”가 됩니다.
이 문서는 허브(Crypto Payment) 다음으로
실제 운영자가 자주 확인하는 기준 문서이므로, 문구의 정확성과 일관성이 곧 신뢰도입니다.