Road to Web3 (16) 결제 시스템 비교: 카드 승인 매입 vs 온체인 정산

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

 

이번 편의 목표는 이 한 문장입니다.

• web2 결제의 승인 매입 정산 프레임으로 온체인 포함 확정 정산을 맵핑하면 제품 의사결정이 쉬워진다

 

온체인 결제를 아래와 같이 이해했었습니다.

• 블록에 들어가면 카드 결제의 승인 같은 것이다
• confirm은 정산 같은 것이다
• 온체인은 환불이 없으니 정책이 단순해진다

하지만 현실은 더 복잡합니다.

• 승인과 정산이 분리되는 문제는 web2도 web3도 동일하다
• 다만 web3는 실패 비용이 있고, 되돌림 reorg까지 고려해야 한다
• 환불과 분쟁이 사라지는 게 아니라 구현 레이어가 바뀐다

그래서 이 글은 결제 기획과 운영 언어로 체인을 번역합니다.

---

 

1) 카드 결제는 실제로 어떻게 굴러가나

상세 네트워크는 카드사와 국가마다 다르지만, 결제는 보통 이 단계로 이해합니다.

1) 승인 authorization
2) 매입 capture
3) 정산 settlement
4) 취소 환불 dispute refund

승인은 즉시 응답이 오지만, 정산은 지연될 수 있습니다.

• 승인은 빠른 UX
• 정산은 회계 확정

---

 

2) 온체인 결제는 어떤 단계로 보나

온체인도 단계를 나눠야 운영이 됩니다.

1) submitted: RPC에 제출됨
2) seen: 멤풀에서 관측됨
3) included: 블록에 포함됨
4) confirmed: k confirmations를 쌓음
5) finalized: 최종 확정 정책을 만족함
6) failed: 블록 포함 후 revert

이 단계는 서비스 레벨에서 의미가 다릅니다.

• included는 사용자 체감 성공
• confirmed는 제공 시작 기준으로 많이 쓰임
• finalized는 회계 확정 기준으로 많이 쓰임

---

 

3) 맵핑 테이블: 승인 매입 정산과 온체인 상태

여기서 핵심 테이블 하나로 정리합니다.

web2 결제 용어	의미	온체인 상태에 가까운 것	제품적으로 쓰는 기준
승인 authorization	결제 의사 확인, 한도 확보	included 또는 confirmed	빠른 UX, 서비스 제공 시작
매입 capture	실제 청구 확정, 취소 가능성 축소	confirmed가 더 쌓인 상태 또는 finalized 정책 직전	정산 파이프라인 시작
정산 settlement	회계 확정, 대금 수령	finalized	회계 확정, 권리 확정
취소 refund	거래 되돌림	onchain refund tx 또는 오프체인 보상	정책과 비용의 문제

주의

• 이 맵핑은 1대1이 아니라 의사결정 프레임입니다
• 온체인은 승인과 매입을 한 트랜잭션으로 묶어버릴 수도 있고, L2는 다시 승인과 정산이 2층이 됩니다

---

 

4) 제품 의사결정 프레임: 언제 제공하고 언제 확정할까

결제 제품에서 항상 부딪히는 질문

• 결제 완료 문구를 언제 띄울까
• 재시도 버튼을 언제 보여줄까
• 서비스 제공을 언제 시작할까
• 환불 정책은 어떻게 할까

온체인을 결제 프레임으로 보면 이렇게 나뉩니다.

4.1 UX 성공 기준

• included 또는 confirmed k
• 사용자에게는 지금 처리 중이라는 상태와 ETA를 보여준다

4.2 서비스 제공 기준

• confirmed k 또는 L2 included + 위험 점수
• 고액, 고위험은 finalized까지 보수적으로 기다린다

4.3 회계 확정 기준

• finalized
• 매출 인식, 정산 보고, 회계 마감은 이 기준으로 고정한다

web2와 같은 결론

• 승인으로 UX를 만든다
• 정산으로 회계를 고정한다

---

 

5) web3에서 달라지는 지점 5개

5.1 실패 비용이 있다

• 카드 승인은 실패해도 비용이 0에 가까운 경우가 많다
• 온체인은 revert도 가스를 소비한다

5.2 되돌림 리스크가 있다

• 카드도 승인 취소, 차지백이 있다
• 체인은 확정 전 reorg로 되돌아갈 수 있다

5.3 환불은 트랜잭션이다

• 카드 환불은 네트워크가 처리해준다
• 온체인 환불은 내가 트랜잭션을 만들어야 한다

5.4 결제 수단과 수수료 자산이 분리될 수 있다

• USDC가 있어도 ETH가 없으면 전송이 막힌다

5.5 운영 의존성이 RPC와 네트워크다

• PG 장애가 서비스 장애가 되듯이
• RPC와 네트워크 혼잡이 곧 결제 장애다

---

 

6) 체크리스트

1) 결제 완료라는 문구를 included에서 쓰지 않는다
2) included confirmed finalized를 제품 상태로 분리한다
3) CS 스크립트도 상태별로 분리한다
4) 고액 거래는 확정 깊이를 더 보수적으로 잡는다
5) 멱등성 키로 중복 제공과 중복 청구를 막는다
6) 재시도는 비용이 든다는 점을 UX에 반영한다
7) 실패 원인별로 재시도 전략을 분리한다
8) 환불은 트랜잭션이라는 점을 운영 비용으로 잡는다
9) 정산 파이프라인을 별도로 둔다
10) 오프체인 원장과 온체인 상태를 리컨실한다
11) explorer 지연과 RPC 지연을 구분한다
12) pending과 dropped를 구분해 안내한다
13) nonce와 replacement를 운영으로 다룬다
14) L2는 소프트 확정과 하드 확정을 분리한다
15) 체인별 수수료 자산을 준비시킨다
16) 인덱서는 reorg를 전제로 설계한다
17) 장애 시 degraded mode를 설계한다
18) 대시보드에 lag와 확정 단계 분포를 띄운다
19) 수수료 급등 시 정책을 문서화한다
20) 분쟁과 보상 프로세스를 제품에 포함한다

---

 

결론

• 전통 결제의 승인 정산 프레임은 온체인에도 그대로 먹힌다
• 차이는 구현 디테일 실패 비용 되돌림 환불 트랜잭션에 있다
• 제품은 상태 머신과 정책으로 신뢰와 UX를 동시에 만든다