BTCPay Server는 MIT 라이선스로 배포되는 비트코인 결제 수신용 자유 소프트웨어입니다. 자신의 서버에서 실행하거나 다른 사람이 설치한 서비스를 이용할 수 있습니다. 결제 요청을 만들고 입금을 연결하며 기록을 돕습니다. 프로젝트 자체는 돈을 맡겨야 하는 계좌도, 상품 분쟁을 판정하는 중개자도 아닙니다.
온라인 서점을 떠올려 보세요. 고객이 비트코인을 선택하면 BTCPay Server가 invoice, 즉 특정 금액을 지급해 달라는 요청을 만듭니다. 결제 페이지에는 상점 설정에 따라 주소나 Lightning 요청이 표시됩니다. 프로그램은 입금을 확인하고 연결된 상점에 상태 변화를 알립니다. 운영자가 각 입금을 일일이 주문과 맞출 필요가 줄어듭니다. 매장 계산대나 기부금 수납에도 활용할 수 있습니다. 공개된 소스 코드는 검사와 수정을 가능하게 하지만, 그것만으로 특정 설치 환경의 안전성이 입증되지는 않습니다. [1]
기존 지갑을 연결할 때 서버에 확장 공개 키를 제공할 수 있습니다. 서버는 이 정보에서 수신 주소를 도출합니다. 송금을 승인하는 개인 키는 하드웨어 지갑처럼 서버 바깥에 남겨 둘 수 있습니다. 핫 월렛은 다릅니다. 비밀 정보가 인터넷에 연결된 기기에 직접 저장됩니다. 빠른 결제를 처리하는 Lightning 노드에 대한 접근 권한 역시 지출을 허용할 수 있습니다. 따라서 서버 운영과 돈에 대한 통제는 서로 다른 문제입니다. 직접 운영한다는 self-hosted라는 이름만으로 두 질문에 답할 수 없습니다. [2] [3]
다른 사람의 서버를 이용하면 설치와 유지보수 부담을 줄일 수 있습니다. 하지만 자신의 지갑으로 직접 받더라도 서버 관리자에게 의존합니다. 변조되거나 침해된 서버는 자신의 주소 대신 공격자의 주소를 표시할 수 있습니다. 공개 키만 얻었다고 이미 받은 코인을 쓸 수 있는 것은 아니지만, 조작된 계산대는 앞으로의 결제를 다른 곳으로 보낼 수 있습니다. 독립된 지갑에서도 입금을 확인해야 합니다. 직접 운영하는 서버가 침해돼도 같은 위험이 있으며, 외부 운영자는 가용성과 결제 프라이버시에도 영향을 줍니다. [4]
책 가격을 체코 코루나로 표시하고 고객은 비트코인으로 지불할 수 있습니다. Invoice는 일정 시간 동안 환율과 금액을 고정합니다. Processing은 요청한 전액이 지급됐지만 블록 확인 같은 결제 완료 조건이 남은 상태입니다. Settled는 그 조건이 충족됐다는 뜻이며, Lightning 결제는 일반적으로 블록을 기다리지 않습니다. 상점은 부족하거나 초과한 금액, 늦은 입금도 처리해야 합니다. 상태를 수동 변경해도 네트워크 확인이 생기지 않습니다. 화면의 가격 환산만으로 은행 계좌에 코루나가 들어오지도 않습니다. 플러그인이나 업체를 통한 환전은 별도 조건과 비용이 있는 서비스입니다. [5] [6] [3]
프로그램은 통신 인터페이스인 Greenfield API로 연결됩니다. 상점은 invoice 식별자를 주문과 함께 저장합니다. Webhook이라는 서버의 자동 메시지가 변화를 알리며, 문서에 따라 그 진위를 확인해야 합니다. API 접근 키에는 해당 상점에 필요한 권한만 줍니다. 같은 메시지가 다시 와도 두 번째 책을 보내면 안 됩니다. 고객이 감사 페이지로 돌아온 것 역시 결제 증거가 아닙니다. 장애 후에는 로컬 기록을 청구 내역 및 실제 입금과 대조해야 합니다. [7]
Lightning Network는 결제 채널을 사용하므로 모든 결제를 블록에 개별 기록할 필요가 없습니다. 자신의 노드는 이용 가능해야 하며 인바운드 유동성, 즉 자금이 자신에게 들어올 수 있는 채널의 여유가 있어야 합니다. 따라서 지속적인 관리가 필요합니다. 유동성 지원, 결제 네트워크 간 교환, 고객 자금을 대신 통제하는 수탁 서비스를 이용하는 방법도 있습니다. 각 선택은 권한, 수수료, 위험이 다릅니다. 결제 페이지의 BTCPay Server라는 이름만으로 상점이 어느 방식을 택했는지 알 수 없으며, 모든 결제의 성공이 보장되는 것도 아닙니다. [8]
지갑 복구 정보가 상점 전체의 백업은 아닙니다. 키 외에도 청구 기록, 설정, 구성에 맞는 추가 데이터가 필요합니다. Lightning에서는 오래된 채널 상태로 노드를 시작하는 것이 특히 위험합니다. 잘못 복구하면 자금을 잃을 수 있습니다. 계획된 서버 이전은 장애 복구와 다른 작업입니다. 이전 중에는 원래 노드의 상태가 계속 바뀌면 안 되며, 복원한 사본과 동시에 실행해서도 안 됩니다. 사용하는 구현체의 절차를 따르세요. Lightning 복구 시험은 네트워크와 상대 노드에서 격리해 실제 채널에 영향을 주지 않도록 해야 합니다. Docker는 애플리케이션 구성 요소를 별도 컨테이너에서 실행하는 환경이며, 해당 안내서는 이 설치 방식에 적용됩니다. [9]
장점은 자신의 결제 인프라를 직접 결정할 수 있다는 것입니다. 그러나 업데이트, 관리자 접근, 인터넷에 노출된 서비스, 실제 복원 가능한 백업은 누군가 관리해야 합니다. 프로그램이 결제마다 일정 비율을 떼지는 않지만 호스팅, 장비, 네트워크 수수료, Lightning 지원에는 비용이 들 수 있습니다. 불필요한 고객 개인정보는 저장하지 마세요. 책이 분실되거나 반품되면 판매자가 불만과 환불을 처리합니다. BTCPay Server 개발자가 판매 분쟁을 판정하지는 않습니다. 청구 기록은 회계를 돕지만 모든 회계상 의무를 대신하지 않습니다. [10] [3] [7]
계산대는 멈췄지만 지갑은 남습니다
외부 지갑의 공개 정보만 쓰는 상점의 서버가 응답을 멈췄다고 해 보세요. 그 지갑의 키로 통제하는 기존 입금은 사라지지 않습니다. 다만 고객이 새 결제 페이지를 열지 못하고 상점도 최신 주문 상태를 확인할 수 없을 수 있습니다. 복구 후에는 수신 설정을 확인하고 청구 내역을 지갑과 대조합니다. 이 예를 서버의 핫 월렛과 함께 비밀 키를 잃은 경우나 오래된 데이터로 Lightning 채널을 복구하는 경우에 그대로 적용할 수는 없습니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Payment Processor, Bitcoin Point of Sale, 자기 수탁, Lightning Network, Merchant Adoption, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Bitcoin Coffee, Transaction Labeling, Bitcoin Payment Processor, Bitcoin Point of Sale.