Bitcoin Point of Sale ist eine Kassenschnittstelle für den Verkauf vor Ort: Sie berechnet den Kaufpreis, erstellt eine Zahlungsanforderung, ordnet den Zahlungseingang zu und führt einen Nachweis. Sie kann auf Telefon, Tablet oder Terminal laufen; das Aussehen des Geräts bestimmt nicht, wer die Coins kontrolliert.
Die Bedienung wählt Waren aus oder gibt einen Betrag ein und prüft Währung, Trinkgeld und Endsumme. BTCPay Server bietet Katalog, Warenkorb und Zifferntastatur. Jeder Kauf sollte über Bestellung und Rechnung nachvollziehbar sein; erneutes Öffnen des Bildschirms darf keinen zweiten Verkaufsdatensatz erzeugen. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
Ein Preis in Landeswährung wird anhand der eingestellten Kursquelle umgerechnet; die Kasse muss den erwarteten Bitcoin-Betrag und die Gültigkeit des Angebots anzeigen. BOLT 11 enthält Daten der Lightning-Rechnung einschließlich Payment Hash und Ablaufzeit; der Betrag kann optional sein. Für einen konkreten Kauf müssen tatsächlicher Betrag, Netzwerk und Empfänger geprüft werden. Preisumrechnung bedeutet keinen Verkauf von Bitcoin gegen Fiatgeld. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
Ein QR-Code übermittelt nur Zahlungsdaten. Ein Screenshot des Kunden ersetzt nicht den Status im Händlersystem. Bei BTCPay Server wartet Processing auf die gewählten on-chain Bestätigungen; Settled bedeutet, dass die Vorgaben erfüllt sind, kann aber auch manuell gesetzt sein. Eine erfolgreiche Lightning-Zahlung wartet nicht auf eine Blockbestätigung. Die Warenausgabe richtet sich daher nach einer verifizierten Zahlung und nicht nur nach der Bildschirmfarbe. [BTCPay Server — Invoice lifecycle]
Dasselbe Tablet kann Eingänge an die eigene Wallet leiten oder einen verwahrenden Anbieter nutzen. Entscheidend sind Schlüssel, Berechtigungen und Auszahlungsbedingungen, nicht das Bitcoin-Logo. Selbst der Empfang über einen öffentlichen Schlüssel schließt nicht aus, dass eine kompromittierte Kasse oder ein Server eine künftige Adresse ersetzt. Trennen Sie Bedienungsrechte vom Ändern des Empfängers, der Wallet-Verwaltung und der Freigabe von Erstattungen. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Ein eigener Lightning-Knoten benötigt Betrieb, Kanäle und eingehende Liquidität. Ein Anbieter kann einen Teil der Arbeit übernehmen, verändert aber Kosten und Vertrauen. Ein Routingfehler oder fehlende Liquidität ist keine erfolgreiche Zahlung. Vor einem Wechsel der Zahlungsmethode prüft die Bedienung das Ergebnis des ursprünglichen Versuchs, damit nicht zweimal für einen Kauf bezahlt wird. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
Fehlendes Internet, Backend oder Kursquelle kann eine neue Anforderung oder die Eingangsprüfung verhindern. Ein angezeigter oder gedruckter Code kann ohne aktuellen Status lesbar bleiben. Der Betriebsablauf sollte Ersatzverbindung, Aufschub des Verkaufs und spätere Zahlungssuche festlegen. Unterzahlungen, Überzahlungen und Zahlungen nach Ablauf sind einzeln zu prüfen; eine manuelle Statusänderung verändert nicht die Netzwerkhistorie. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Eine Rückzahlung erfordert die Zuordnung zum ursprünglichen Kauf, einen vereinbarten Betrag und eine Währung, ein geprüftes Ziel und eine berechtigte Freigabe. BTCPay Server trennt das Erstellen einer Erstattungsanforderung vom Senden der Auszahlung. Die ursprüngliche Übertragung wird dadurch nicht gelöscht. Die Bedienung muss zwischen erstellter Anforderung, ausstehender Auszahlung und tatsächlich abgeschlossener Erstattung unterscheiden. [BTCPay Server — Refund workflow]
Gleichen Sie am Schichtende Bestellungen, Zahlungseingänge, Gebühren, Erstattungen und mögliche Anbieterauszahlungen ab. BTCPay Server exportiert Berichte zu Zahlungen, verkauften Produkten und der on-chain Wallet; ein Export allein garantiert nicht die Erfüllung örtlicher Buchführungs- und Steueranforderungen. Testen Sie Bedienungsabläufe, Ausfälle und Wiederherstellung, beschränken Sie Kundendatenzugriff und berücksichtigen Sie Geräte-, Verbindungs- und Betriebskosten. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Zwei Bildschirme, ein Kauf
Bei der beispielhaften Bestellung POS-497 zeigt der Kunde eine erfolgreiche Zahlung, doch das Tablet der Bedienung verliert die Verbindung. Die Bedienung markiert den Kauf nicht automatisch als unbezahlt und erstellt nicht sofort eine zweite Anforderung. Sie stellt die Verbindung wieder her, findet die ursprüngliche Rechnung und prüft Betrag und tatsächlichen Eingangsstatus. Erst dann entscheidet sie über Warenausgabe oder erneuten Versuch und dokumentiert das Ergebnis bei derselben Bestellung.
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Bestätigung, Bitcoin. Auf diesen Eintrag verweisen außerdem Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Reicht ein QR-Code an der Kasse?+
Der Code übermittelt Zahlungsdaten, prüft aber selbst weder den Eingang noch die Zuordnung zum Kauf. Die Kasse braucht einen verlässlichen Zahlungsstatus und einen Ablauf für falsche Beträge, abgelaufene Anforderungen und fehlende Verbindung.
02Bedeutet eine Lightning-Zahlung immer Selbstverwahrung des Händlers?+
Nein. Die Kasse kann einen eigenen Knoten, ein anderes Dienstmodell oder einen verwahrenden Anbieter verwenden. Prüfen Sie, wer Schlüssel und Guthaben kontrolliert, wer den Empfang sicherstellt und unter welchen Bedingungen Geld abgezogen werden kann.