Konfiguration Ist die Modulinstallation erfolgreich abgeschlossen, ist die richtige Konfiguration entscheidend. Im Allgemeinen sind die Module intuitiv zu bedienen. Sollten Sie einmal nicht weiterkommen, kontaktieren Sie gerne unseren kostenlosen Support im Rahmen des Modulkaufs. 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: Format Präfix Beispiel Beschreibung P2PKH 1... 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa Legacy-Adresse, veraltet, hohe Gebühren P2SH 3... 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy Für Multisig oder Scripts Bech32 bc1q... bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh Native SegWit (P2WPKH), niedrige Gebühren Taproot bc1p... bc1p5cyxnuxmeuwuvkwfem96l0hu32k6sd59k5u2dd P2TR (seit 2021), Grundlage für BIP-0352 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 Merkmal Klassische BTC-Adresse Silent Payment Adresse Sichtbarkeit in Blockchain Öffentliche Adresse Zieladresse ist nur für Empfänger erkennbar Format 1... , 3... , bc1q... silent:pubkey=... Wiederverwendung Sollte vermieden werden Kann dauerhaft veröffentlicht werden Datenschutz Schwach Sehr hoch Wallet-Kompatibilität Weit verbreitet Aktuell nur in Spezialwallets 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.