Konfiguration

• Einstellungen
• Status & Zahlung
• Logs
• Wartung

Einstellungen

Im Tab „Konfiguration“ werden alle zentralen Funktionen des Bitcoins-Moduls verwaltet. Hier legen Sie fest, wie die Bitcoin-Zahlung im Checkout dargestellt wird, welche Zahlungsinformationen Kunden erhalten und welche Statusabläufe nach Bestellung automatisch ausgeführt werden. Darüber hinaus können Zahlungsdetails, QR-Code-Darstellung und Beschreibungstexte angepasst werden, um den Bezahlvorgang transparent und komfortabel zu gestalten.

Empfängeradresse

Hinterlegt die Bitcoin-Adresse der Kunden an die, die Zahlung gesendet werden soll. Alternativ kann das Feld leer bleiben, wenn stattdessen eine Silent-Payment-Adresse verwendet wird.

Beispiel (klassische Bitcoin-Empfängeradresse im Bech32-Format):

---

Silent Payment Adresse 

Hinterlegt den öffentlichen Silent-Payment-Schlüssel (64-stelliger Hex-Wert), der von kompatiblen Wallets genutzt wird, um automatisch individuelle Empfangsadressen abzuleiten.

Beispiel (Silent-Payment Empfängeradresse in Dana Wallet konfiguriert - Bech32m-kodiert):

Darstellung eines Silent-Payment-QR-Codes im Front Office auf der Bestellbestätigungsseite

Klassische Bitcoin-Empfängeradressen

Klassische Bitcoin-Adressen dienen als öffentliche Zieladressen für den Empfang von BTC. Es gibt drei Hauptformate:

Diese Adressen sind öffentlich sichtbar und jede Transaktion an diese Adresse ist in der Blockchain direkt zuordenbar.

Silent Payment Empfangsadressen (BIP-0352)

Silent Payments sind ein besonders datenschutzfreundlicher Adresstyp, bei dem:

• keine wiederverwendbare BTC-Adresse veröffentlicht wird,

• jede Zahlung automatisch auf einer neuen Zieladresse eingeht,

• der Empfänger Zahlungen durch Scan der Blockchain erkennt – ohne Onchain-Verknüpfung.

Aufbau:

Silent Payments nutzen keinen klassischen Bitcoin-Adress-String, sondern einen sogenannten Scan-PubKey (auch: x-only Public Key). Dieser wird in folgendem Format veröffentlicht:

silent:pubkey=f3c1d4b8e5a1c0d2b7f98ab3d378ff45a56739c0d59d3e49d23e89dd1b35c3af

• Der Schlüssel besteht aus 32 Byte und wird hexadezimal kodiert (64 Zeichen).

• Alternativ verwenden viele Wallets das kompaktere Format mit sp1...-Präfix (Bech32m-kodiert).

• Beide Formate sind gleichwertig – die Unterstützung hängt von der verwendeten Wallet ab.

Für den Empfänger:

• Veröffentlicht nur seinen Scan-PubKey (z. B. in einer der beiden Varianten).

• Erkennt eingehende Zahlungen durch regelmäßiges Scannen der Blockchain.

• Nutzt dazu eine Silent Payments-kompatible Wallet (z. B. Cake Wallet, Dana Wallet, SilentPay).

Für den Sender:

• Muss eine Wallet mit Silent Payments-Sendeunterstützung verwenden.

• Die Zieladresse wird automatisch berechnet und regulär als Taproot-Zahlung durchgeführt.

• Aktuell unterstützte Wallets: u. a. SilentPay, Dana Wallet, Cake Wallet, BitBox02 (nur senden).

---

Unterschiede im Überblick

Silent Payments erhöhen die Privatsphäre erheblich, ohne neue Coins oder zentrale Dienste einzuführen.
Sie basieren auf Taproot und sind vollständig Bitcoin-kompatibel, benötigen aber passende Wallets zur Nutzung.

Silent Payments – Wallet-Kompatibilitätstabelle

Wallet	📥 Empfangen	📤 Senden	Plattform	Hinweise
BitBox02	❌ Nein	✅ Ja	Hardware (Desktop App)	Nur Senden unterstützt (ab Firmware 9.21.0 / App 4.45.0)
BlueWallet	❌ Nein	❌ Nein	Android / iOS	Keine Taproot- oder SP-Unterstützung
Cake Wallet	❌ Nein	❌ Nein	Android / iOS	Kein SP-Fokus
Calke Wallet	✅ Ja	✅ Ja	Android (F-Droid)	Privacy-fokussiert, gute QR/Export-Tools
Dana Wallet	✅ Ja	✅ Ja	Android / Desktop (FOSS)	Aktive SP-Unterstützung, manuell installierbar über F-Droid
Electrum	❌ Nein	❌ Nein	Desktop	Kein offizieller SP-Support
Ledger Live	❌ Nein	❌ Nein	Desktop / Mobile	Kein SP-Support, Taproot vorhanden
Samourai Wallet	❌ Nein	❌ Nein	Android	Fokus auf CoinJoin, kein BIP-352
Shakesco Wallet	✅ Ja	✅ Ja	CLI / Dev Tool	Für technisch versierte Nutzer, CLI-basiert
SilentPay Wallet	✅ Ja	✅ Ja	Android (GitHub Build)	Open Source, vollen BIP-352 Support
Silentium Wallet	✅ Ja	✅ Ja	PWA (Browser)	Modernes Webinterface mit vollständigem SP-Support
Sparrow Wallet	🔄 Bald	🔄 Bald	Desktop	SP-Funktion in Entwicklung (teils via Script nutzbar)
Trezor	❌ Nein	❌ Nein	Hardware (Web App)	Kein Taproot-Support in Core → kein SP
Wasabi Wallet	❌ Nein	❌ Nein	Desktop	Fokus auf CoinJoin, kein SP geplant

Zahlung mit Bitcoin und QR-Codes auf der Bestellbestätigungsseite

Sollten beide Adressen im Modul konfiguriert sein, werden auf der Seite der Bestellbestätigung auch beide QR-Codes angezeigt:

In der Regel erkennt die Wallet beim Scannen des QR-Codes automatisch den Betrag (hier Dana Wallet für Android):

Status & Zahlung

Im Tab „Status & Zahlung“ wird festgelegt, wie die Bitcoin-Zahlung im Bestellprozess abgewickelt wird. Hier bestimmen Sie, welcher Bestellstatus zu welchem Zeitpunkt gesetzt wird, welche Informationen im Checkout angezeigt werden und wie die Zahlungsart visuell dargestellt wird. Dadurch kann der gesamte Zahlungsablauf klar strukturiert und vollständig automatisiert werden.

Bestellstatus, nachdem die Bestellung aufgegeben wurde

Legt fest, welcher Bestellstatus unmittelbar nach Abschluss der Bestellung gesetzt wird — noch bevor der Kunde die Zahlung ausführt.

---

Warten auf Zahlungseingang

Setzt den Bestellstatus automatisch auf „Warten auf Zahlungseingang“, nachdem der Kunde Bitcoin als Zahlungsart gewählt hat. 

---

Folgestatus "Warten auf Zahlungseingang"

Versendet optional eine zusätzliche E-Mail mit Zahlungsinformationen, sobald der Status „Warten auf Zahlungseingang“ aktiv ist.

---

Zahlungslogo anzeigen

Aktiviert die Anzeige des Bitcoin-Logos während der Zahlungsartauswahl im Checkout.

---

Logo-Zahlung

Ermöglicht das Hochladen eines eigenen Zahlungslogos (32 × 32 px).

---

Titel der Zahlungsart 

Texttitel der Bitcoin-Zahlung im letzten Schritt des Bestellabschlusses optional leer lassen, um ausschließlich das Logo anzuzeigen.

---

Beschreibung der Zahlungsart (DE/EN)

Zusatztext zur Erklärung der Bitcoin-Zahlung im Checkout; mehrsprachig pflegbar.

Logs

Moduleinstellungen

Im Tab "Logs" werden die vom Modul erstellten Protokolldateien verwaltet. Diese dienen zur Fehlerdiagnose, zur Nachverfolgung technischer Abläufe und zur Unterstützung bei Wartungsarbeiten.

Vorhandene Logs

Listet alle vom Modul erzeugten Log-Dateien mit Dateinamen, Erstellungsdatum, Dateigröße und der Option zum Löschen.

---

Log-Einstellungen

Hier wird das Log-Level definiert (z. B. Warnung, Fehler, Debug). Eine niedrigere Stufe als Warnung sollte nur für Debug-Zwecke verwendet werden, da sonst sehr große Log-Dateien entstehen können.

Wartung

Der Tab "Wartung" bietet Shopbetreibern eine Übersicht über die technische Integrität des Moduls. Er hilft dabei, mögliche Fehlerquellen zu identifizieren und fehlerhafte Installationen von Hooks, Menüeinträgen, Datenbankstrukturen oder Templates schnell zu beheben.

Hooks

Zeigt alle vom Modul verwendeten Hooks. Nicht eingetragene Hooks können per Klick nachinstalliert werden.

---

Registerkarten

Listet alle Backend-Menüeinträge mit den entsprechenden Berechtigungen (CRUD).

---

Datenbank

Prüft das SQL-Schema und zeigt Abweichungen von der aktuellen Datenbankstruktur.

---

Konfiguration 

Listet die Konfigurationswerte des Moduls. Fehlerhafte Werte können zurückgesetzt und fehlende Konfigurationen direkt installiert werden. 

---

Controller

Zeigt, ob für das Modul Controller installiert werden müssen. Optional können fehlende Controller installiert werden. 

---

Bestellstatus

Kontrolliert, ob spezielle Bestellstatus durch das Modul installiert werden. Optional können fehlende Bestellstatus installiert werden. 

---

Templates

Überprüft, ob die Front-Office-Templates korrekt installiert sind oder im Theme überschrieben wurden. Kritische Versionen werden entsprechend markiert. 

---

Plugins

Zeigt an, wenn weitere Plugins für dieses Moduls verfügbar sind.

---

Erweiterte Optionen 

Dort kann bei Bedarf der Lizenzschlüssel geändert werden. Die jeweils installierten Versionen werden angezeigt.