ALLE SYSTEME BETRIEBSBEREIT 14 REGIONEN · 1.2 TBPS SCHUTZSCHILD AUFLADEN MIT BTC · XMR · LTC · ETH · USDT +3 COINS

ANLEITUNGEN

Wie Sie mit BTCPay Server selbst Bitcoin-Zahlungen annehmen

11 Min. Lesezeit

Wie Sie mit BTCPay Server selbst Bitcoin-Zahlungen annehmen

Jeder gehostete Zahlungsdienstleister ist ein Unternehmen, das Sie einfrieren kann. Das ist keine Hypothese für irgendjemanden, der Bitcoin annimmt: Die großen Zahlungsdienstleister haben vor Jahren Identitätsprüfungen, Auszahlungsschwellen und Abwicklungsregeln eingeführt, und ein Händler, der bei einer dieser Prüfungen durchfällt, erfährt das meist erst, wenn das Geld schon unterwegs ist. Genau deshalb gibt es BTCPay Server. Es ist freie, quelloffene Software, die einen Server, den Sie selbst kontrollieren, in Ihren eigenen Checkout verwandelt — Rechnungen, einen Point-of-Sale-Bildschirm, Store-Plugins, Lightning — ganz ohne Unternehmen dazwischen, ohne abgezogene Prozente und ohne Konto, das Sie verlieren könnten. Die Installation ist wirklich an einem einzigen Nachmittag erledigt. Was darüber entscheidet, ob das Ergebnis taugt, ist die Maschine darunter — und die Handvoll Details, die eine Standardinstallation still und leise auf Sie zurückweisen lässt.

Was BTCPay Server tatsächlich ersetzt

Ein gehosteter Zahlungsdienstleister sitzt zwischen Ihrem Kunden und Ihrer Wallet. Er erzeugt die Adresse, beobachtet die Chain, rechnet den Betrag um, hält die Gelder eine gewisse Zeit und zahlt sie Ihnen schließlich aus. Bei jedem dieser Schritte erfährt er etwas über Sie, und jeder ist ein Punkt, an dem er ablehnen kann. BTCPay erledigt dieselbe Arbeit auf Hardware, die Sie selbst mieten, und der Unterschied darin, was es über Sie weiß, ist vollständig.

  • Zahlungen landen direkt in Ihrer eigenen Wallet. Sie geben BTCPay einen erweiterten öffentlichen Schlüssel, es leitet daraus für jede Rechnung eine frische Adresse ab und beobachtet sie — für On-Chain-Zahlungen hält es niemals einen privaten Key und kann keinen einzigen Satoshi bewegen.
  • Es gibt keine Gebühr und kein Konto. Die Software ist quelloffen, Sie betreiben sie selbst, es gibt nichts zu beantragen und nichts, wovon Sie gesperrt werden könnten.
  • Es übernimmt die Teile, die mühsam selbst zu bauen wären: Ablauf von Rechnungen, Kursumrechnung in Echtzeit, Unter- und Überzahlungen, Teilzahlungen, Rückerstattungen und eine Quittung, die der Kunde unabhängig prüfen kann.
  • Es liefert die Oberflächen, die die meisten Leute brauchen — einen Point-of-Sale-Bildschirm, Pay-Buttons, eine Crowdfunding-Seite, Plugins für die gängigen E-Commerce-Plattformen — und eine vollständige API, wenn Sie es in Ihre eigene Software einbinden.
  • Lightning ist auf Wunsch im selben Deployment enthalten, und das ist überhaupt erst das, was Zahlungen unter ein paar Dollar praktikabel macht.

Diese Grenze sollte man klar benennen. BTCPay verwandelt Bitcoin nicht in Ihre Landeswährung, und es beseitigt weder die Börse noch die Bank, wenn das Geld am Ende dorthin muss. Was es beseitigt, ist der Zahlungsdienstleister — der Vermittler, der eine Provision einbehielt, Ihre Gelder zwischenzeitlich hielt und dafür Ihre Identität verlangte. Was Sie dafür bekommen, hat dieselbe Form wie eine Website, die Sie selbst hosten: mehr Kontrolle, und die Arbeit, die damit einhergeht.

Sie werden selbst zum Zahlungsdienstleister

Diese Arbeit ist der ehrliche Preis des Self-Hostings, und den versteht man sich besser vor der Installation klarzumachen als danach. Niemand überwacht Ihre Uptime, niemand stellt Ihr Backup wieder her, und niemand sitzt am anderen Ende einer Support-Leitung, wenn ein Kunde darauf beharrt, bezahlt zu haben, und Sie es nicht sehen können.

  • Die Uptime ist Ihre Sache. Solange der Server offline ist, kann keine Rechnung erstellt werden — ein Checkout, der immer funktionieren muss, braucht also eine Maschine, die auch wirklich jemand überwacht.
  • Backups sind Ihre Sache. Den Server zu verlieren ist verkraftbar; den Wallet-Deskriptor oder den Lightning-Kanalzustand zu verlieren nicht.
  • Die Verwahrung der Keys teilt sich in zwei Teile. On-Chain-Gelder liegen in einer Wallet, die BTCPay nur beobachtet — das ist die sichere Variante. Lightning-Gelder liegen in einer Hot-Wallet auf dem Server selbst, was sie nicht ist — behandeln Sie diesen Betrag als Betriebsguthaben, niemals als Ersparnisse.
  • Streitfälle haben keinen Schlichter. Es gibt keine Chargebacks, was großenteils der Sinn der Sache ist, bedeutet aber auch, dass jede Rückerstattung eine Entscheidung ist, die Sie treffen, und eine Transaktion, die Sie selbst versenden.
  • Updates sind Ihre Sache. Unter der freundlichen Oberfläche steckt ein Stack aus Containern mit einem Bitcoin-Node darin, und der braucht dieselbe Wartungsdisziplin wie alles andere, das auf einer öffentlichen IP läuft.

Nichts davon ist schwer. Es sind ein paar Minuten im Monat, sobald das Ganze läuft, plus ein sorgfältiger Nachmittag am Anfang. Es ist schlicht nicht null — und eine Zahlungsdienstleister-Gebühr hat bislang genau dafür mitbezahlt.

Die Maschine dimensionieren: Der Node darunter entscheidet über alles

BTCPay selbst ist eine leichte Anwendung. Der Bitcoin-Node, gegen den es läuft, ist es nicht, und fast jeder Dimensionierungsfehler hier entsteht dadurch, dass man für die Webanwendung budgetiert statt für die Chain darunter. Ein Standard-Deployment bringt Bitcoin Core, einen Indexer, der Ihre Wallets im Blick behält, eine Datenbank, einen Reverse-Proxy und die Anwendung selbst hoch — und es ist Core, das die Festplatte, den Arbeitsspeicher und die Geduld beansprucht.

  • Storage ist die Entscheidung, die Ihren Plan festlegt. Eine ungeprunte Chain liegt heute bei über 750 GB und wächst um etwa 7 GB im Monat. Das Deployment bringt stattdessen speichersparende Presets mit, die die Blockdaten auf etwa 100, 50 oder 25 GB begrenzen, und jedes davon ist trotzdem ein echter vollständiger Node, der jede Regel selbst verifiziert.
  • Pruning verkürzt die Erstsynchronisierung nicht. Core lädt so oder so jeden Block seit Genesis herunter und prüft ihn; Pruning entscheidet nur, was danach aufbewahrt wird.
  • Arbeitsspeicher ist die Quelle der Sync-Geschwindigkeit. Mit 4 GB läuft es, mit 8 GB synchronisiert es merklich schneller und lässt Raum für Lightning und eine Datenbank, die dem Node nicht um den Cache streitig macht.
  • NVMe ist keine Option, sondern Pflicht. Die Erstsynchronisierung wird von zufälligen Lese- und Schreibzugriffen auf die UTXO-Datenbank dominiert, sodass dieselbe Aufgabe auf einer langsamen Festplatte Tage statt Stunden braucht.
  • Bandbreite ist unauffällig, sobald Sie synchron sind, aber die Erstsynchronisierung lädt die gesamte Chain herunter. Ein gemessener Plan ist dafür die falsche Form.

In der Praxis ist der VPS-8 für $13.99/mo — 4 vCPU EPYC, 8 GB DDR5 ECC und 120 GB Gen4-NVMe — der vernünftige Standard für einen Pruned-Node mit Lightning, mit dem VPS-16 für $26.99/mo als Option, falls Sie nie wieder an die Festplatte denken wollen. Jede VPS-Stufe kommt mit Gen4-NVMe im RAID-10 und unmetered Transfer, sodass die Kapazität die einzige wirkliche Variable ist. Wenn Sie die Chain ungeprunt wollen — um eine alte Wallet erneut zu scannen oder um neben dem Store einen Electrum-Server zu betreiben —, lassen Sie die VPS-Reihe ganz aus: Ein dedizierter Server ab $64/mo mit 2 × 1 TB NVMe ist zugleich günstiger und deutlich geräumiger als der größte VPS, und die Rechnung wird mit der Zeit nur schlechter. Es sind dieselben Kompromisse wie beim Betreiben eines vollständigen Bitcoin-Node, denn genau das tun Sie hier — nur mit einem Checkout obendrauf.

Pruning hat eine Konsequenz, der die meisten viel zu spät begegnen: Ein Pruned-Node kann die Chain nicht weiter zurückscannen als bis zu den Blöcken, die er noch besitzt. Richten Sie BTCPay auf eine bereits bestehende Wallet mit Historie aus, werden diese älteren Zahlungen schlicht nicht gefunden. Starten Sie den Store mit einem frischen Konto, oder betreiben Sie den Node ungeprunt.

Schritt für Schritt: von einem frischen VPS zum laufenden Checkout

  1. 01Den VPS bereitstellen und zuerst absichernEine Debian- oder Ubuntu-Box, SSH ausschließlich per Schlüssel, eine Default-Deny-Firewall — bevor irgendetwas Wertvolles darauf liegt. Die geordnete Fassung dieser Checkliste ist eine eigene Anleitung.
  2. 02Eine Domain auf den Server zeigen lassen und 80 sowie 443 öffnenBTCPay stellt beim ersten Start sein eigenes Zertifikat aus, was nur funktioniert, wenn der Hostname bereits auf die Maschine auflöst und beide Ports erreichbar sind. Diese Reihenfolge zu vertauschen ist mit weitem Abstand die häufigste fehlgeschlagene Installation.
  3. 03Das offizielle Docker-Deployment klonenDas Projekt liefert ein vorgegebenes Container-Setup. Nutzen Sie es, statt die Teile von Hand zusammenzusetzen — genau dagegen wird der Upgrade-Pfad getestet.
  4. 04Die Optionen vor dem ersten Start festlegenNetzwerk, Hostname, Lightning-Implementierung und Storage-Preset sind Umgebungsvariablen, die nur einmal beim Setup gelesen werden. Das Pruning-Level nachträglich zu ändern ist nicht kostenlos — entscheiden Sie also jetzt.
  5. 05Das Setup-Skript ausführen und synchronisieren lassenAlles fährt in Containern hoch, und Bitcoin Core beginnt mit seinem Initial Block Download. Das ist der lange Teil — mehrere Stunden auf NVMe — und der eine Schritt, den Sie nicht beschleunigen können.
  6. 06Sofort das Admin-Konto registrierenDas erste Konto, das sich registriert, wird zum Administrator. Erledigen Sie das in dem Moment, in dem die Oberfläche antwortet, nicht erst am nächsten Morgen.
  7. 07Eine Wallet an Ihren Store anbindenLegen Sie einen Store an und verbinden Sie dann eine Wallet, indem Sie einen erweiterten öffentlichen Schlüssel von einer Hardware-Wallet oder einem dedizierten Konto in Ihrer eigenen Software importieren. BTCPay beobachtet die Adressen; es signiert niemals etwas.
  8. 08Mit einer echten Zahlung testen, dann die Oberfläche anbindenSenden Sie sich selbst einen kleinen Betrag und bestätigen Sie, dass die Rechnung beglichen wird. Erst danach binden Sie den Point-of-Sale-Bildschirm, das Store-Plugin oder die API an, die Ihre Seite tatsächlich aufrufen wird.
Verbinden Sie die Wallet mit einem erweiterten öffentlichen Schlüssel, niemals mit einer Seed-Phrase. Ein xpub lässt BTCPay Adressen ableiten und Zahlungen erkennen; ein Seed würde eine öffentlich erreichbare Webanwendung in eine Hot-Wallet verwandeln, die alles hält, was Sie jemals ausgezahlt bekommen haben. Das gesamte Sicherheitsmodell der On-Chain-Seite hängt an genau dieser einen Entscheidung.

Lightning: lohnenswert, und was es tatsächlich kostet

On-Chain-Zahlungen funktionieren überall und kosten das, was der Mempool an dem Tag gerade verlangt, was alles unter ein paar Dollar umständlich und manchmal absurd macht. Lightning behebt das, und BTCPay richtet Ihnen dafür im selben Deployment einen Node ein. Für kleine oder häufige Zahlungen ist es die richtige Antwort. Es ist aber auch eine betriebliche Verpflichtung anderer Art als ein Bitcoin-Node, und es lohnt sich, die Unterschiede zu kennen, bevor Sie es einschalten.

  • Sie brauchen eingehende Liquidität, bevor Sie bezahlt werden können. Einen eigenen Kanal zu öffnen verschafft Ihnen Kapazität zum Ausgeben, nicht zum Empfangen. Bis jemand einen Kanal zu Ihnen hin öffnet oder Sie sich eingehende Kapazität beschaffen, kann Ihr Node überhaupt nichts annehmen.
  • Das Guthaben ist per Design hot. Kanalgelder liegen in einer Wallet auf dem Server, online, weil sie es sein müssen. Lassen Sie dort nur laufendes Betriebsguthaben liegen und verschieben Sie den Rest on-chain.
  • Der Kanalzustand lässt sich nicht durch Kopieren von Dateien sichern. Einen alten Snapshot eines Lightning-Node wiederherzustellen kann Sie genau die Kanäle kosten, die er beschreibt. Nutzen Sie den eigenen Backup-Mechanismus der Implementierung und verstehen Sie, was er tatsächlich wiederherstellt.
  • Downtime kostet hier mehr als on-chain. Ein Offline-Node kann nicht routen oder empfangen, und ein veralteter Zustand, der wieder online geht, kann bestraft werden.
  • Kanäle verursachen an beiden Enden On-Chain-Kosten. Öffnen und Schließen sind Transaktionen, sodass die Angewohnheit vieler kleiner Kanäle still und leise teuer wird.
  • Ihr Node ist sichtbar, wenn Sie es zulassen. Ein öffentlich angekündigter Node sendet seinen Alias und seine Netzwerkadresse an alle, wodurch Ihr Server auf einer Karte landet, die jeder lesen kann.

Ein vernünftiger Mittelweg ist Lightning mit unangekündigten Kanälen — Sie können bezahlt werden, ohne Ihre Infrastruktur zu veröffentlichen — und On-Chain als Standard für alles Größere. Wenn Sie den Node erreichbar haben wollen, ohne zuordenbar zu sein, betreiben Sie ihn über Tor — dieselbe Überlegung, die auch einen Bitcoin-Node hinter einen Onion-Service statt eine öffentliche IP stellt.

Die Identitätslecks, die eine Standardinstallation offenlässt

Dieser Abschnitt zählt, wenn Sie sich für BTCPay gerade deshalb entschieden haben, um einem Zahlungsdienstleister zu entkommen, der wusste, wer Sie sind. Die Software entfernt diesen Zahlungsdienstleister vollständig. Sie entfernt von sich aus aber nicht alles andere, was den Checkout mit einer Person verknüpft — und das meiste davon stammt aus Schritten, die sich völlig losgelöst von Zahlungen anfühlen.

  • Die Domain. Ein Registrar verwahrt Ihre Identität, selbst wenn das öffentliche WHOIS geschwärzt ist, und braucht eine funktionierende Adresse, um den Namen am Leben zu halten. Der Hostname ist der mit Abstand häufigste Weg, wie ein selbstgehosteter Checkout zu seinem Besitzer zurückverfolgt wird.
  • Certificate Transparency. In dem Moment, in dem ein Zertifikat ausgestellt wird, wird der exakte Hostname in öffentlichen Logs veröffentlicht, die jeder durchsuchen kann. Eine Subdomain, von der Sie annahmen, sie sei privat — pay.irgendwas, btcpay.irgendwas — wird weltweit mit Zeitstempel bekanntgegeben.
  • Der Host. Wurde der Server mit einer Karte auf Ihren echten Namen gekauft, läuft die Maschine auf Ihren echten Namen, ganz gleich, was darauf läuft. Das entscheidet sich bei der Anmeldung, lange vor der ersten Rechnung.
  • Der erweiterte öffentliche Schlüssel. Geben Sie BTCPay einen xpub, kann es jede Adresse beobachten, die dieser Schlüssel ableitet — samt Guthaben und Historie, die Sie nie einer Webanwendung offenlegen wollten. Verwenden Sie für den Store ein eigenes Konto, niemals den xpub Ihrer Haupt-Wallet.
  • Der Lightning-Node. Ein angekündigter Node veröffentlicht einen Alias und eine Adresse. Ein Alias, der Ihre Marke trägt, auf einer IP, die auch Ihren Checkout bedient, verknüpft beides dauerhaft in einem öffentlichen Graphen.
  • Ausgehende Verbindungen. Kursanbieter, Plugins und Benachrichtigungsintegrationen greifen allesamt von der Maschine aus nach außen, und E-Mail-Benachrichtigungen laufen über das SMTP-Konto, das Sie konfiguriert haben. Jeder Einzelne davon ist ein Dritter, der Ihren Server sieht.
  • Der Auszahlungsweg. Coins, die den Store in Richtung eines verifizierten Börsenkontos verlassen, kommen mit ihrer Historie im Schlepptau an. Dieses Leck liegt hinter BTCPay, und es ist dasjenige, das am häufigsten die ganze Sorgfalt zunichtemacht, die davor aufgewendet wurde.
Die nützliche Sichtweise ist: BTCPay entfernt den Mittelsmann aus der Zahlung, nicht aus dem Rest des Stacks. Ein selbstgehosteter Checkout ist immer nur so privat wie das am wenigsten private Ding, von dem er abhängt — die Domain, der Host, und wohin das Geld als Nächstes geht.

Das zu schließen ist gewöhnliche Arbeit, nichts Exotisches. Wählen Sie einen Registrar, der Krypto akzeptiert und das Minimum erhebt, und geben Sie ihm eine Adresse, die nicht mit Ihrer Identität verknüpft ist. Bringen Sie die Maschine bei einem Host, der nie gefragt hat, wer Sie sind, unter und bezahlen Sie sie aus einem Krypto-Guthaben — Bitcoin ist pseudonym, nicht anonym, weshalb das Aufladen in Monero die On-Chain-Spur schließt, falls Ihnen das wichtig ist. Und erreichen Sie die Admin-Oberfläche über einen WireGuard-Tunnel, statt eine Login-Seite für etwas offenzulegen, das Geld hält. Jedes davon ist eine kleine, einmalig getroffene Entscheidung; zusammen machen sie den Unterschied zwischen "kein Zahlungsdienstleister" und wirklich privat.

Den Checkout nach dem Start am Laufen halten

Ein Checkout, der seit einem Jahr funktioniert, ist ein Checkout, den seit einem Jahr niemand mehr angeschaut hat. Eine kurze Wartungsroutine verhindert, dass daraus ausgerechnet an Ihrem stärksten Tag ein Ausfall wird.

  • Aktualisieren Sie im Rhythmus des Projekts, nicht in Ihrem eigenen. Das Deployment hat einen Upgrade-Pfad, der zusammengehörige Container-Versionen gemeinsam bewegt; Teile von Hand hochzuziehen ist der Weg, wie aus einem funktionierenden Stack ein kaputter wird.
  • Sichern Sie, was sich nicht neu erzeugen lässt: die Store-Datenbank und -Konfiguration, den Wallet-Deskriptor und das Lightning-Backup, falls Sie eines betreiben. Die Blockchain ist kein Backup — sie lädt sich erneut herunter.
  • Stellen Sie einmal bewusst wieder her, während nichts kaputt ist. Ein ungetestetes Backup eines Zahlungssystems ist eine Vermutung über Ihren Umsatz.
  • Behalten Sie die Festplatte im Blick. Ein Pruned-Node hat einen stabilen Speicherbedarf, Logs und Datenbanken aber nicht, und eine volle Festplatte stoppt den Node, was die Rechnungen stoppt.
  • Halten Sie die Maschine gepatcht und die Ports geschlossen. Alles auf der Härtungs-Checkliste für die ersten zehn Minuten gilt auch hier, nur mit deutlich mehr auf dem Spiel.

Richten Sie dabei gleich eine externe Prüfung für den Store ein. Etwas so Einfaches wie ein Monitor, der den Rechnungs-Endpunkt von außen anspricht, sagt Ihnen, dass der Checkout ausgefallen ist, bevor es ein Kunde tut — das ist der Großteil des praktischen Unterschieds zwischen Self-Hosting und Unerreichbarkeit. Und behandeln Sie die Box selbst so, wie es die ersten zehn Minuten auf einem neuen VPS beschreibt, denn auf einer Maschine, die Geld hält, steht mehr auf dem Spiel.

Fehler, die echtes Geld kosten

  • Eine Seed-Phrase statt eines erweiterten öffentlichen Schlüssels importieren und damit eine öffentliche Webanwendung in eine Hot-Wallet verwandeln, die jede jemals empfangene Zahlung hält.
  • DNS erst nach dem Installer konfigurieren und sich dann wundern, warum das Zertifikat nie ausgestellt wurde und die Seite nicht lädt.
  • Das aggressivste Pruning-Preset wählen und danach versuchen, eine Wallet mit jahrelanger Historie anzubinden, die der Node nicht mehr zurückscannen kann.
  • Das Lightning-Guthaben wie Ersparnisse behandeln statt wie Betriebsguthaben, das zufällig online liegt.
  • Einen Lightning-Node sichern, indem man sein Datenverzeichnis kopiert, und annehmen, das sei ein funktionierender Wiederherstellungsweg.
  • Einen Plan kaufen, der für die Webanwendung dimensioniert ist, und mitten in der Erstsynchronisierung die Festplatte volllaufen lassen.
  • Die Admin-Oberfläche für das gesamte Internet offen lassen, geschützt nur durch ein Passwort, das schon anderswo verwendet wurde.
  • Die Domain registrieren und den Server auf den eigenen Namen mieten, nachdem man alles andere richtig gemacht hat.

BTCPay ist eine der wenigen Software-Lösungen, die einen Mittelsmann rundweg entfernt, statt ihn durch einen freundlicheren zu ersetzen. Die Installation dauert einen Nachmittag, die Synchronisierung eine Nacht. Was übrig bleibt, ist ein Checkout, der Bitcoin und Lightning annimmt, nichts berechnet, nichts verwahrt und niemandem Rechenschaft schuldet — und der auf einer Maschine läuft, die Sie aus demselben Guthaben bezahlen können, das sie einnimmt. Dimensionieren Sie die Festplatte für den Node, halten Sie den Seed vom Server fern, und stellen Sie die Box irgendwo hin, wo nie nach Ihrem Namen gefragt wurde.

Bereit, es auszuprobieren?Offshore-VPS bereitstellen ab $3.99/Mon. — ohne KYC, bezahlt in Krypto. Jetzt starten