Bitcoin Payment Processor to program lub usługa tworząca żądania płatności, śledząca wpłaty i przypisująca je do zamówień. Pomaga obsłużyć sprzedaż i zachować dokumentację. Nie ustala reguł sieci Bitcoin ani nie musi przechowywać środków klientów: kontrola kluczy i sposób wypłaty zależą od konfiguracji.
Wyobraźmy sobie klienta zamawiającego książkę w internecie. Sklep prosi procesor o invoice, czyli żądanie płatności z kwotą i walutą, a jego identyfikator zapisuje przy numerze zamówienia. Klient otwiera stronę płatności lub skanuje kod QR i płaci. Zapisane powiązanie pozwala przypisać pieniądze do zakupu. Bez niego samo wykrycie, że gdzieś wpłynął bitcoin, nie wystarcza. Również powrót na stronę „Dziękujemy za zamówienie” nie dowodzi, że sklep otrzymał pieniądze. [1]
BTCPay Server może tworzyć adresy odbiorcze z publicznych danych istniejącego portfela, bez kluczy prywatnych umożliwiających wydawanie. To inny układ niż gorący portfel z kluczami na serwerze lub dostęp do środków węzła Lightning obsługującego szybkie płatności. W usłudze dostawca może kontrolować pieniądze przed wypłatą. Sama etykieta non-custodial, oznaczająca niepowierzanie mu kluczy, nie wystarcza. Sprawdź rzeczywiste uprawnienia, kto może wysłać środki i czy ich odzyskanie wymaga cudzej zgody. [2] [6]
Cena książki może być podana w zwykłej walucie, choć klient wysyła bitcoin. BTCPay Server ustala więc kwotę i kurs w żądaniu na ograniczony czas. Wygaśnięcie nie blokuje późniejszego przelewu; sklep musi go właściwie obsłużyć. Podobnie jest z niedopłatami i nadpłatami. Pierwotna kwota i kurs pozostają w ewidencji do rozliczenia. Nowe żądanie przy innym kursie może wymagać innej liczby satoshi, najmniejszych jednostek bitcoina, mimo niezmienionej ceny książki. [3]
W BTCPay Server stan Processing oznacza opłacenie żądanej kwoty, ale niespełnione jeszcze warunki zakończenia, na przykład potwierdzenia transakcji w blokach. Settled oznacza ich spełnienie; płatności Lightning zwykle nie czekają na potwierdzenie w bloku. Inne usługi mają własne znaczenia stanów. BitPay wyraźnie ostrzega, że paid nie gwarantuje płatności. Reguła wysyłki musi wynikać z dokumentacji wybranej usługi i metody płatności. Ręczne oznaczenie zamówienia jako opłaconego nie zastępuje sprawdzenia rzeczywistej wpłaty. [3] [5]
Procesor zgłasza zmiany przez webhook, automatyczną wiadomość między serwerami. Sklep weryfikuje jej pochodzenie i treść. W BTCPay HMAC-SHA256 oblicza się z oryginalnych bajtów wiadomości i wspólnego sekretu. To kod uwierzytelniający, a nie potwierdzenie sieci Bitcoin. BitPay nie podpisuje powiadomienia IPN: powinno ono tylko wywołać sprawdzenie rzeczywistego stanu przez API, interfejs komunikacji programów. Wiadomości mogą przychodzić ponownie. Sklep zapisuje realizację zamówienia, aby powtórka nie spowodowała kolejnej wysyłki. Po awarii uzgadnia zapisane stany z procesorem. [4] [5]
Wpłata klienta i wypłata od usługodawcy to różne zdarzenia. BitPay pozwala wybrać obsługiwaną walutę rozliczenia oraz rachunek bankowy lub adres kryptowalutowy; zmiany mogą wymagać zatwierdzenia. Sprzedawca sprawdza więc też terminy, limity, opłaty i kontrolę pieniędzy przed wypłatą. Przy bezpośrednim wpływie do własnego portfela ten etap pośredni może nie występować. System sprzedaży powinien odróżniać te modele, aby „opłacone” nie sugerowało błędnie, że pieniądze są już dostępne. [6] [2]
Zwrot pieniędzy nie usuwa pierwotnej transakcji Bitcoin. Sklep najpierw rozpatruje prośbę, ustala kwotę i walutę, weryfikuje odbiorcę i zleca nową płatność. Link do zgłoszenia zwrotu nie oznacza jeszcze, że środki wysłano. W dokumentacji zostają zamówienie, żądanie płatności, wpłata, kurs, opłaty i zwrot. Eksport raportów pomaga księgowości, ale sam nie spełnia wszystkich lokalnych obowiązków. Potwierdzenie sieciowe nie rozstrzyga sporu o dostawę ani nie znosi umownych czy ustawowych obowiązków dotyczących reklamacji. [7] [8] [10]
Jeden udany zakup próbny przed uruchomieniem nie wystarczy. Trzeba sprawdzić niedopłaty, spóźnione wpłaty, powtarzające się powiadomienia i powrót do pracy po awarii. Klucz API jest danymi dostępowymi programu: otrzymuje tylko potrzebne uprawnienia do danego sklepu. Dołączane informacje nie powinny zawierać zbędnych danych klienta. Własna obsługa wymaga hostingu, aktualizacji i wsparcia; Lightning również zarządzania płynnością, czyli środkami i dostępnym miejscem w kanałach płatniczych. Darmowy program nie oznacza darmowego działania. Dostępność, ochrona kluczy i poprawne połączenie ze sklepem wymagają osobnych kontroli. [1] [9]
Opłacona książka i ponowna wiadomość
Sklep łączy żądanie płatności z zamówieniem OBJ-101. Po sprawdzeniu wpłaty i spełnieniu warunków wysyłki wysyła książkę oraz zapisuje realizację. Później przychodzi ponownie to samo powiadomienie. System rozpoznaje wykonane zamówienie i nie tworzy kolejnej paczki. Samo otwarcie strony z podziękowaniem nie wystarczyłoby do wysyłki.
Pełniejszy obraz uzyskasz, czytając to hasło razem z BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. Do tego hasła prowadzą również odsyłacze z Płatność bitcoinem w Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Czy muszę powierzyć bitcoin procesorowi?+
Nie zawsze. Program może obserwować wpłaty do twojego portfela bez kluczy do wydawania. Gorący portfel na serwerze, dostęp do węzła Lightning lub usługa z późniejszą wypłatą mają inne warunki. Oceniaj faktyczną kontrolę pieniędzy i uprawnienia, nie samą etykietę non-custodial.
02Czy mogę wysłać towar po powrocie klienta do sklepu?+
Nie. Powrót w przeglądarce to jedynie czynność na stronie. Sklep potrzebuje zweryfikowanego stanu konkretnej płatności i reguły realizacji odpowiedniej dla tej metody. Powtarzające się wiadomości o tej samej wpłacie też nie mogą uruchamiać kolejnych wysyłek.