스테이블코인 결제 게이트웨이 아키텍처

아키텍처 개요:

스테이블코인 결제 게이트웨이에는 (1) 결제별로 예금 주소를 생성하고 관리하는 결제 의도 레이어, (2) 블록체인에서 들어오는 이체를 감시하는 체인 모니터링 레이어, (3) 영수증을 확인하고 이벤트를 트리거하는 확인 엔진, (4) 모든 결제 상태를 기록하는 원장, (5) 오프 램프 및 자금 관리를 처리하는 결제 레이어 등 5개의 핵심 레이어가 있습니다.

이 가이드는 프로덕션 스테이블 코인 게이트웨이 뒤에 있는 시스템 설계에 중점을 두고 있습니다. 즉, 존재하는 구성 요소뿐만 아니라 구성 요소가 연결되는 방식, 오류가 발생하는 위치, 규모에 따른 안정성에 중요한 설계 결정에 중점을 둡니다.

결제 의도 레이어

지불인이 지불을 시작할 때 지불 의도가 생성됩니다. 여기에는 예상 금액, 스테이블 코인 및 체인, 할당된 입금 주소, 만료 시간, 다운스트림 주문 또는 송장 참조가 저장됩니다.

입금 주소 추출

입금 주소는 BIP-44를 사용하여 HD 지갑에서 파생됩니다. 마스터 시드는 비밀 관리자(AWS Secrets Manager, Vault)에 저장됩니다. 각 지불 의도에는 고유한 파생 경로 색인이 할당됩니다. 게이트웨이는 파생 지수, 예상 금액, 스테이블코인, 체인, 만료 및 결제 상태를 저장합니다.

EVM 체인에서는 동일한 파생 주소가 모든 EVM 호환 체인에서 작동합니다. 단일 HD 지갑은 인텐트별로 별도의 주소 인덱스를 사용하여 Base, Ethereum, Polygon 및 Arbitrum를 제공할 수 있습니다.

주소 만료 및 재사용

입금 주소는 결제 의도 전반에 걸쳐 재사용되어서는 안 됩니다. 만료되거나 결제가 성공한 후에는 모니터링 계층에서 주소가 비활성화됩니다. 만료된 주소에 연체금이 도착하면 게이트웨이는 수동 검토를 위해 이를 일치하지 않는 것으로 기록합니다.

체인 모니터링 레이어

체인 모니터링 레이어는 블록체인에서 ERC-20(또는 이에 상응하는) 이벤트를 활성 입금 주소로 전송하는 것을 감시합니다. 설계에서는 높은 이벤트 볼륨(사용 중인 체인의 경우), 실시간 감지, 체인 재구성 및 여러 체인에 대한 동시 모니터링을 처리해야 합니다.

EVM 체인 모니터링

Subscribe to ERC-20 Transfer events from the stablecoin contract address using WebSocket RPC (Alchemy, QuickNode). Filter by the to address matching any active deposit address. Use a bloom filter or database index on active addresses for O(1) lookup.

Fallback: poll for recent Transfer events every N seconds using eth_getLogs. WebSocket subscriptions are preferred but can drop connections — the polling fallback ensures no missed events.

트론 TRC-20 모니터링

TronGrid API는 주소에 대한 거래 내역을 제공합니다. TronGrid REST API를 사용하여 각 활성 입금 주소에 대한 TRC-20 전송 내역을 폴링합니다. WebSocket 구독은 Tron에서 안정성이 낮습니다. 폴링이 표준 접근 방식입니다.

Solana SPL 토큰 모니터링

Solana uses Associated Token Accounts (ATAs) — each wallet address has a corresponding ATA for each SPL token. Monitor the USDC ATA corresponding to each deposit address using WebSocket account subscriptions or polling getSignaturesForAddress.

확인 엔진

확인 엔진은 감지된 이체를 검증하고 결제 이벤트를 내보냅니다. 주요 책임:

블록 깊이 확인: 확인 이벤트를 내보내기 전에 트랜잭션이 필요한 확인 깊이에 도달할 때까지 기다립니다.

금액 확인: 받은 금액과 예상 금액을 비교합니다. 미달 지불(수동 검토 플래그 또는 제품 허용 오차에 따른 거부 플래그) 및 초과 지불(크레딧 전액, 플래그 초과 플래그)을 처리합니다.

체인 재구성 처리: 이전에 감지된 거래가 체인 재구성으로 제거된 경우, Payment_Detected 이벤트를 되돌리고 보류 상태로 다시 들어갑니다. 체인 재구성 위험에 적합한 짧은 확인 깊이를 사용하십시오.

멱등성: 확인된 각 거래 해시가 저장됩니다. 동일한 확인 이벤트를 다시 재생할 수 없습니다.

원장 디자인

결제 원장은 모든 스테이블코인 결제 활동에 대한 권위 있는 기록입니다. 추가 전용(업데이트 없음, 삽입만 가능) 및 이벤트 소스여야 합니다. 모든 상태 전환(생성, 감지, 확인, 만료, 스위프)은 원장 항목입니다.

이벤트	트리거	다운스트림 작업
결제.생성	결제 의도가 생성됨	입금자 주소를 입금자에게 반환
결제.감지됨	온체인에서 전송이 확인되었으며 보류 중입니다.	지불인에게 통지합니다. 보류 상태 표시
결제.확인됨	필수 확인에 도달했습니다.	주문/구독 활성화 웹훅 트리거
결제가 만료되었습니다.	유효기간이 지났는데 결제가 안되네요	입금 주소 공개 지불인에게 통지
지불.미달	예상보다 적은 금액	검토를 위해 플래그를 지정합니다. 제품별 취급
결제.스왑	자금은 국고 지갑으로 휩쓸려갔습니다.	스윕 기록을 업데이트합니다. 주소 잔액 감소

청소 및 재무 관리

재무 지갑은 프로덕션 배포를 위한 다중 서명(예: Safe/Gnosis Safe)이어야 합니다. 중요한 재무 작업에는 여러 서명자가 필요합니다.

가스 자금 조달: 각 입금 주소에는 스윕 거래 가스 수수료를 충당하기 위한 기본 토큰(ETH, TRX 등)이 필요합니다. 게이트웨이는 청소 전에 예금 주소를 보충하는 가스 자금 제공자 서비스를 유지합니다.

스윕 트리거: 잔액 임계값, 시간 일정 또는 수동으로 트리거됩니다. 일괄 스윕을 수행하면 총 가스 비용이 절감됩니다.

스윕 확인: 스윕 거래는 확인을 위해 모니터링됩니다. 성공하면 스윕 원장 이벤트가 기록됩니다.

오프램프 통합 아키텍처

오프 램프는 재무부 지갑에 보관된 스테이블 코인을 법정화폐로 변환합니다. 통합 패턴:

오프 램프 제공자 계정: 오프램프 제공자(Bridge, Coinbase Prime 등)는 스테이블코인 대상 주소를 제공합니다. USDC을 이 주소로 보내면 구성된 은행 계좌로 법정화폐 결제가 실행됩니다.

전송 지시: 게이트웨이는 재무부 지갑에서 오프 램프 주소로의 이체를 구성하고 서명합니다. 이를 위해서는 재무부 지갑 서명 키 액세스가 필요하며 일반적으로 다중 서명 승인이 필요합니다.

정산확인: 오프램프 제공업체는 웹훅을 보내거나 APIs을 제공하여 법정화폐 결제를 확인합니다. 게이트웨이는 오프램프 전송에 대한 법정화폐 결제 이벤트를 기록합니다.

생산 고려 사항

생산 안정성에 중요한 아키텍처 결정:

중복 RPC 노드 연결 실행(Alchemy 기본 + QuickNode 폴백) - 단일 RPC 오류로 인해 결제 누락이 발생해서는 안 됩니다.
체인 모니터링과 확인 엔진 사이의 이벤트 큐(Kafka, SQS 또는 Redis Streams) — 처리에서 수집을 분리하고 재생을 활성화합니다.
원장 쓰기 관련 데이터베이스 트랜잭션 - 확인 이벤트 및 다운스트림 작업은 둘 다 커밋하거나 롤백해야 합니다.
실패한 웹훅 전달에 대한 배달 못한 편지 대기열 — 지수 백오프로 재시도, 반복되는 실패에 대한 경고
모니터링 및 경고: 체인 모니터링 지연, 일치하지 않는 지불, 청소 실패, 오프 램프 결제 지연
게이트웨이 애플리케이션 로직에서 서명 키 관리를 분리합니다. 재무 운영에는 다중 서명 승인이 필요합니다.

FAQ

게이트웨이는 독립형 서비스여야 합니까, 아니면 기본 애플리케이션에 내장되어야 합니까?

프로덕션에는 독립형 게이트웨이 서비스가 강력히 선호됩니다. 체인 모니터링 및 서명 논리를 기본 애플리케이션에서 분리하고 독립적으로 배포 및 확장할 수 있으며 명확한 보안 경계가 있습니다. 게이트웨이는 결제 이벤트를 게시합니다. 주요 애플리케이션이 이를 소비합니다.

잘못된 금액이나 잘못된 스테이블코인을 보내는 사용자를 어떻게 처리하나요?

입금 주소로 잘못된 스테이블코인 이체(예: USDC 대신 DAI)는 일치하지 않는 것으로 기록되며 수동 검토를 위해 대기됩니다. 미달 지불이 표시됩니다. 제품은 부분 지불 수락, 거부 또는 지불인에게 충전하라는 메시지를 표시할지 여부를 정의합니다. 초과지불은 전액 환불되며 초과금액은 온체인으로 환불됩니다.

RPC 노드가 다운되면 어떻게 되나요?

모니터링 계층은 중복 RPC 공급자를 사용하여 실행되어야 합니다. 모두 실패하면 게이트웨이는 성능 저하 상태가 됩니다. 즉, 새로운 결제 확인이 지연되지만 손실되지는 않습니다. 연결이 복원되면 마지막으로 확인된 블록부터 재생하여 누락된 전송 이벤트를 포착합니다. 모니터링과 확인 엔진 사이의 이벤트 대기열은 짧은 가동 중단 중에 이벤트가 삭제되지 않도록 보장합니다.

이 아키텍처는 어떻게 대용량으로 확장됩니까?

체인 모니터링 작업자의 수평적 확장(체인 또는 체인 샤드당 작업자 1명) 이벤트 큐는 버스트 볼륨을 흡수합니다. 확인 엔진은 원장 쓰기가 멱등성이 있는 한 수평으로 확장됩니다. 활성 주소에 대한 적절한 데이터베이스 인덱스를 사용하여 주소 파생 및 조회 규모를 조정합니다. 병목 현상은 일반적으로 RPC 속도 제한입니다. 규모에 맞는 전용 RPC 엔드포인트를 계획합니다.

아키텍처 요약

5개 계층: 결제 의도(주소 관리), 체인 모니터링, 확인 엔진, 원장 및 결제(스윕 + 오프 램프).

HD 지갑 파생은 주소별로 개인 키를 저장하지 않고 고유하고 결정적인 입금 주소를 제공합니다.

모니터링과 확인 엔진 사이의 이벤트 큐는 안정성과 재생에 매우 중요합니다.

원장은 추가 전용이어야 하며 이벤트 소스여야 합니다. 모든 상태 전환은 업데이트가 아닌 기록입니다.

Treasury 다중 서명 및 오프 램프 통합은 운영상 민감한 구성 요소입니다. 적절한 서명 제어 기능을 갖춘 설계입니다.