BTCPay Server to wolny procesor płatności na licencji MIT, działający we własnej instancji lub u zewnętrznego gospodarza. Projekt dostarcza oprogramowanie, nie uniwersalny rachunek powierniczy ani arbitraż sporów ze sprzedawcą. Zaufanie zależy od rzeczywistego połączenia serwera, portfela i usług płatniczych.
Sprzedawca łączy kasę lub sklep internetowy z fakturą i wybraną metodą odbioru. BTCPay Server tworzy adresy płatności on-chain i żądania Lightning, śledzi płatności i udostępnia przegląd faktur. Zawiera też aplikacje kasowe i do darowizn oraz interfejsy integracji. Otwarty kod umożliwia kontrolę i modyfikacje, ale sam nie dowodzi bezpieczeństwa konkretnej instalacji. [BTCPay Server — Source repository]
Istniejący portfel on-chain można połączyć rozszerzonym kluczem publicznym: serwer wyprowadza adresy odbiorcze bez jego klucza prywatnego. Gorący portfel utworzony na serwerze ma inny model ryzyka. Uprawnienia węzła Lightning również mogą umożliwiać dysponowanie jego środkami. Oddzielaj klucze odbioru, podpisu i administracji; samo słowo self-hosted nie określa, kto może wydać pieniądze. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Zewnętrzny gospodarz zapewnia serwer, podczas gdy użytkownik może odbierać bezpośrednio do własnego portfela. Nie usuwa to zaufania: złośliwy lub przejęty serwer może podmienić klucz publiczny i przekierować przyszłe płatności. Monety już otrzymane we własnym portfelu i nowo wyświetlane dane płatności to różne sprawy. Sprawdzaj wpływy także niezależnie od kasy. Ten sam atak może dotknąć przejętą własną instancję; gospodarz wpływa też na dostępność i prywatność. [BTCPay Server — Third-party hosting risks]
Sklep ustawia walutę, źródło kursu, ważność i wymagane potwierdzenia. Processing płatności on-chain oczekuje na ustawiony warunek, a Settled oznacza jego spełnienie. Udana płatność Lightning nie musi czekać na blok. Obsługuj niedopłaty, nadpłaty, spóźnione wpływy i ręczne zmiany stanu, które nie tworzą potwierdzeń sieciowych. Przeliczenie ceny na bitcoin nie jest sprzedażą za fiat: wtyczka lub dostawca wymiany dodaje własne opłaty i wymagania zaufania. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
Sklep powinien przechowywać powiązanie zamówienia z identyfikatorem faktury. Greenfield API pozwala ograniczać uprawnienia do danego sklepu; nie nadawaj kluczowi więcej dostępu, niż potrzeba. Weryfikuj webhooki według dokumentacji i obsługuj powtórzone zdarzenia bez drugiej wysyłki. Powrót klienta na stronę z podziękowaniem sam nie dowodzi zapłaty. Po awarii uzgodnij lokalne zapisy z rzeczywistymi stanami faktur i płatności. [BTCPay Server — eCommerce integration]
Własny węzeł wymaga dostępności, zarządzania kanałami i płynności przychodzącej. Usługa płynności, swap lub portfel powierniczy rozwiązują różne części problemu i nie są tym samym modelem. W usłudze powierniczej kontrola środków pozostaje u dostawcy; w innych wariantach trzeba sprawdzić konkretne uprawnienia i ryzyka. Logo BTCPay Server nie gwarantuje powodzenia każdej płatności ani zerowych opłat. [BTCPay Server — Lightning options]
Twórz kopie danych sklepów, faktur, konfiguracji i potrzebnych danych portfeli stosownie do wdrożenia; seed nie zastępuje bazy zamówień. Dokumentacja Docker wymaga sprawdzenia odtworzenia kopii. Stary stan kanału Lightning może przy błędnym odtworzeniu spowodować utratę środków. Planowana migracja z poprawnie zatrzymanym starym węzłem różni się od odzyskiwania po katastrofie; po uruchomieniu zamiennika nie uruchamiaj pierwotnej kopii tego samego węzła. Procedura musi odpowiadać używanemu backendowi. [BTCPay Server — Backup and restore]
Zaplanuj aktualizacje, ochronę dostępu administratora, ekspozycję sieciową, monitoring dostępności i sprawdzone kopie. Hosting, sprzęt, opłaty sieciowe, płynność i wsparcie mogą kosztować, choć program nie pobiera procentu od każdej płatności. Ograniczaj przechowywane dane klientów. Zwrotami i sporami o dostawę zajmuje się sprzedawca, a nie twórcy projektu; eksport faktur nie gwarantuje spełnienia wszystkich obowiązków księgowych. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Awaria kasy nie oznacza utraty już otrzymanych monet
W przykładowym sklepie serwer zna tylko publiczne dane zewnętrznego portfela. Gdy hosting przestaje działać, otrzymane monety on-chain pozostają pod kontrolą jego kluczy, ale kasa może nie tworzyć nowych faktur ani nie zgłaszać płatności. Operator przywraca usługę, sprawdza konfigurację odbioru i uzgadnia zamówienia z portfelem. Przykład nie dotyczy gorącego portfela na utraconym serwerze ani przestarzałego stanu kanałów Lightning.
Pełniejszy obraz uzyskasz, czytając to hasło razem z Bitcoin Payment Processor, Bitcoin Point of Sale, Samodzielna opieka, Lightning Network, Merchant Adoption, Bitcoin. Do tego hasła prowadzą również odsyłacze z Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01Czy BTCPay Server automatycznie oznacza samodzielną kontrolę środków?+
Nie. Decydują podłączony portfel, usługa Lightning i rzeczywiste uprawnienia. Odbiór do zewnętrznego portfela wyłącznie przez klucz publiczny różni się od gorącego portfela na cudzym serwerze czy powierniczego backendu. Trzeba też ufać poprawności wyświetlanych danych płatności.
02Czy do odtworzenia wystarczy kopia seeda?+
Seed może odtworzyć odpowiedni portfel on-chain, ale nie automatycznie faktury, ustawienia sklepów i stany kanałów Lightning. Te części mają osobne kopie i procedury. Odtworzenie trzeba przetestować; przestarzałej kopii aktywnego węzła Lightning nie można bezpiecznie traktować jak zwykłej kopii plików.