497 / 691₿·POS

Bitcoin Point of Sale

Kasa bitcoinowa do sprzedaży stacjonarnej

Kasa łączy zamówienie z żądaniem płatności bitcoinem i zweryfikowanym wpływem. Ani kod QR, ani ekran klienta same nie potwierdzają zapłaty; przechowywanie środków, kurs, awarie i zwroty zależą od wybranego rozwiązania.

Bitcoin Point of Sale to interfejs kasowy do sprzedaży stacjonarnej: wycenia zakup, tworzy żądanie płatności, przypisuje otrzymaną płatność i zachowuje zapis. Może działać na telefonie, tablecie lub terminalu; wygląd urządzenia nie określa, kto kontroluje monety.

Obsługa wybiera produkty lub wpisuje kwotę, sprawdza walutę, napiwek i sumę końcową. BTCPay Server oferuje katalog, koszyk i klawiaturę numeryczną. Każdy zakup powinien być identyfikowalny przez zamówienie i fakturę; ponowne otwarcie ekranu nie może tworzyć drugiego zapisu sprzedaży. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]

Cena w lokalnej walucie jest przeliczana według skonfigurowanego źródła kursu; kasa musi pokazać oczekiwaną kwotę bitcoina i ważność oferty. BOLT 11 zawiera dane faktury Lightning, w tym hash płatności i termin wygaśnięcia; kwota może być opcjonalna. Przy konkretnym zakupie trzeba zweryfikować rzeczywistą kwotę, sieć i odbiorcę. Przeliczenie ceny nie oznacza sprzedaży bitcoina za walutę fiat. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]

Kod QR tylko przekazuje dane płatności. Zrzut ekranu klienta nie zastępuje statusu w systemie sprzedawcy. W BTCPay Server Processing czeka na wybrane potwierdzenia on-chain; Settled oznacza spełnienie zasad, ale może też zostać ustawiony ręcznie. Udana płatność Lightning nie czeka na potwierdzenie bloku. Wydanie towaru opiera się więc na zweryfikowanej płatności, nie tylko na kolorze ekranu. [BTCPay Server — Invoice lifecycle]

Ten sam tablet może kierować wpływy do własnego portfela lub korzystać z dostawcy powierniczego. Decydują klucze, uprawnienia i warunki wypłaty, nie logo Bitcoin. Nawet odbiór przez klucz publiczny nie wyklucza podmiany przyszłego adresu przez przejętą kasę lub serwer. Oddziel uprawnienia kasjera od zmiany odbiorcy, zarządzania portfelem i zatwierdzania zwrotów. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]

Własny węzeł Lightning wymaga utrzymania, kanałów i płynności przychodzącej. Dostawca może przejąć część pracy, lecz zmienia koszty i zaufanie. Błąd routingu lub brak płynności nie jest udaną płatnością. Przed zmianą metody płatności obsługa sprawdza wynik pierwotnej próby, aby uniknąć dwóch opłat za jeden zakup. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]

Niedostępny internet, backend lub źródło kursu może uniemożliwić nowe żądanie albo weryfikację wpływu. Wyświetlony lub wydrukowany kod może pozostać czytelny bez aktualnego statusu. Procedura powinna określać łącze zapasowe, odłożenie sprzedaży i późniejsze odszukanie płatności. Niedopłaty, nadpłaty i wpłaty po wygaśnięciu oceniaj osobno; ręczna zmiana statusu nie zmienia historii sieci. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]

Zwrot wymaga powiązania z pierwotnym zakupem, uzgodnionej kwoty i waluty, sprawdzonego celu oraz zatwierdzenia przez uprawnioną osobę. BTCPay Server oddziela utworzenie żądania zwrotu od wysłania wypłaty. Pierwotny przelew nie zostaje usunięty. Obsługa musi odróżniać utworzone żądanie, oczekującą wypłatę i rzeczywiście ukończony zwrot. [BTCPay Server — Refund workflow]

Na koniec zmiany uzgodnij zamówienia, otrzymane płatności, opłaty, zwroty i ewentualne wypłaty dostawcy. BTCPay Server eksportuje raporty płatności, sprzedanych produktów i portfela on-chain; sam eksport nie gwarantuje spełnienia lokalnych wymagań księgowych i podatkowych. Przetestuj działania obsługi, awarie i odtwarzanie, ogranicz dostęp do danych klientów oraz uwzględnij koszty urządzeń, łącza i utrzymania. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]

Przykład · ₿·POS

Dwa ekrany, jeden zakup

Przy przykładowym zamówieniu POS-497 klient pokazuje udaną płatność, ale tablet obsługi traci połączenie. Obsługa nie oznacza automatycznie zakupu jako nieopłaconego i nie wystawia od razu drugiego żądania. Przywraca połączenie, odnajduje pierwotną fakturę i sprawdza jej kwotę oraz rzeczywisty status wpływu. Dopiero wtedy decyduje o wydaniu towaru lub kolejnej próbie i zapisuje wynik przy tym samym zamówieniu.

Pełniejszy obraz uzyskasz, czytając to hasło razem z Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Potwierdzenie, Bitcoin. Do tego hasła prowadzą również odsyłacze z Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.

01Czy przy kasie wystarczy kod QR?

Kod przekazuje dane płatności, ale sam nie weryfikuje wpływu ani nie przypisuje płatności do zakupu. Kasa potrzebuje wiarygodnego statusu płatności i procedury na wypadek błędnej kwoty, wygaśnięcia i braku połączenia.

02Czy płatność Lightning zawsze oznacza samodzielne przechowywanie środków przez sprzedawcę?

Nie. Kasa może korzystać z własnego węzła, innego modelu usługi lub dostawcy powierniczego. Sprawdź, kto kontroluje klucze i saldo, kto zapewnia odbiór oraz na jakich warunkach można wypłacić środki.

DOC · 001BTCPay Server — Point of Sale appDokumentacja ↗DOC · 002BTCPay Server — Invoice lifecycleDokumentacja ↗DOC · 003BTCPay Server — Store rates and policiesDokumentacja ↗DOC · 004Lightning BOLTs — Invoice protocolSpecyfikacja ↗DOC · 005BTCPay Server — Wallet setupDokumentacja ↗DOC · 006BTCPay Server — Third-party hosting risksDokumentacja ↗DOC · 007BTCPay Server — Lightning setupDokumentacja ↗DOC · 008BTCPay Server — Refund workflowDokumentacja ↗DOC · 009BTCPay Server — ReportingDokumentacja ↗
Najpierw źródła · To nie jest porada inwestycyjna