Road to Web3 (23) 토큰 이코노미 정책: 수수료 환불 차지백 부재를 제품에 반영

이 글은 EVM 계열을 기준으로 설명합니다.

 

목표는 토큰 가격 얘기가 아니라, 결제와 정산 정책을 제품 언어로 번역하는 것입니다.
web2 결제 개발자가 온체인 결제를 붙일 때 가장 크게 부딪히는 구간이 바로 여기입니다.

0) 요약

• 온체인 결제는 승인과 정산이 하나로 붙어 있고, 되돌리기와 차지백이 기본 기능이 아니다
• 그래서 환불, 수수료, 분쟁 처리를 제품이 직접 설계해야 한다

---

 

1) 수수료는 누가 내나: 고객, 가맹점, 프로토콜

web2 결제에서는 수수료 구조가 어느 정도 표준화되어 있습니다.
하지만 온체인에서는 수수료가 두 갈래로 분해됩니다.

• 네트워크 수수료: 블록 공간과 실행 자원 비용
• 서비스 수수료: 제품이 부과하는 플랫폼 또는 사용료

즉, 결제 1건의 비용은

• 프로토콜 비용 + 서비스 비용

입니다.

그리고 중요한 차이가 있습니다.

• 프로토콜 비용은 실패해도 발생할 수 있다
• 서비스 비용은 정책에 따라 환불 가능하다

 

---

 

2) 환불은 어떻게 정의되나: 되돌리기와 별개다

여기서 제가 처음 web3를 접할 때 했던 오해는 이렇습니다.

• 환불은 결제 트랜잭션을 되돌리는 것이라고 생각했다

하지만 온체인에서는 일반적으로 직렬화 되어있기 때문에

• 되돌리기 rollback 라는 개념이 아니라
• 별도의 반대 방향 트랜잭션을 만드는 것

이 환불입니다.

즉, 환불은 보통

• 환불 트랜잭션이라는 새 결제

입니다.

그래서 환불을 설계하려면 다음이 필요합니다.

• 환불 가능한 조건과 기간
• 환불 시 수수료 부담 주체
• 환불 주소가 동일한지 여부
• 환불이 부분 환불인지 전체 환불인지
• 환불이 자동인지 수동인지

web2 비유로는

• 승인 취소가 아니라 매입 취소 또는 환불 전표를 새로 발행하는 것

에 더 가깝습니다.

---

 

3) 차지백이 없다는 말의 진짜 의미

차지백은 단순 환불이 아닙니다.
차지백은

• 네트워크나 카드사 같은 상위 권위가 개입해서
• 거래를 강제로 뒤집고
• 분쟁을 중재하는 절차

입니다.

온체인 결제에서 흔히 말하는 차지백 부재는

• 상위 권위가 강제로 뒤집어 주는 채널이 기본으로 없다

는 뜻입니다.

그래서 분쟁 처리 방식은 보통 3개로 갈립니다.

1) 제품이 환불 권한을 가진다

• 고객지원과 정책으로 해결

2) 에스크로 또는 분쟁 컨트랙트를 쓴다

• 조건 충족 시 자동 분배
• 또는 중재자 역할을 컨트랙트로 모델링

3) 아예 비가역 결제로 간다

• 디지털 재화나 즉시 제공 서비스에 더 적합

제품 정책 질문

• 분쟁이 났을 때 누가 판정자 역할을 하는가
• 제공이 끝난 서비스는 환불 가능한가
• 사기 거래를 어떻게 탐지하고 차단할 것인가

---

 

4) 토큰 경제는 가격이 아니라 상태 머신이다

토큰 이코노미라는 단어가 나오면 가격과 투자 얘기로 빠지기 쉽습니다.
하지만 제품 입장에서는 이게 더 중요합니다.

• 토큰은 결제 수단인 동시에, 상태와 권한을 표현하는 매개체가 될 수 있다

예를 들어

• 구독권 토큰: 보유하면 기능 접근
• 크레딧 토큰: 소모하면 사용량 차감
• 스테이킹: 예치하면 보상 또는 신뢰 점수

즉, 토큰은

• 요금제 데이터 모델

로 쓰일 수 있습니다.

web2에서는 이 역할을 보통

• 포인트
• 쿠폰
• 구독 상태
• 크레딧 잔액

이 담당합니다.

온체인에서는 이것이

• 공개 검증 가능한 상태

로도 구현될 수 있다는 차이가 있습니다.

---

 

5) 제품 설계 프레임: 결제 정책을 문장으로 고정하기

여기부터가 실무적으로 가장 유용합니다.
정책을 코드보다 먼저 문장으로 고정해야 합니다.

아래 질문에 답하면 제품 정책이 거의 완성됩니다.

5.1. 비용

• 가스비는 사용자, 서비스, 또는 분담 중 누구인가
• 실패 가스비를 보조할 것인가
• 서비스 수수료는 고정인가 비율인가

5.2. 환불

• 환불 가능 기간은 얼마인가
• 환불 시 가스비 부담은 누구인가
• 환불 주소는 원 결제 주소로 고정할 것인가
• 부분 환불을 허용할 것인가

5.3. 분쟁

• 차지백이 없으니 분쟁은 어디서 처리하나
• 에스크로가 필요한가
• 사기 거래는 어떤 기준으로 차단하나

5.4. 확정

• 몇 confirmations 이후 제공할 것인가
• L2라면 소프트 확정과 하드 확정을 어떻게 다룰 것인가

---

 

6) 실전 예시: 결제 서비스에 바로 넣을 수 있는 정책

아래는 제품 문서나 고객지원 문구로 바로 쓸 수 있는 형태입니다.

• 결제는 블록 포함 이후 처리되며, 서비스 제공은 N confirmations 이후 시작됩니다
• 결제 실패 시 네트워크 수수료는 환불되지 않을 수 있습니다
• 환불은 별도의 환불 트랜잭션으로 처리되며, 환불 수수료는 정책에 따릅니다
• 분쟁은 온체인 차지백이 아니라 고객지원 절차로 처리됩니다
• 의심 거래는 자동 보류되며 추가 확인 후 처리됩니다

---

 

7) 결론

• 온체인 결제는 승인과 정산이 한 번에 커밋되는 구조에 가깝다
• 차지백 부재는 기술 문제가 아니라 제품 정책이 떠안는 책임이다
• 토큰 이코노미는 가격이 아니라 상태 머신으로 설계해야 한다