BTCPay Server는 MIT 라이선스의 자유 결제 처리 소프트웨어로, 자신의 인스턴스나 제삼자 호스트를 통해 운영할 수 있습니다. 프로젝트는 소프트웨어를 제공하며, 공통 수탁 계좌나 상점 분쟁 중재 서비스를 제공하는 것은 아닙니다. 신뢰 요건은 서버, 지갑, 결제 서비스의 실제 연결에 따라 달라집니다.
상점은 계산대나 온라인 상점을 청구서 및 선택한 수신 방식과 연결합니다. BTCPay Server는 온체인 결제 주소와 Lightning 요청을 만들고 결제를 추적하며 청구서 목록을 제공합니다. 판매 시점 및 기부 앱과 통합 인터페이스도 포함합니다. 공개 소스는 검사와 수정을 가능하게 하지만, 그 자체로 특정 설치의 보안을 입증하지는 않습니다. [BTCPay Server — Source repository]
기존 온체인 지갑은 확장 공개 키로 연결할 수 있습니다. 서버는 개인 키 없이 수신 주소를 도출합니다. 서버에 생성한 핫 월렛은 위험 모델이 다릅니다. Lightning 노드 권한도 그 자금을 사용할 수 있게 할 수 있습니다. 수신, 서명, 관리용 키를 구분하세요. self-hosted라는 말만으로 누가 돈을 쓸 수 있는지는 정해지지 않습니다. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
제삼자가 서버를 운영하면서 사용자는 자신의 지갑으로 직접 받을 수 있습니다. 그래도 신뢰가 없어지는 것은 아닙니다. 악의적이거나 침해된 서버가 공개 키를 바꿔 미래 결제를 다른 곳으로 돌릴 수 있습니다. 지갑에 이미 받은 코인과 새로 표시되는 결제 정보는 별개입니다. 계산대와 독립적으로도 입금을 확인하세요. 침해된 자체 인스턴스에도 같은 공격이 가능하며, 호스트는 가용성과 개인정보 보호에도 영향을 줍니다. [BTCPay Server — Third-party hosting risks]
상점은 통화, 환율 출처, 유효기간, 필요한 확인 횟수를 설정합니다. 온체인 결제의 Processing은 설정 조건을 기다리고 Settled는 충족을 나타냅니다. 성공한 Lightning 결제는 블록을 기다릴 필요가 없습니다. 부족 지급, 초과 지급, 늦은 수신과 수동 상태 변경도 처리해야 합니다. 수동 변경은 네트워크 확인을 만들지 않습니다. 가격을 비트코인으로 환산하는 것은 법정화폐로 파는 것과 다르며, 환전 플러그인이나 제공자는 자체 수수료와 신뢰 요건을 추가합니다. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
온라인 상점은 주문과 청구서 식별자의 연결을 보관해야 합니다. Greenfield API로 상점별 권한을 제한할 수 있습니다. 키에 통합에 필요한 것보다 많은 접근 권한을 주지 마세요. 문서에 따라 webhook을 검증하고 중복 이벤트가 두 번째 배송을 만들지 않도록 처리합니다. 고객이 감사 페이지로 돌아오는 것만으로 결제가 입증되지 않습니다. 장애 후에는 로컬 기록을 실제 청구서 및 결제 상태와 대조하세요. [BTCPay Server — eCommerce integration]
자체 노드는 가용성, 채널 관리, 수신 유동성이 필요합니다. 유동성 서비스, swap, 수탁 지갑은 서로 다른 부분을 해결하며 같은 모델이 아닙니다. 수탁 서비스에서는 제공자가 자금 통제권을 보유합니다. 다른 방식에서도 구체적인 권한과 위험을 확인해야 합니다. BTCPay Server 로고는 모든 결제의 성공이나 수수료 0을 보장하지 않습니다. [BTCPay Server — Lightning options]
배포 방식에 맞춰 상점 정보, 청구서, 설정, 필요한 지갑 데이터를 백업하세요. 시드는 주문 데이터베이스를 대신하지 않습니다. Docker 문서는 백업 복원을 검증하도록 요구합니다. 오래된 Lightning 채널 상태를 잘못 복원하면 자금을 잃을 수 있습니다. 원래 노드를 정상 종료한 계획된 이전은 재해 복구와 다릅니다. 대체 노드를 시작한 뒤 동일 노드의 원본 사본을 시작하지 마세요. 사용하는 백엔드에 맞는 절차가 필요합니다. [BTCPay Server — Backup and restore]
업데이트, 관리자 접근 보호, 네트워크 노출, 가용성 모니터링, 검증된 백업을 계획하세요. 소프트웨어가 결제마다 일정 비율을 받지 않아도 호스팅, 하드웨어, 네트워크 수수료, 유동성, 지원 비용은 들 수 있습니다. 저장하는 고객 데이터를 줄이세요. 환불과 배송 분쟁은 프로젝트 개발자가 아니라 상점이 처리합니다. 청구서 내보내기가 모든 회계 의무 이행을 보장하지는 않습니다. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
계산대 장애가 이미 받은 코인의 손실은 아니다
가상의 상점에서 서버는 외부 지갑의 공개 데이터만 압니다. 호스팅이 멈춰도 이미 받은 온체인 코인은 그 키로 계속 통제하지만, 계산대는 새 청구서를 만들거나 결제를 알리지 못할 수 있습니다. 운영자는 서비스를 복구하고 수신 설정을 확인하며 주문과 지갑을 대조합니다. 이 예시는 잃어버린 서버에 저장한 핫 월렛이나 오래된 Lightning 채널 상태에는 적용되지 않습니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Payment Processor, Bitcoin Point of Sale, 자기 보관, Lightning Network, Merchant Adoption, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01BTCPay Server는 자동으로 자기 수탁을 의미하나요?+
아닙니다. 연결한 지갑, Lightning 서비스, 실제 권한에 달려 있습니다. 공개 키만으로 외부 지갑에 받는 것은 다른 사람의 서버에 있는 핫 월렛이나 수탁 백엔드와 다릅니다. 표시되는 결제 정보의 정확성도 신뢰해야 합니다.
02복구에는 시드 백업만 있으면 되나요?+
시드는 해당 온체인 지갑을 복원할 수 있지만 청구서, 상점 설정, Lightning 채널 상태까지 자동 복원하지는 않습니다. 이 부분은 각자의 백업과 절차가 필요합니다. 복구를 시험해야 하며, 활성 Lightning 노드의 오래된 사본을 일반 파일 백업처럼 안전하게 취급할 수는 없습니다.