
잘못된 네트워크로 암호화폐가 결제되는 일을 방지하는 방법: 판매자 사고 대응 지침
블록체인에서 거래가 확정되었더라도 사업자가 요청한 결제로 인정되지 않을 수 있습니다. 고객이 올바른 토큰과 금액을 다른 네트워크로 전송했거나, 예상 주소로 다른 토큰을 보냈거나, 금액이 부족하거나, 무관한 주소로 자금을 보냈을 수 있기 때문입니다. 고객 지원팀은 송금이 이루어졌다는 증거와 주문 대금이 올바르게 결제되었다는 증거를 구분해야 합니다.
이 글은 지갑 복구 방법이 아니라 판매자 운영 지침입니다. 예방, 증빙 수집, 블록 탐색기 검증, 사고 분류, 재결제 요청, 중복 방지, 고객 안내를 다룹니다. 고객에게는 간략한 잘못된 네트워크 결제자 FAQ가 유용하며, 이 글에서는 고객에게 답변하기 전에 판매자가 내부적으로 해야 할 일을 설명합니다.
거래 확정이 결제 인정을 의미하지는 않습니다
블록체인은 해당 네트워크의 규칙에 따라 거래를 확정합니다. 사업자의 결제 절차에서는 확인된 송금 내역이 결제 요청과 일치하고, 사업자가 정한 승인 상태에 도달해야 결제로 인정합니다.
정상 결제라면 다음 항목이 모두 일치하는지 확인하세요.
| 항목 | 일치해야 하는 내용 |
|---|---|
| 주문 또는 결제 참조 정보 | 해당 고객과 구매 건에 대해 열려 있는 요청 |
| 네트워크 | 실제 결제 흐름에서 선택한 네트워크 |
| 자산 | 요청한 정확한 토큰 또는 네이티브 자산. 필요한 경우 예상 컨트랙트 또는 민트 포함 |
| 수신처 | 해당 결제 수단에 설정된 수신 주소 |
| 금액 | 결제 요청과 사업자의 금액 허용 오차 정책에서 요구하는 금액 |
| 거래 결과 | 단순히 제출되었거나 대기 중인 상태가 아니라 해당 네트워크에서 성공한 상태 |
| 컨펌 상태 | 주문 처리 정책에서 요구하는 기준 또는 상태 |
| 고유성 | 해당 거래가 다른 주문이나 이행 처리에 이미 적용되지 않았음 |
Circle의 블록체인 컨펌 참고 자료에 따르면 거래는 대기 상태에서 시작하고, 컨펌 방식은 블록체인마다 다르며, 최근 블록은 체인 재구성의 영향을 받을 수 있습니다. 따라서 거래 해시, 지갑 화면 캡처, 또는 ‘성공’ 화면은 조사할 증빙일 뿐, 그것만으로 주문 이행을 승인해서는 안 됩니다.
주요 사고 유형 구분하기
고객은 불일치 문제를 모두 ‘잘못된 네트워크’라고 표현하는 경우가 많습니다. 해결책을 선택하기 전에 사실관계부터 분류하세요.
| 사고 유형 | 발생한 일 | 판매자 대응 |
|---|---|---|
| 잘못된 네트워크 | 요청한 자산을 보냈을 수 있지만, 결제 요청에서 선택한 네트워크가 아닌 다른 네트워크를 사용함 | 실제 사용한 네트워크에서 거래를 검증하고, 수신 주소를 통제할 수 있는지와 해당 네트워크에서 자산을 사용할 수 있는지 확인하되 복구를 약속하지 않음 |
| 잘못된 토큰 또는 통화 | 네트워크는 올바를 수 있지만 전송된 자산이 요청과 일치하지 않음 | 토큰 컨트랙트 또는 민트와 수신처를 확인한 뒤 잘못된 통화 처리 절차를 따름 |
| 잘못된 주소 | 결제 요청의 수신 주소가 아닌 다른 주소로 송금됨 | 두 주소를 정확히 대조함. 판매자가 받지 못한 송금은 판매자가 되돌릴 수 없음 |
| 일부 결제 | 올바른 경로를 사용했지만 수신 금액이 요구 금액보다 적음 | 주문 이행을 중단하고 일부 결제 처리 절차를 따름. 즉석에서 추가 송금을 안내하지 않음 |
| 컨펌 지연 | 일치하는 거래가 대기 중이거나 판매자가 요구하는 컨펌 상태에 도달하지 않음 | 사건을 대기 상태로 유지하고 모니터링하며 결과가 확인될 때까지 두 번째 결제를 하지 않도록 안내함 |
| 중복 결제 | 고객이 두 번 이상 송금했거나 기존 요청과 재결제 요청이 모두 성공함 | 주문은 한 번만 이행하고 모든 거래를 보존하며 초과 수신 건은 검토 대상으로 전달함 |
익숙한 티커가 표시된다는 이유만으로 자산이 올바르다고 판단하지 마세요. Circle은 USDC를 여러 블록체인에서 발행되는 디지털 달러라고 설명하고, Tether는 Tether 토큰을 지원하는 프로토콜의 최신 목록을 제공합니다. 하지만 이러한 발행사 목록이 Yolfi, 판매자의 지갑 또는 사업체에서 지원하는 범위를 정하는 것은 아닙니다. 현재 Yolfi 설정에 표시되는 정확한 자산과 네트워크 조합만 제공하세요.
고객이 서명하기 전에 사고 예방하기
잘못된 네트워크 사고를 막는 가장 좋은 절차는 고객 지원이 아니라 결제 페이지에서 시작됩니다.
자산과 네트워크를 하나의 결제 수단으로 취급하기
결제 옵션을 ‘USDC’ 또는 ‘USDT’로만 표시하지 마세요. 선택 화면, 검토 화면, QR 안내, 지갑 연결 화면, 영수증, 고객 지원 기록, 정산 내보내기 등 모든 곳에서 ‘[선택한 네트워크]의 USDC’처럼 자산과 네트워크를 결합해 표시하세요.
USDC 결제 안내서와 USDT 결제 안내서에서는 네트워크 선택이 결제 수단의 일부인 이유를 설명합니다. 공개 안내에는 발행사가 토큰을 제공하는 모든 네트워크가 아니라 현재 결제 흐름에서 실제로 사용할 수 있는 조합만 기재해야 합니다.
결정 시점에 핵심 정보 다시 보여주기
지갑에서 서명하기 전에 다음 정보를 표시하세요.
- 정확한 자산 이름과 기호
- 정확한 네트워크 이름
- 정확한 금액
- 복사 기능이 제공되는 수신 주소
- 주문 또는 결제 참조 정보
- 해당하는 경우 만료 또는 시간 규칙
- 주소가 비슷해 보여도 다른 네트워크를 선택하면 안 된다는 경고
- 송금 후 결제 상태 페이지로 돌아오라는 안내
네트워크를 전환하면 토큰이 이동한다고 안내해서는 안 됩니다. 지갑에서 선택한 네트워크를 바꾸면 지갑이 표시하고 상호작용하는 체인만 달라질 뿐, 기존 잔액이 체인 사이를 이동하지는 않습니다. 별도의 브리지 이용이나 거래소 출금은 각각 고유한 위험과 지원 범위가 있는 별개의 작업입니다.
불필요한 선택지 줄이기
고객이 실제로 사용하고 담당 팀이 지원할 수 있는 옵션만 활성화하세요. 조합이 하나 늘어날 때마다 정산 주소, 토큰 식별자, 블록 탐색기, 컨펌 규칙, 예외 처리 경로도 추가됩니다. 현재 설정에서 제공되는 옵션을 검토하고, Yolfi의 네트워크별 페이지는 블록체인 목록에서 확인하세요.
활성화한 조합마다 소액으로 실제 테스트를 진행하세요. 결제 페이지의 표시 내용, 수신처, 지갑 안내, 블록 탐색기 기록, 상태 전환, 알림 또는 Webhook, 정산 기록, 주문 이행 동작을 확인해야 합니다.
사고 증빙 자료 구성하기
필요한 정보를 한 번에 요청하세요. 정보를 반복해서 요구하면 처리가 늦어지고 고객이 승인되지 않은 해결책을 시도할 가능성이 커집니다.
고객에게 받아야 할 증빙
- 결제 링크 URL 또는 결제 참조 ID
- 주문, 청구서 또는 계정 참조 정보
- 거래 해시와 가능한 경우 블록 탐색기 링크
- 고객이 보냈다고 생각하는 자산과 금액
- 고객이 실제로 선택한 네트워크
- 송신 지갑 주소
- 대략적인 송금 시각
판매자 측 증빙
- 원래 결제 요청에 표시된 자산, 네트워크, 금액, 수신처
- 요청 생성, 만료, 감지, 상태 변경 시각
- 요청한 조합에 설정된 정산 주소
- 관련 결제 알림, Webhook ID, 처리 결과
- 실제 사용된 네트워크의 블록 탐색기를 독립적으로 확인한 결과
- 고객 메시지와 담당 팀이 제공한 안내
- 같은 주문에 연결된 이전 결제 요청과 재결제 요청의 참조 정보
- 이미 처리된 주문 이행, 크레딧, 환불 또는 접근 권한 조치
화면 캡처는 조작되었거나 오래되었거나 다른 네트워크에서 촬영된 것일 수 있습니다. 화면 캡처로 거래를 찾은 뒤 거래 내역을 별도로 검증하세요.
올바른 블록 탐색기에서 송금 검증하기
우선 고객이 사용했다고 말한 네트워크에서 확인하되, 블록 탐색기 데이터로 실제 네트워크를 확정하세요. MetaMask의 잘못된 수신처 관련 안내도 상황을 판단하기 전에 거래 상태와 블록 탐색기를 확인하도록 권고합니다.
- 실제로 사용된 네트워크의 신뢰할 수 있는 블록 탐색기를 엽니다.
- 전체 거래 해시를 검색합니다. 링크에 표시된 문구를 그대로 믿지 말고 내부 절차에 따라 블록 탐색기 도메인을 확인합니다.
- 거래가 대기 중, 성공, 실패, 누락 또는 대체 중 어느 상태인지 확인합니다.
- 송신 주소와 수신 주소를 문자 단위로 대조합니다.
- 전송된 자산을 확인합니다. 토큰 송금이라면 기호만 보지 말고 컨트랙트 또는 민트도 확인합니다.
- 송금 이벤트에 기록된 토큰의 원시 수량을 확인합니다. 소수점 정밀도는 공식 컨트랙트나 민트 또는 신뢰할 수 있는 블록 탐색기 메타데이터에서 별도로 확인합니다.
- 블록, 타임스탬프, 현재 컨펌 수 또는 완결성 상태와 관련 로그를 기록합니다.
- 모든 항목을 원래 결제 요청과 대조합니다.
- 같은 네트워크에서 정산 지갑 또는 지갑 모니터링 기록을 확인합니다.
- 내부 기록을 검색해 해당 해시가 이미 인식되었거나 다른 곳에 적용되지 않았는지 확인합니다.
Circle의 EVM USDC 전송 빠른 시작 안내서는 체인 선택, 송금 제출, 해시 수신, 블록 탐색기 확인이 각각 별도의 단계임을 보여 줍니다. 송신자가 가스비를 지불하려면 해당 네트워크의 네이티브 토큰이 필요하다는 점도 설명합니다. 이는 송금 원리를 보여 주는 예시일 뿐, Yolfi 계정에서 사용할 수 있는 조합 목록으로 해석해서는 안 됩니다.
복구를 약속하지 말고 의사 결정 절차 따르기
다음 분기를 순서대로 따르세요.
1. 고객이 주장한 네트워크에 유효한 거래가 있나요?
- 없거나 아직 대기 중: 주문을 이행하지 않은 상태로 유지합니다. 모니터링하는 동안 또는 고객의 지갑 제공업체가 대기 중인 거래를 처리하는 동안 다시 송금하지 않도록 안내합니다.
- 실패했거나 되돌려짐: 해당 거래에서는 결제가 성공하지 않았습니다. 재결제 요청을 발행하기 전에 고객의 지갑 상태와 블록 탐색기 상태를 확인합니다.
- 성공: 각 항목이 일치하는지 계속 확인합니다.
2. 네트워크, 자산, 수신처, 금액, 컨펌 정책이 모두 일치하나요?
- 예: 정상 결제 인식 절차와 멱등성이 보장된 주문 이행 제어를 통해 처리합니다.
- 아니요: 예외 검토 대상으로 지정합니다. 어딘가로 가치가 이동했다는 이유만으로 수동으로 결제 완료 처리하지 마세요.
3. 실제 사용된 네트워크의 수신 주소를 판매자가 통제하나요?
- 확인되지 않음: 자금을 받았거나 복구할 수 있다고 말하지 마세요. 해당 주소를 담당하는 지갑 소유자 또는 수탁업체에 전달합니다.
- 예: 해당 주소에 정확한 자산이 존재하며, 판매자의 지갑, 보안, 회계, 규정 준수 절차에 따라 안전하게 관리할 수 있는지 확인합니다. 주소를 통제할 수 있다고 해서 원래 주문이 자동으로 올바르게 결제된 것은 아닙니다.
- 아니요: 사업자가 통제하지 않는 주소의 자금은 이동할 수 없다고 설명합니다. Ethereum.org의 지원 FAQ에 따르면 Ethereum 거래는 중앙 운영자가 되돌릴 수 없습니다. 수신 주소를 관리하는 서비스가 확인된다면 해당 서비스의 고객 지원팀에 문의하는 것이 적절할 수 있습니다.
4. 시정 조치가 승인되었나요?
가능한 결과로는 송금을 수동으로 결제로 인정하기, 올바른 방식으로 재결제 요청하기, 접근 가능한 자금을 새 거래로 반환하기, 문서화된 크레딧 적용하기, 복구 요청 거절하기 등이 있습니다. 적절한 결과는 네트워크, 주소 통제권, 토큰, 수탁 방식, 기술적 역량, 비용, 위험 검토, 사업 정책에 따라 달라집니다.
자금이 ‘항상 손실된다’거나 ‘항상 복구 가능하다’고 말해서는 안 됩니다. MetaMask 문서에는 동일한 지갑 주소를 다른 EVM 호환 네트워크에서 이용할 수 있는 일반적인 사례가 소개되어 있지만, 복구가 보장되지 않는 사례도 설명되어 있습니다. 이 안내만으로 판매자, 거래소, 스마트 컨트랙트, 다중 서명 지갑 또는 결제 시스템이 특정 송금에 접근하거나 이를 반환할 수 있다고 판단해서는 안 됩니다.
재결제 링크를 안전하게 발행하기
기존 요청을 결제로 인정할 수 없고 정책상 재시도가 허용된다면 새로운 Yolfi 결제 링크를 만드세요. 기존 기록을 수정하거나 고객에게 단순히 ‘다시 시도해 달라’고 안내해서는 안 됩니다.
재결제 요청은 다음 조건을 충족해야 합니다.
- 같은 주문 또는 청구서 ID를 유지합니다.
- 새로운 고유 결제 참조 ID를 부여합니다.
- 실제 결제 흐름에 표시되는 정확한 자산, 네트워크, 금액, 수신처를 명시합니다.
- 이전 요청이 대체되었거나 검토 중임을 표시합니다.
- 기존 거래는 별개의 사고로 계속 처리된다는 점을 설명합니다.
- 고객에게 두 링크를 모두 결제하지 말라고 안내합니다.
- 만료 규칙이 있다면 그대로 유지합니다.
- 주문을 이행하기 전에 두 요청 모두 중복 감지 절차를 거치게 합니다.
고객에게 추적되지 않는 차액만 따로 보내거나, 채팅에서 복사한 주소로 다시 보내거나, 송금 후 네트워크를 바꾸면 기존 자금이 이동하는 것처럼 안내해서는 안 됩니다.
중복 결제와 중복 주문 이행 방지하기
재결제 요청을 만든 뒤 지연된 기존 거래가 확정될 수 있습니다. 고객이 답변을 기다리는 동안 두 번 송금할 수도 있습니다. 두 상황 모두에 대비해야 합니다.
하나의 업무상 주문 ID 아래 변경할 수 없는 여러 결제 시도를 기록하세요. 다음 제어를 적용해야 합니다.
- 하나의 거래 해시는 최대 한 번만 결제로 인정할 수 있습니다.
- 하나의 결제 시도로 여러 주문을 이행할 수 없습니다.
- 하나의 주문은 주문 이행 또는 접근 권한 부여를 한 번만 실행할 수 있습니다.
- 기존 요청과 재결제 요청의 연결을 유지합니다.
- 주문 이행 직전에 열려 있는 모든 결제 시도를 확인합니다.
- 늦게 확정되거나 초과 수신된 거래는 검토 대상으로 보냅니다.
- Webhook과 알림 처리는 멱등성을 보장합니다.
- 환불에는 별도 승인, 수신처 검증, 거래 기록이 필요합니다.
두 건의 송금이 모두 성공했다면 하나를 삭제하거나, 다른 구매 건에 임의로 적용하거나, 새로운 고객 지원 메시지에 적힌 주소로 자동 반환하지 마세요. 중복 주문 이행을 중단하고 문서화된 크레딧 또는 환불 정책을 따르세요.
판매자 고객 지원 및 보안 규칙 마련하기
일선 고객 지원 담당자에게 응대 문구와 상위 담당자에게 전달해야 하는 기준을 제공하세요.
고객 지원 담당자는 공개 거래 데이터, 결제 참조 정보, 주문 세부 정보, 비밀 정보가 노출되지 않은 화면 캡처를 요청할 수 있습니다. 하지만 시드 문구, 복구 문구, 개인 키, 지갑 비밀번호, 일회용 코드 또는 고객 기기의 원격 제어 권한을 절대로 요청해서는 안 됩니다. 시드 문구나 개인 키를 아는 사람은 지갑을 통제할 수 있습니다.
다음과 같은 문구를 사용하세요.
[네트워크]에서 거래가 제출된 사실을 확인했습니다. 현재 자산, 수신처, 금액, 컨펌 상태가 결제 요청 [참조 정보]와 일치하는지 확인하고 있습니다. 새로 승인된 링크를 보내 드리거나 다음 단계를 안내해 드릴 때까지 추가 결제를 하지 마세요. 당사는 시드 문구나 개인 키를 요청하지 않습니다.
접수 확인, 증빙 검토, 상위 담당자 전달, 승인, 고객 안내의 처리 기한을 정하세요. 접근 가능 여부와 거래 처리 가능성을 확인하기 전에는 복구 일정을 약속하지 마세요.
Yolfi는 비수탁형 서비스입니다. 결제 자금은 Yolfi가 보관하지 않고 판매자가 설정한 지갑으로 전송됩니다. 따라서 올바른 지갑 설정, 접근 권한 관리, 판매자 측 사고 대응 정책이 반드시 필요합니다.
판매자 사고 대응 점검표
결제를 받기 전
- 모든 단계에서 자산과 네트워크를 함께 표시합니다.
- 현재 Yolfi 설정에서 제공되는 조합만 활성화합니다.
- 모든 정산 주소와 토큰 식별자를 확인합니다.
- 활성화한 경로마다 처음부터 끝까지 테스트합니다.
- 컨펌, 불일치, 중복, 환불, 상위 담당자 전달 규칙을 정합니다.
- 지갑 비밀 정보를 절대 요청하지 않도록 고객 지원팀을 교육합니다.
사고가 접수되었을 때
- 주문 이행을 중단하고 중복 결제를 하지 않도록 안내합니다.
- 원래 결제 요청과 고객 신고 내용을 보존합니다.
- 사고 증빙 자료를 구성합니다.
- 실제 사용된 네트워크에서 거래를 검증합니다.
- 네트워크, 자산, 수신처, 금액, 상태, 컨펌을 대조합니다.
- 복구 가능하다고 단정하지 않고 주소 통제권을 확인합니다.
- 이전 결제 인정 기록과 연결된 결제 시도를 검색합니다.
- 승인된 결정과 고객 안내 내용을 기록합니다.
자주 묻는 질문
거래가 확정되었는데도 미결제 상태로 남을 수 있나요?
예. 거래 확정은 네트워크가 해당 거래를 처리했다는 뜻입니다. 결제로 인정하려면 요청한 네트워크, 자산, 수신처, 금액, 참조 정보, 판매자의 컨펌 정책과도 일치해야 합니다.
지갑의 네트워크를 전환하면 자금을 복구하거나 이동할 수 있나요?
아니요. 선택한 네트워크를 전환하면 지갑이 표시하고 상호작용하는 블록체인만 바뀝니다. 네트워크 사이에서 토큰이 이동하지는 않습니다. 일부 EVM 사례에서는 같은 주소의 소유자가 실제 사용된 네트워크에서 자산을 확인할 수 있지만, 이후 송금이나 브리지는 별도의 작업이며 항상 가능하거나 적절하다고 보장할 수 없습니다.
고객에게 즉시 다시 결제해 달라고 해야 하나요?
아니요. 먼저 기존 거래가 대기 중인지, 실패했는지, 성공했는지, 또는 요청과 불일치하는지 확인해야 합니다. 재시도가 승인되면 기존 요청과 연결된 새 결제 요청을 발행하고 두 결제 시도 모두에 중복 감지를 적용하세요.
Yolfi가 잘못된 네트워크의 결제를 복구할 수 있나요?
복구할 수 있다고 단정해서는 안 됩니다. 비수탁형 결제 흐름에서는 자금이 판매자가 설정한 지갑으로 전송됩니다. 가능한 조치는 실제 수신처, 네트워크, 자산, 지갑 통제권, 기술적 역량, 판매자 정책에 따라 달라집니다.
고객이 올바른 네트워크에서 잘못된 토큰을 보냈다면 어떻게 하나요?
잘못된 통화 사고로 처리하세요. 토큰 컨트랙트 또는 민트, 금액, 수신처, 지갑 수신 내역을 확인한 뒤 주문을 결제 완료 처리하지 말고 문서화된 예외 처리 절차를 따르세요.
거래가 아직 대기 중이면 어떻게 하나요?
주문을 대기 상태로 유지하고 이행하지 마세요. 컨펌 정책에 따라 블록 탐색기와 결제 상태를 모니터링하세요. 대기 중인 거래가 처리되거나 통제된 재결제가 승인될 때까지 두 번째 송금을 하지 않도록 안내하세요.
화면 캡처만으로 주문 이행을 승인해도 되나요?
아니요. 해시로 거래를 찾고 올바른 블록 탐색기에서 독립적으로 검증하세요. 그런 다음 거래와 결제 요청을 대조하고 해당 거래가 이미 사용되지 않았는지 확인해야 합니다.
결론
잘못된 네트워크로 결제되는 일을 예방하려면 자산, 네트워크, 수신처, 금액, 컨펌 상태를 명확하게 제시해야 합니다. 사고가 발생하면 검증된 거래 데이터와 신중한 지갑 통제권 확인이 필요하며, 복구를 약속하지 말고 중복을 방지해야 합니다.
현재 Yolfi 설정에 표시되는 조합부터 테스트하고, 고객 지원팀에는 하나의 의사 결정 절차를 제공하세요. 재결제가 필요하다면 채팅으로 즉석 안내하지 말고 기존 요청과 연결된 새 결제 요청을 만드세요. 목표는 올바른 결제를 정확히 인식하고 주문을 한 번만 이행하며, 모든 예외 처리 결정을 기록으로 남기는 것입니다.


