Bitcoin Payment Processor는 결제 요청을 만들고 입금을 추적해 주문과 연결하는 소프트웨어나 서비스입니다. 판매 처리와 기록 보관을 돕습니다. 비트코인 네트워크 규칙을 정하거나 반드시 고객 자금을 보관하는 것은 아닙니다. 누가 키를 통제하고 누가 누구에게 돈을 지급하는지는 구성에 달려 있습니다.
고객이 온라인에서 책을 주문한다고 가정해 봅시다. 상점은 프로세서에 invoice, 즉 금액과 통화가 적힌 결제 요청을 만들도록 하고, 그 식별자를 주문 번호와 함께 저장합니다. 고객은 결제 페이지를 열거나 QR 코드를 읽어 결제합니다. 저장된 연결을 통해 상점은 돈이 어느 구매에 해당하는지 알 수 있습니다. 이 연결 없이는 어디론가 비트코인이 들어왔다는 사실만으로 충분하지 않습니다. “주문해 주셔서 감사합니다” 페이지로 돌아온 것도 상점의 입금 증거는 아닙니다. [1]
BTCPay Server는 기존 지갑의 공개 데이터로 수신 주소를 만들 수 있으며, 지출을 가능하게 하는 개인 키를 받을 필요는 없습니다. 이는 키가 서버에 있는 핫 월렛이나 빠른 결제를 처리하는 Lightning 노드 자금에 접근하는 구성과 다릅니다. 서비스에서는 제공자가 지급 전까지 돈을 통제할 수 있습니다. 따라서 제공자에게 키를 맡기지 않는다는 non-custodial 표시만으로 판단해서는 안 됩니다. 실제 권한, 누가 돈을 보낼 수 있는지, 돈을 받는 데 다른 사람의 승인이 필요한지 확인해야 합니다. [2] [6]
책 가격은 일반 통화로 표시되지만 고객은 비트코인을 보낼 수 있습니다. BTCPay Server는 결제 요청에 금액과 환율을 일정 시간 고정합니다. 만료되어도 나중의 전송이 도착하지 못하는 것은 아니므로 상점은 이를 올바르게 처리해야 합니다. 부족 지급과 초과 지급도 마찬가지입니다. 원래 금액과 환율은 대조를 위해 보관합니다. 책 가격이 같아도 다른 환율로 새 요청을 만들면 비트코인의 최소 단위인 사토시의 요구 수량이 달라질 수 있습니다. [3]
BTCPay Server에서 Processing은 요구 금액이 지급되었지만 블록의 거래 확인 같은 완료 조건이 아직 충족되지 않았다는 뜻입니다. Settled는 조건 충족을 나타내며, Lightning 결제는 보통 블록 확인을 기다리지 않습니다. 다른 서비스는 상태를 자체적으로 정의합니다. BitPay는 paid가 결제 보장이 아니라고 명시합니다. 발송 규칙은 선택한 서비스의 문서와 결제 방식에 맞아야 합니다. 주문을 수동으로 결제 완료로 바꾸는 것은 실제 결제 확인을 대신하지 못합니다. [3] [5]
프로세서는 서버 사이의 자동 메시지인 webhook으로 상태 변경을 알립니다. 상점은 출처와 내용을 검증해야 합니다. BTCPay에서는 원본 메시지 바이트와 공유 비밀로 HMAC-SHA256을 계산합니다. 이는 인증 코드이지 비트코인 네트워크 확인이 아닙니다. BitPay는 IPN 알림에 서명하지 않습니다. 알림은 프로그램 간 통신 인터페이스인 API로 실제 상태를 조회하는 계기로만 사용해야 합니다. 메시지는 다시 올 수 있으므로 상점은 주문 처리 완료를 기록해 중복 발송을 막습니다. 장애 후에는 저장된 상태를 프로세서와 대조합니다. [4] [5]
고객 결제 수신과 서비스의 대금 지급은 별개의 사건입니다. BitPay에서는 지원되는 정산 통화와 은행 계좌 또는 암호화폐 주소를 설정할 수 있으며 변경에 승인이 필요할 수 있습니다. 판매자는 일정, 한도, 수수료, 지급 전 자금 통제권도 확인합니다. 자기 지갑으로 직접 받는 경우 이 중간 단계가 없을 수 있습니다. 판매 시스템은 두 방식을 구별해 “결제 완료”가 곧 사용 가능한 돈이라는 오해를 주지 않아야 합니다. [6] [2]
환불은 원래 비트코인 거래를 지우지 않습니다. 상점은 먼저 고객 요청을 처리하고 금액과 통화를 정한 다음, 수신자를 확인해 새 결제를 마련합니다. 환불 신청 링크만으로 돈이 이미 나갔다고 볼 수는 없습니다. 주문, 결제 요청, 수신 금액, 환율, 수수료, 환불 기록을 남깁니다. 내보낸 보고서는 회계를 돕지만 모든 지역 의무를 혼자 충족하지는 않습니다. 네트워크 확인도 배송 분쟁을 판정하거나 불만 처리에 관한 계약상·법적 의무를 없애지 않습니다. [7] [8] [10]
출시 전 한 번의 성공적인 시험 구매만으로는 부족합니다. 부족 지급, 늦은 지급, 반복 알림, 장애 복구를 시험해야 합니다. API 키는 프로그램의 접근 자격 증명이므로 해당 상점에 필요한 권한만 줍니다. 부가 정보에는 불필요한 고객 개인정보를 넣지 않습니다. 직접 운영에는 호스팅, 업데이트, 지원이 필요합니다. Lightning에는 결제에 필요한 자금과 채널의 가용 공간이라는 유동성 관리도 필요합니다. 무료 소프트웨어가 무료 운영을 뜻하지는 않습니다. 가용성, 키 보호, 올바른 상점 연동을 각각 점검합니다. [1] [9]
결제된 책과 다시 도착한 메시지
상점은 결제 요청을 주문 OBJ-101과 연결합니다. 결제를 검증하고 발송 조건을 충족하면 책을 보내고 처리 완료를 기록합니다. 나중에 같은 알림이 다시 와도 시스템은 이미 처리된 주문으로 인식해 다른 소포를 만들지 않습니다. 감사 페이지를 여는 행동만으로는 배송을 시작할 수 없습니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Alza의 비트코인 결제, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01프로세서에 비트코인을 맡겨야 하나요?+
항상 그렇지는 않습니다. 소프트웨어는 지출 키 없이 자기 지갑으로 들어오는 결제를 추적할 수 있습니다. 서버 핫 월렛, Lightning 노드 접근, 나중에 대금을 지급하는 서비스는 조건이 다릅니다. non-custodial 표시만 보지 말고 실제 돈의 통제권과 권한을 확인하세요.
02고객이 상점으로 돌아오면 바로 발송해도 되나요?+
아니요. 브라우저에서 돌아오는 것은 페이지 동작일 뿐입니다. 상점은 해당 결제의 검증된 상태와 그 방식에 맞는 주문 처리 규칙이 필요합니다. 같은 결제의 반복 메시지도 중복 발송을 일으켜서는 안 됩니다.