거래 감지, 체인 확인, 주문 연관성 및 서비스 전달은 별개의 단계입니다. 올바른 체인, 자산, 수신자 및 금액을 확인하고, 문서화된 수락 정책을 적용하며, 조정을 멱등적으로 만드세요. 거래 참조, 스크린샷 또는 브라우저 버튼만으로는 특정 주문이 결제되었음을 확립할 수 없습니다.
체인 이벤트와 주문 이벤트를 분리하세요
지갑이 전송이 이루어졌다고 보고하는 것은 자체 행동에 대한 증거일 뿐, 완전한 결제 결정이 아닙니다. 수신 백엔드는 의도한 네트워크를 관찰하고 실제 전송을 검증하며 이를 주문과 연관시켜야 합니다. 그런 다음에야 주문이 수락 정책을 적용할 수 있습니다. 인프라 전달은 결제 수락 이후의 또 다른 운영 단계입니다.
코드와 고객 언어 모두에서 이러한 전환을 명시적으로 유지하세요. 화면은 주문을 결제됨으로 표시하지 않고 대기, 감지 또는 확인 중을 표시할 수 있습니다. 브라우저가 수락 금액을 제공하거나 권위 있는 상태를 덮어쓰게 하지 마세요. 서버에서 생성한 견적과 그 지침을 저장하여 나중에 조정할 때 변경되는 장바구니가 아니라 원래 주문을 기준으로 평가할 수 있게 하세요.
체인별 신뢰 규칙을 사용하세요
네트워크마다 거래 신뢰도를 다르게 설명합니다. Bitcoin의 개발자 가이드는 노드가 가장 많은 누적 작업 증명을 가진 체인을 선택하는 방법과 경쟁 블록이 발생할 수 있는 방법을 설명합니다. 따라서 최근에 확인된 거래에는 확인 깊이와 가능한 체인 변경에 대한 정책이 필요합니다. 모든 자산과 상업적 위험에 적합한 단일 확인 횟수는 없습니다.
Ethereum의 지분 증명 문서는 체크포인트 최종성을 설명하고, Solana은 처리됨, 확인됨 및 최종화됨 커밋 상태를 문서화합니다. 이러한 용어를 하나의 보편적인 블록 수로 무심코 번역하지 마세요. 네트워크별 규칙, 정보 출처 및 불확실성 중의 동작을 기록하세요. 운영자는 관련 없는 결제에서 숫자를 복사하는 것이 아니라 결제 및 전달 위험에 따라 수락 임계값을 결정해야 합니다.
실제 전송 페이로드를 확인하세요
올바른 체인에서 수신자, 자산 및 금액을 식별하세요. 토큰 결제에는 주소로의 성공적인 거래만이 아니라 의도한 토큰 정체성이 필요합니다. 체인의 모델에 따라 관련 실행 성공 및 전송 증거를 확인하세요. 브라우저가 제공하는 형식화된 소수를 신뢰하지 말고 자산의 적절한 정밀도로 정수 금액을 파싱하세요.
결제 지침은 원래 경로에 묶여 있어야 합니다. 다른 네트워크의 전송, 같은 기호를 가진 다른 토큰 또는 관련 없는 거래 참조는 이를 충족하지 않아야 합니다. 검증 기록은 무엇을 확인했는지 설명하고 결정을 검토하는 데 필요한 증거를 보존해야 합니다. 이 가이드는 특정 서비스 구현이 아니라 일반적인 결제 조정 원칙을 설명합니다.
주문 연관성을 명확하게 만드세요
고정 수신 주소는 비슷한 금액의 여러 주문을 받을 수 있습니다. 일치하는 전송이 존재한다고 해서 어느 고객이나 주문에 크레딧을 제공해야 하는지 증명되지는 않습니다. 실제 결제를 수락하기 전에 연관 방법을 정의하고 충돌 처리를 포함하세요. 사용자가 제공한 거래 참조도 동일한 전송이 이미 다른 곳에 할당되지 않았는지 검증해야 합니다.
겹치는 기간 동안 같은 경로에서 같은 금액의 인보이스 두 개를 상상해 보세요. 감시자가 전송 하나를 봅니다. 둘 다 자동으로 결제됨으로 표시하는 것은 잘못이며, 충분한 증거 없이 하나를 선택하는 것도 안전하지 않습니다. 운영자의 정책이 유효한 연관성을 확립할 수 있을 때까지 전송을 미할당 또는 검토 상태로 유지하세요. 모호한 일치는 처리해야 할 상태이지, 확실성을 조작할 이유가 아닙니다.
지연되고 변하는 증거를 허용하는 상태를 정의하세요
결제 프로세스는 체인 증거를 주문 수락 결정과 분리한 명확한 소수의 상태로 구성하는 것이 좋습니다. 이 예시 표는 특정 서비스의 상태 이름을 설명하는 것이 아니라 가능한 단계를 설명합니다. 각 전환에는 검증된 이유가 있어야 하며 결제 수락은 인프라 전달과 구분되어야 합니다.
지연, 부분 및 초과 전송, 견적 만료 및 일시적으로 사용할 수 없는 체인 데이터를 포함하세요. 만료가 실제 전송을 사라지게 하지는 않습니다. 지연 결제는 자동 수락이나 거부가 아니라 검토가 필요할 수 있습니다. 이전에 관찰된 체인 이벤트가 변경되면 모든 감시자 알림을 되돌릴 수 없는 진실로 취급하지 말고 문서화된 정책에 따라 상태를 재평가하세요.
| 예시 상태 | 의미 | 다음 결정 |
|---|---|---|
| 대기 중 | 검증된 적격 전송 없음 | 유효한 인보이스 계속 관찰 |
| 감지됨 | 관련 전송 관찰됨 | 체인 신뢰도 및 연관성 확인 |
| 확인 중 | 수락 규칙 아직 충족되지 않음 | 정책이 결정을 허용할 때까지 관찰 |
| 검토 | 지연, 부분 또는 모호한 증거 | 운영자 정책에 따라 해결 |
| 수락됨 | 검증 및 조정된 결제 | 별도의 전달 워크플로로 진행 |
재시도를 안전하고 관찰 가능하게 만드세요
감시자와 조정 작업은 연결 중단이나 프로세스 재시작 후에 재시도합니다. 체인과 적절한 거래 또는 전송 식별자 같은 안정적인 전송 ID를 사용하여 중복 크레딧을 방지하세요. 진행 상황과 결정을 영속화하여 동일한 이벤트를 다시 처리할 때 두 번째 서비스를 프로비저닝하거나 수락된 견적을 변경하지 않도록 하세요.
알 수 없는 결과와 실패한 작업을 구분하세요. 다운스트림 요청이 시간 초과되면 다시 제출하기 전에 권위 있는 결과를 확인하세요. 수락된 작업과 불확실한 작업의 내구성 있는 기록을 유지하세요. 주문 토큰과 내부 증거에 대한 접근을 제한하면서 분쟁 결제를 조사하기에 충분한 정보를 보존하세요. 여기서 신뢰성은 결제 화면의 매끄러운 애니메이션이 아니라 반복 가능한 결정에 관한 것입니다.
대기 중인 주문에 여전히 필요한 것을 파악하세요
전송이 관찰되지 않았거나, 필요한 체인 신뢰도에 도달하지 않았거나, 인보이스와의 연관성을 검토해야 하기 때문에 주문이 대기 중일 수 있습니다. 인보이스와 공개 거래 참조를 보존하고, 명시된 수락 규칙을 확인하며, 주문의 의도된 지원 절차를 이용하세요. 상태 업데이트 지연만으로는 다른 결제를 보낼 이유가 되지 않습니다.
실제 주문에 대한 지침과 검증된 상태를 따르세요. 결제 확인은 조정된 전송의 수락을 식별해야 하며, 서비스 전달은 별도의 상태를 가집니다. 도움 요청에 비공개 액세스 토큰과 지갑 비밀을 포함하지 마세요.
실용 체크리스트.
- 서버에서 생성한 변경 불가능한 견적을 영속화하세요.
- 체인, 수신자, 자산 및 정수 금액을 확인하세요.
- 체인별 수락 규칙을 문서화하세요.
- 추측 없이 고정 주소 충돌을 처리하세요.
- 중복 크레딧과 안전하지 않은 재시도 제출을 방지하세요.
- 지연, 부분, 잘못된 경로 및 변경된 증거 사례를 테스트하세요.
중요한 세부 사항.
거래 해시만으로 결제를 확인할 수 있나요?+
아니요. 의도한 체인에서 전송, 페이로드 및 신뢰도를 확인한 다음, 그것이 주문에 속하고 이미 크레딧되지 않았음을 확립하세요.
모든 네트워크가 같은 확인 임계값을 사용할 수 있나요?+
아니요. 네트워크마다 다른 신뢰 및 최종성 모델을 노출합니다. 운영자는 각 경로에 적합한 수락 정책을 정의하고 테스트해야 합니다.
결제가 확인되면 서버가 프로비저닝되었나요?+
아니요. 결제 수락과 전달은 별도의 워크플로 이벤트입니다. 자체 권위 있는 프로세스에서 프로비저닝 상태를 전달하세요.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Bitcoin 개발자 가이드: 블록체인 동작 developer.bitcoin.org
- Ethereum: 지분 증명 및 최종성 ethereum.org
- Solana: RPC 상태 커밋 solana.com
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.