Dokumentation

• Ubuntu 22.04+ oder Debian 12+; Mint 21+ und Pop!_OS 22+.
• Fedora 42+; Rocky, AlmaLinux, RHEL, Oracle Linux oder CentOS Stream 9–10.
• openSUSE Leap 16+ oder Tumbleweed; Arch, Manjaro oder EndeavourOS.

Wähle eine noch gepflegte Version. Höhere Vorgaben deiner Distribution gelten zuerst: openSUSE Leap 16 nennt zum Beispiel mehr als 40 GB Speicherplatz.

Mehr Last braucht gegebenenfalls mehr CPU/RAM; RPC-Limits bleiben. Setup ist automatisiert getestet, aber nicht für jede Distribution vollständig auf einem frischen VPS.

Bestimmte Version? Hänge auf einem frischen VPS --version 7.8.1 an. Ohne Angabe wird die neueste stabile Version installiert.

Beim Fortsetzen bleiben die gewählte Version und erledigte Schritte erhalten, auch beim GitHub-Fallback. Eine vorhandene Installation wird nie heruntergestuft.

Schau dir das Skript an. Mit --check am Ende prüfst du die Voraussetzungen ohne Installation. --help zeigt die Optionen.

Setze die Einrichtung fort. Schlüssel und Einstellungen bleiben erhalten:

bash <(curl -fsSL https://releases.whollycrypto.com/setup_wholly.sh) --resume

Weitere Basisdomains können dieselben Dienstnamen nutzen. Auch IPv6-Einträge müssen auf diesen VPS zeigen. Aktiviere den Cloudflare-Proxy erst nach der Domain-Prüfung.

Neue Beträge für erkannte Stablecoins werden aufgerundet: 1,321 USDC → 1,33 USDC, auch ohne Zahlungstoleranz. Minimum: 0,01 Token.

Bestehende Rechnungen, Guthaben und Restbeträge nach Teilzahlungen bleiben exakt. Andere oder eigene Token behalten ihre normale Genauigkeit.

Dein Basic-Auth-Login steht in /root/whollycrypto/config/setup-credentials.txt. Er ist getrennt von E-Mail und Passwort deines Dashboard-Kontos.

Neue Projekte übernehmen Währung und Zeitzone aus den Systemeinstellungen; Stores nutzen die Projektwährung. Bestehende Konto-Zeitzonen änderst du separat unter Settings → Account.

whollycrypto welcome zeigt dir deine Dashboard-Adresse und hilfreiche Links erneut.

1. Gemeinsame Nodes, Kurse, Domains, Installationsguthaben und Updates gehören ins Operator panel.
2. Öffne Wallets → Create receiving wallets für BTC, ETH und Ethereum-USDC/USDT. Sichere beide unabhängigen Wiederherstellungsphrasen. Dieses eigene Projekt kann keine Verkaufsrechnungen erstellen; ein bereits eingerichteter Empfangs-Store bleibt erhalten.
3. Lege einen Händler mit Guthabenwährung, Gebühr und Admin-E-Mail an. Teile Einladung und Merchant-Basic-Auth-Zugang privat. Das Passwort wählt der Händler selbst. Teile niemals deinen Operator-Basic-Auth-Zugang.
4. Der Händler lädt über deinen Checkout auf, oder du buchst eine begründete Guthaben-Korrektur. Für neue Projekte und Stores braucht er zuerst Guthaben. Nutzer und Verlauf findest du unter Merchants → Manage.

Die Operator-Einrichtung fragt nach einer vierten Adresse, etwa operator.example.com, und einem eigenen Basic-Auth-Benutzernamen mit Passwort. Wähle deinen Namen, richte DNS zum VPS ein, prüfe DNS und aktiviere HTTPS. Das Panel öffnet direkt auf dieser Adresse. Merchant, Checkout und API bleiben getrennt.

Nutze den neuen Operator-Basic-Auth-Zugang und danach deine Admin-E-Mail mit Passwort. Der Merchant-Basic-Auth-Zugang bleibt gleich. Bei DNS- oder Zertifikatsfehlern kannst du die Einrichtung fortsetzen. Auch beim Update von 7.0.0 ist dieser Schritt nötig; bestehende Adressen bleiben erreichbar.

Bei 3% Operator-Gebühr kostet eine Rechnung über 100 EUR den Händler 3 EUR Guthaben. Bei anderer Guthabenwährung wird der Fiat-Kurs bei Rechnungserstellung gespeichert.

Du zahlst separat die normale Wholly-Crypto-Installationsgebühr. Kundenzahlungen werden nicht auf der Blockchain geteilt. Guthaben-Käufe zählen nicht erneut als Verkäufe.

Eine Aufladung wird erst nach automatisch verifizierter Zahlung gutgeschrieben. Checkout öffnen oder Rechnung manuell akzeptieren reicht nicht. Rücknahmen bleiben im Verlauf; kommt eine zurückgenommene Aufladung wieder, musst du sie prüfen.

Ohne Händlerguthaben pausieren IPN, Webhooks, Sweeps und neue Projekte/Stores. Bestehende Checkouts und Zahlungseingänge laufen weiter. Zu wenig Installationsguthaben kann die Automatisierung aller Händler pausieren. Ein deaktivierter Händler kann sich nicht anmelden und keine neuen Rechnungen erstellen; alte Zahlungen werden weiter geprüft.

Die Anwendung trennt Konten, nicht ein eigener VPS pro Händler. Händler sehen keine fremden Projekte, Wallets, API-Zugänge, Börsenkonten oder Guthaben. Der Server-Admin kann aber auf Hot-Wallet-Schlüssel zugreifen. Sag das vor der Anmeldung klar. Nutze vertrauenswürdiges Hosting, eigene Backups und genug Kapazität für die gemeinsame Last.

Ab 7.2.0 findest du unter Wallets Guthaben, Adressen und Backups; unter Sweep manuelles Senden und automatische Regeln. Behalte ETH für Token-Gebühren. Merchant top-ups zeigt Händler-Aufladungen. Dein Guthaben oben bezahlt separat die Installationsgebühren. My business öffnet deinen eigenen Merchant-Bereich in einem neuen Tab.

Unter Finances siehst du verdiente Gebühren, bestätigte Installationskosten, die geschätzte Marge und aktuelle Händlerguthaben. Filtere nach Zeitraum, Händler oder Anzeigewährung und lade einen CSV-Bericht herunter.

Der Zeitraum richtet sich nach der ersten Bestätigung einer Rechnung. Spätere Gebührenrücknahmen sind enthalten. Prepaid-Guthaben ist kein Umsatz; Kosten deines eigenen Geschäfts stehen separat. Fehlen Kosten oder Kurse, bleibt die betroffene Marge offen. Umrechnungen nutzen aktuelle zwischengespeicherte Fiat-Kurse. Gas und Betriebskosten sind nicht enthalten.

Add merchant erstellt eine Einladung. Ab 7.3.0 kannst du kostenloses Startguthaben in der Händlerwährung festlegen, auch null. Dein eigenes Operator-Guthaben ändert sich dadurch nicht. Send invitation by email ist standardmäßig angehakt.

Richte zuerst deinen SMTP-Anbieter unter Settings → Invitation email mit TLS oder STARTTLS ein. Der Verbindungstest sendet keine E-Mail. Alternativ nimmst du den Haken raus und teilst den Link privat. Bei einem E-Mail-Fehler bleiben Konto und Guthaben erhalten; lege den Händler nicht nochmal an.

Einen neuen Link oder Passwort-Reset findest du unter Merchants → Manage → User accounts. Die SMTP-Annahme garantiert keine Zustellung. Teile den Merchant-Basic-Auth-Zugang separat, niemals deine Operator-Zugangsdaten.

Einladungen gelten 48 Stunden, Reset-Links eine Stunde. Jeder Link funktioniert einmal. Du kannst ihn dort ersetzen oder widerrufen. Ein neues Passwort meldet bestehende Sitzungen ab; 2FA bleibt aktiv. Der Merchant-Basic-Auth-Zugang wird weiterhin benötigt.

Lege Konten direkt mit Passwort oder per Einladung an. Verwalte Nutzer, Projekte, Stores, Gebühren und lokale Guthaben; lies Berichte und empfange signierte Ereignisse. Die Zustimmung zur gehosteten Wallet beim ersten Login, 2FA und die Trennung der Händler bleiben erhalten.

Für jeden Schreibzugriff speicherst du einen Idempotenz-Schlüssel. Guthaben-Gutschriften laden nicht dein Installationsguthaben auf. Wallet-Schlüssel, Senden und Server-Konfiguration sind nicht über diese API verfügbar.

Nutze api.deine-domain.de/v1/operator. Operator-Schlüssel bleiben im Backend, nie im Browser oder beim Händler.

Settings → Address book: Speichere Chain und Adresse. Native Coins und passende CoinGecko-Token erscheinen automatisch. Admins verwalten die Liste. Zahlungen bleiben unverändert.

Token-Abfragen: 22 Chains. Private Guthaben und Bitcoin-/CashTokens-/Kaspa-Token brauchen separate Zugänge oder Indexer. Fehler erscheinen statt erfundener Null-Guthaben.

Sammle Rechnungsguthaben in einem anderen Wallet: manuell senden oder automatisch sweepen. Token-Transfers brauchen auch den nativen Coin der Chain für Gebühren.

Verifizierte USDC/USDT nutzen ersatzweise frische Kurse aktivierter Kraken-/Binance-Anbieter. Price unavailable heißt: Der Kurs fehlt, nicht das Guthaben.

1. Store → Payment methods → EVM oder Solana → Custom token.
2. Contract/Mint, Name und Kürzel eintragen. Festen USD-Preis oder DEX-Kurs wählen.

Chain/Dezimalstellen werden geprüft. Projektweite Preise ändern bestehende Angebote nicht. Ein Katalogtreffer allein aktiviert keine Zahlungsart.

Automatische Kurse

DEX Screener braucht einen Pool zum exakten Contract, 10.000 USD Liquidität und einen Trade innerhalb einer Stunde. Kurse werden jede Minute erneuert; Fehler oder fünf Minuten alte Kurse blockieren neue Angebote.

DEX-Kurse können manipuliert sein; Prüfungen sind keine Audits. Nutze vertrauenswürdige Standard-Token: ERC-20 oder klassisches SPL. Token-2022/Erweiterungen sind nicht unterstützt. Ohne passenden Pool: Festpreis nutzen.

Scanner offline? Rechnungen behalten ihre Zahlungsarten, die Erkennung wartet. Chain connections zeigt passende Scanner-APIs; erreichbar heißt nicht scannerkompatibel. Standard: zwei unabhängige Anbieter.

Wallets und Kurse bleiben nötig. Monero-/Lightning-Dienste müssen Zahlungsanforderungen ausstellen können.

API/MCP-Fehler enthalten error.details.payment_methods. SDK 2.4.0 erklärt bekannte Fehler sicher: PHP getPaymentMethodIssues(), Python payment_method_issues, Node paymentMethodIssues. Fehlerreferenz →

Krypto-Beträge werden aufgerundet und enthalten den Kursaufschlag des Stores. Eine Rechnung in Fiat tauscht deine Krypto-Zahlung nicht automatisch in Bankguthaben um.

Bei null Bestätigungen gilt die Zahlung schon beim Erkennen als abgeschlossen – ohne den Schutz von Netzwerkbestätigungen. Native EVM-Zahlungen werden als direkte Überweisungen erkannt. Prüfe abweichende oder unklare Zahlungen unter Needs attention.

Standardmäßig gesperrt. Mit Stores → Invoice → Allow zero-amount invoices erlaubst du Nullbeträge manuell und per API. Sie sind sofort abgeschlossen, ohne Zahlung, Empfangsadresse, Transaktion oder Verarbeitungsgebühr.

status zeigt den Rechnungsstand beim Erstellen der Nachricht. event_type sagt, was passiert ist.

• Ethereum-Beispiel: payment.received + processing, später invoice.settled + settled.
• Solana-Beispiel: Schon beim Erkennen final. Deshalb senden payment.received und invoice.settled beide settled.

Beide Abläufe sind auch auf anderen Chains möglich. Zwei Ereignisse bedeuten nicht automatisch zwei Zahlungen. Sie können dieselbe sequence, aber verschiedene event_id haben. Die Zustellreihenfolge ist nicht garantiert. processing muss nicht vorher eintreffen.

Ereignisse: invoice.created, payment.received, invoice.processing, invoice.settled, invoice.expired, invoice.invalid, invoice.cancelled. Alle Ereignisse und Sonderfälle →

amount_status: none, partial, paid, overpaid. paid berücksichtigt Toleranz, nicht Bestätigungen. timing_status: on_time oder late. resolution: automatic, manually_settled oder manually_invalidated. Bei requires_review = true gelten deine Regeln für Sonderfälle.

invoice_id entspricht der API-Antwort. amount, currency und order_id beschreiben deine Bestellung. payment_info ergänzt Transfers, genaue Kryptobeträge, festen Kurs/Aufschlag/Toleranz und unverbindliche Marktkurse. Kundendaten und Metadaten bleiben privat.

paid_chain, paid_asset, paid_payment_method_id, paid_asset_amount, paid_asset_amount_received und settlement_exchange_rate zeigen den Abschluss. Diese Werte bleiben gespeichert. Fehlende Nachweise/Daten bleiben null. Spätere Eingänge findest du in payment_info oder der Zahlungs-API.

Nutze Dezimalstrings. Addiere keine verschiedenen Assets; unbestätigt heißt nicht fehlend. Prüfhinweise erlauben keine automatische Freigabe oder Erstattung. Interne Gas-Aufladungen sind keine Kundenzahlungen und lösen kein payment.received aus.

Getrennte Signierschlüssel: Store → IPN gilt für IPNs, auch mit eigener ipn_url pro Rechnung. Jeder Endpunkt unter Store → Webhooks hat seinen eigenen Schlüssel, sichtbar beim Anlegen oder Erneuern.

Beide nutzen Wholly-Signature und dieselbe SDK-Prüfung. Nutze den passenden Signierschlüssel, keinen API-Schlüssel. Wenn du den IPN-Schlüssel erneuerst, bleiben die Webhook-Schlüssel unverändert.

Prüfe unveränderten Body, Zeitstempel und Projekt-/Store-Zuordnung. Speichere dauerhaft, dann antworte mit HTTP 2xx. Ein Worker prüft die aktuelle Rechnung über deine feste API-URL und bucht einmal in einer Datenbanktransaktion. Header sind unsigniert; nutze die signierte Identität im Version-2-Body.

Ereignisbasiert: Duplikate über signierte event_id erkennen, dann invoice.settled filtern. SDK-statusbasiert: Projekt + invoice_id + sequence zusammenfassen, dann den Status unabhängig vom Ereignistyp prüfen. Danach keinen Ereignisfilter ergänzen. Beide brauchen zusätzlich Schutz vor doppelten Bestellbuchungen.

Wiederholungen behalten Body und Ereignis-ID. Alte Revisionen dürfen neuere nicht überschreiben. IPN versucht bis zu acht Zustellungen; Webhook-Wiederholungen sind optional. Zu wenig Guthaben pausiert Nachrichten, nicht Zahlungen.

Store → IPN / Webhooks → History → Details zeigt Body und Ergebnis. Inhalte laufen nach 90 Tagen ab. Erneutes Senden beweist keinen Zahlungseingang.

1. Settings → Exchanges: Verbinde einen API-Schlüssel, prüfe Guthaben und gib Projekte frei. Keine Auszahlungsrechte; beschränke den Schlüssel auf deine VPS-IP.
2. Projekt → Sweep: Prüfe Asset, Netzwerk, Adresse und Token-Contract. Wähle je Chain/Token entweder ein anderes Wallet oder eine Börse. Teste zuerst einen kleinen Betrag.

Der Mindestbetrag gilt je Einzahlung, nicht je Sweep. Eine zu kleine Einzahlung stoppt den Plan. Sammle kleine Beträge zuerst in deinem eigenen Wallet; zusätzliche Netzwerkgebühren fallen an.

Märkte aktualisieren sich alle zwei Minuten. Nur zugeordnete, gutgeschriebene Einzahlungen können umgetauscht werden. Veraltete Kurse stoppen neue Orders. 1% bleibt als Gebührenreserve auf der Börse, getrennt vom Verarbeitungsguthaben.

Keep minimum amount behält einen Coin-/Token-Betrag im Projekt-Wallet. Der Sweep-Mindestbetrag ist ein eigener Auslöser. Null behält keine zusätzliche Reserve; manuelle Überweisungen bleiben unverändert. Netzwerkgebühren kommen aus dem Überschuss.

Setze unklare Überweisungen fort, statt sie zu ersetzen. Das Wallet bleibt bis zur Bestätigung oder zum Ablauf ungenutzter Angebote reserviert. Große Sweeps brauchen mehrere Durchläufe.

Börsenverwahrung, KYC, regionale Grenzen und Gebühren gelten. Keine Bankauszahlungen oder Hebel. Ohne Guthaben pausieren neue Umtausche; bestehende Orders werden weiter geprüft.

Öffne Auto top-up nach Requests. Wähle ein gesichertes Empfangs-Wallet, Schwellenwert, Aufladebetrag, Tageslimit und maximale Netzwerkgebühr. Bestätige die Freigabe und speichere. Anfangs ist die Funktion aus.

Nutze BTC, ETH oder Ethereum-USDC/USDT, wenn angeboten. Token-Absender brauchen ETH; diese Regel füllt fehlendes Gas nicht auf. Operatoren nutzen eigene Empfangs-Wallets, gehostete Händler zahlen an ihren Operator.

Die freigegebene Aufladung kann trotz Guthaben-Pause für Sweep laufen. Nur der Empfänger bestätigt die Gutschrift. Es läuft jeweils eine automatische Aufladung. Ausschalten stoppt ungesendete Schritte, nicht bereits übermittelte Transaktionen.

Nutze Check payment in Auto top-up. Du kannst dieselbe noch gültige Zahlung fortsetzen oder eine nachweislich fehlgeschlagene Ethereum-Überweisung abschließen und die Regel pausieren. Unklare oder ausstehende Zahlungen bleiben gesperrt, damit du nicht doppelt sendest. Ein abgelaufenes Angebot beweist keinen Zahlungsfehler.

Neue Installationen starten mit der zugewiesenen Gebühr, normalerweise 1 %. Nach Aktivierung gibt es einmalig 10 USD Startguthaben oder den Gegenwert. Gebühren richten sich nach dem ursprünglichen Fiatwert der bezahlten Rechnung. Die Krypto-Zahlung deiner Kunden wird nicht aufgeteilt.

Gebühren fallen weiter an, auch bei negativem Saldo. Gleiche das Minus aus und lade genug für nutzbares Guthaben über dem erlaubten Spielraum auf. Bei funktionierender Verbindung siehst du Guthabenänderungen normalerweise nach 10–15 Sekunden.

Für Updates muss dein geprüftes Guthaben über null liegen, auch wenn Automatiken einen Spielraum haben. Eine Aufladung installiert Updates nie automatisch.

Pausierte Benachrichtigungen verbrauchen keine Versuche. Gespeicherte Zustellungen werden fortgesetzt, ihre normale Ablaufzeit bleibt bestehen. Gleiche fehlende Ereignisse über die Rechnungs-API ab.

Schaltet der Betreiber Gebühren ab, gelten keine neuen Verarbeitungsgebühren oder Guthaben-Einschränkungen. Alte Gebühren bleiben im Verlauf. Ohne Kopplung kannst du Projekte/Stores einrichten; Rechnungen brauchen geprüfte Abrechnung. Bereits erstellte Rechnungen werden weiter überwacht.

• Umsatz nutzt bezahlte Rechnungswerte und ihren Abschlusszeitpunkt, vor Gebühren/Rückzahlungen – nicht Wallet-Guthaben oder Gewinn.
• Umrechnungen nutzen aktuelle gespeicherte Kurse, keine historischen Buchhaltungskurse. Ursprüngliche Währungssummen bleiben bei fehlenden Kursen verfügbar.
• Rechnungsstatus-Diagramme nutzen das Erstellungsdatum. Needs attention zeigt aktuell offene Probleme.

• Fester Fiatpreis: Jeder neue Checkout nutzt aktuelle Kryptokurse und den Store-Aufschlag. Danach bleibt das Angebot bis zum Ablauf fest.
• Fester Kryptobetrag: Fordere exakte Einheiten eines akzeptierten On-Chain-Assets an. Für Auswertung und Gebühren wird ein aktueller, aufgerundeter Fiatwert gespeichert. Kein Aufschlag verändert den Kryptobetrag.
• Spenden: Kunden geben einen Betrag innerhalb deiner Grenzen ein. Ergänze Schnellbeträge und optionale Felder für Name und E-Mail.
• Kasse: Gib einen Betrag oder eine Bestellreferenz ein und zeige den Checkout-QR-Code. Warte auf „settled“, nicht nur auf eine erkannte Zahlung.
• Geplante Anfragen: Einmalig, wöchentlich oder monatlich in deiner Zeitzone senden. Kunden bezahlen jede Rechnung selbst. Keine automatischen Wallet-Abbuchungen.

Store-Design, Bestätigungen und Callbacks gelten weiter. Pausieren stoppt neue Anfragen, nicht bestehende Zahlungen. Der Verlauf verlinkt jede Rechnung. Verpasste Termine erzeugen keine E-Mail-Flut. Erneutes Senden nutzt dieselbe unbezahlte, noch gültige Rechnung.

Kunden-Checkout, Zahlungslinks und geplante E-Mails gibt es auf Englisch, Deutsch, Spanisch, brasilianischem Portugiesisch, Italienisch, Russisch, vereinfachtem Chinesisch, Französisch, Koreanisch und Japanisch.

Store → Rechnung → Checkout-Sprache legt den Standard fest. Du kannst ihn pro Rechnung oder Zahlungstool überschreiben. E-Mails und erneute Sendungen behalten die Rechnungssprache. Deine Texte bleiben unverändert; Merchant- und Operator-Konsole bleiben Englisch.

1. Öffne Einstellungen → Benachrichtigungen & Warnungen. Meldungen in der Konsole sind direkt verfügbar.
2. Für E-Mail oder Telegram legst du einen Kanal an, lässt dir einen Bestätigungscode senden und gibst ihn ein. Aktiviere danach den Kanal und wähle ihn für deine Regeln aus.
3. Wähle Warnungen für Zahlungsprobleme, fehlgeschlagene Rückmeldungen, Transferprobleme, wenig Gas, verzögerte Scans, wenig Guthaben oder fehlgeschlagene Backups. Meldungen zu abgeschlossenen Zahlungen sind optional.

Wiederholte Probleme werden zusammengefasst. Der Verlauf bleibt 30 Tage erhalten; Projektberechtigungen gelten weiterhin. Das Lesen löst kein Problem. Diese Meldungen ersetzen weder Store-IPN noch Webhooks.

Nur Bitcoin Mainnet und unterstützte EVM-Coins/ERC-20. Kunden zahlen zuerst in Projekt-Wallets, nicht direkt an Verkäufer. Halte freie native Coins für Gebühren bereit. Normale Sweeps überspringen geschützte Empfangsadressen.

Die Verarbeitungsgebühr fällt einmal auf die ursprüngliche Rechnung an, getrennt von deiner Provision. Unterzahlungen und unklare Eingänge brauchen eine Prüfung. Erstattungen nach Auszahlung benötigen eigene Mittel, keinen automatischen Rückruf.

Zahlungen für mehrere Verkäufer einrichten · Marketplace-API-Referenz

1. Wähle Zeitraum, Berichtswährung und Zeitzone. Filtere nach Projekt oder Store und suche nach Rechnungs-, Bestell-, Asset- oder Transaktionsreferenzen.
2. Prüfe fehlende Kurse, Gebühren und Zahlungsprobleme unter Prüfungen. Die Details führen zur vorhandenen Rechnung oder zum Transfer.
3. Lade ein Buchhaltungs-ZIP mit druckbarer Übersicht und detaillierten CSV-Dateien herunter. Pro Download sind bis zu 10.000 Einträge möglich; wähle für größere Verläufe einen kürzeren Zeitraum.

Bestätigte Eingänge, Rückzahlungen und erfasste Kosten bleiben von Wallet-Transfers und Guthabenaufladungen getrennt. Jede Rechnung wird nur einmal gezählt, auch bei mehreren Zahlungen.

Historische Werte nutzen gespeicherte Nachweise, nicht heutige Preise. Ältere Kurse und tatsächliche Gebühren können fehlen; fehlende Kosten werden nie als null angenommen. Solange Nachweise fehlen, bleibt der Nettobetrag nicht verfügbar.

Erfasst werden die in Wholly Crypto gespeicherten Vorgänge, nicht jede externe Wallet- oder Börsentransaktion. Das ist eine Buchhaltungshilfe, keine Steuererklärung oder Gewinnrechnung. Teile Exporte sicher: Sie können Kunden-E-Mail-Adressen enthalten.

Zu BTC, EVM, SOL und TRX kommen 18 native Adapter. Dein Anbieter braucht eine Sende-API. ZEC bleibt transparent; ADA lässt Token-Ausgänge liegen; DOT nutzt Asset Hub; HBAR braucht ein Relay. Ziele mit Pflicht-Memo, Tag oder Kommentar brauchen eine externe Wallet.

1. Öffne Projekt → Wallets → Asset → Send. Wähle ein Adressbuch-Ziel oder trage eine Adresse ein. Prüfe die ganze Adresse und das Netzwerk.
2. Wähle einen genauen Betrag oder das verfügbare Guthaben und eine Gebührenstufe. Bei unterstützten Token kann Use project ETH for gas (bzw. der native Coin) fehlendes Gas aus demselben Projekt und derselben Chain bereitstellen.
3. Klicke Prepare transfer. Prüfe Quelladressen, Ziel, Betrag, maximale Gebühren und Gas-Zuteilung. Approve & send gibt diesen Plan frei. Vorbereiten allein sendet nichts.

Gas-Aufladung, Bestätigungen und Token-Versand laufen nach der Freigabe im Hintergrund weiter. Unter Transfer activity siehst du den Fortschritt, auch nach dem Schließen des Fensters. Gesendet heißt nicht bestätigt.

Keep in project wallet ETH: 0 bedeutet keine zusätzliche Reserve, nicht „alle ETH ausgeben“. 0.005 hält mindestens 0,005 ETH für später zurück. Für diesen Transfer brauchst du also zusätzliches Guthaben. Gespeicherte automatische Regeln ändern sich nicht.

1. Öffne Automatic Sweep Setup → Asset → Setup. Wähle eine Wallet-Adresse oder ein unterstütztes Börsenziel, nicht beides.
2. Lege Sweep-Minimum und Keep minimum amount fest. Beispiel: Bei 100 USDC starten, 20 USDC behalten, bis zu 80 USDC senden. Die Reserve gilt fürs Projekt, nicht pro Adresse.
3. Prüfe bei Token Use project ETH for gas und Daily funding limit. Aktiviere Auto sweep, klicke Save rule und bestätige. Setup allein aktiviert nichts.

Das Tageslimit begrenzt die zugeteilten nativen Coins je Token-Regel über die letzten 24 Stunden. 1 EUR kann bei wenig Nutzung ein Startwert sein, keine Kostengarantie oder tägliche Gebühr. Auch Aufladungen kosten Netzwerkgebühren. Maximum network fee % begrenzt auf Wunsch die gemeinsamen Auflade-/Transfergebühren.

Checks laufen automatisch. Nur geeignete Adressen mit Token erhalten Gas, keine leeren Adressen. Fehlt einer Adresse Gas und liegt ihr Token-Guthaben unter dem Sweep-Minimum, wartet sie. Gas-Limits erklärt →

• Sichere deine Wallets und teste einen kleinen Transfer. Sende Token, bevor du native Coins abziehst. ETH anderswo im Projekt muss erst zur jeweiligen Token-Adresse gelangen. Ungenutztes Gas bleibt in deinen Wallets.
• Achte auf aktuelle Guthaben, gesunde Anbieter und genug native Coins. Automatische Regeln brauchen ein aktives, gesichertes Wallet und das Asset in einem aktiven Store. Zu wenig Verarbeitungsguthaben kann das Senden pausieren.
• Prüfe unter Transfer activity Fortschritt, Gas funding und Explorer-Links. Bei unklarem Ergebnis aktualisiere denselben Transfer, statt einen neuen anzulegen. Vor dem Fortsetzen Grund und Limits prüfen.

Senden deaktiviert? Prüfe whollycrypto transfers status. Kontrolliere vor whollycrypto transfers enable alle aktiven Regeln: Der Befehl gilt serverweit und kann gespeicherte Regeln sofort ausführen. Stoppen kann bereits gesendete Transaktionen nicht zurückholen.

Store → Basic: wähle aktive Adressen für Konsole, Checkout und API. Für Links gilt: Store → Standard-Store → System. Entfernte Namen werden übersprungen. Trage die API-Domain auch im SDK ein. Wiederholte signierte Benachrichtigungen behalten ihre Links.

• Nutze Full (strict), nicht Flexible. Kein API-Schlüssel nötig.
• Schalte Caching und Browser-/Bot-Challenges für Dashboard, Checkout und API aus.
• Lass /.well-known/acme-challenge/ auf Port 80 ohne Umleitungen oder Zugangskontrolle für Zertifikatserneuerungen erreichbar.

Wir prüfen die zuständigen Nameserver und den Ursprungsserver: Direct oder Cloudflare. Besucher können alte DNS-Daten zwischenspeichern.

Speichern/Löschen nutzt ab 5.6.2 POST: keine Ausnahme für „Not GET or POST“ nötig. Anmeldung und CSRF-Schutz bleiben aktiv. Erlaube auf api.* weiterhin die dokumentierten API-Methoden.

Neue Codes oder das Abschalten von 2FA brauchen dein Passwort und einen Authenticator- oder ungenutzten Wiederherstellungscode. Andere Sitzungen werden abgemeldet. Halte Handy-/Serveruhren synchron. 2FA schützt keinen bereits gehackten Server.

Das Theme-Symbol wechselt Light → Dim → Dark und merkt sich die Wahl im Browser. Das Store-Checkout-Design bleibt getrennt.

Optional kannst du Cloudflare-Zugriffsregeln ergänzen. Nimm Zertifikatserneuerungen davon aus. Nutze keine Browser-Anmeldeprüfung für API oder Checkout. Der Proxy allein beschränkt keine IPs.

Ausgesperrt? Starte über SSH whollycrypto access-reset --domain merchant.example.com. Nur diese Adresse wird innerhalb von fünf Sekunden wieder geöffnet. Der Anmeldeschutz bleibt aktiv.

Mit whollycrypto ssl --domain merchant.example.com --reissue erzwingst du die Neuausstellung. Ausstellungslimits gelten weiter. Blockiert Cloudflare die HTTP-Prüfung, nutze kurz DNS-only. Wallets, Anmeldeschutz und Domains bleiben gleich.

Updater blockiert? Einmal ausführen; dein installierter Schlüssel prüft den Download.

bash <(curl -fsSL https://releases.whollycrypto.com/update_wholly.sh)

Setup und Updates nutzen bei Ausfällen den offiziellen GitHub-Mirror. Aktiviere GitHub-Fallback auch für das Setup-Skript. Signaturen, Prüfsummen und Guthabenregeln bleiben Pflicht.

Die Prüfung ändert nichts; Probleme ergeben einen Exit-Code ungleich null. --fix repariert nur verwaltete Dateirechte und einen fehlenden CLI-Link. Keine Neustarts, Löschungen oder Gebührenänderungen.

whollycrypto reset
# Vorschau ohne Änderungen:
whollycrypto reset --scope business --check
whollycrypto reset --scope project --project YOUR_PROJECT_IDENTIFIER --check

Wähle ein Projekt, alle Geschäftsprojekte oder nur Reparatur. Ein Projekt-Reset löscht die gewählten Projekte, Stores, Wallet-Daten und Zahlungshistorie dauerhaft. Reparatur prüft und korrigiert nur verwaltete Dateirechte und den CLI-Link.

Schalte die Projekte vorher aus, kläre offene Zahlungen und Transfers und übertrage bekannte Wallet-Guthaben. Konten, Domains, Nodes, Guthaben, Abrechnungsidentität und Installationsmodus bleiben erhalten. Operator-Empfangswallets und gehostete Guthabenaufzeichnungen sind geschützt. Der Setup-Assistent wird nicht erneut geöffnet.

Vor dem Löschen musst du einen Bestätigungstext eingeben; dann entsteht ein geprüftes Wiederherstellungsbackup. Sichere Wallets zusätzlich außerhalb des Servers: Alte Adressen können weiter Geld empfangen, werden nach dem Löschen aber nicht mehr verfolgt. Zwischengespeicherte Salden beweisen nicht, dass Wallets leer sind.

whollycrypto uninstall --check
whollycrypto uninstall

Stoppt Checkout, API und Hintergrundaufgaben. Nach Backup und Bestätigung werden Anwendung und verwaltete Server-Einbindung entfernt. Offene Zahlungen oder Transfers verhindern das Entfernen. Dateien werden ins Wiederherstellungsbackup verschoben, nicht vernichtet.

Datenbank, Konfiguration, Schlüssel und Backups bleiben erhalten. Gemeinsam genutzte Nginx-/PostgreSQL-Pakete und TLS-Zertifikate bleiben unverändert. Der Befehl zeigt dir einen Offline-Befehl zur Wiederherstellung. Starte keine Neuinstallation über die erhaltenen Daten.

Reset und Entfernen gelten für native VPS-Installationen, nicht Docker oder Umbrel. Nutze dort Backup und Stop deiner Integration und behalte die Volumes. Die beiden Löschbefehle akzeptieren kein --yes.

whollycrypto htaccess

Wähle Benutzer, Namen und Passwort und bestätige. Das ändert die erste Browser-Anmeldung, nicht dein Dashboard-Konto. Andere Benutzer und API-Zugangsdaten bleiben gleich.

whollycrypto admin-reset

Wähle den Admin per E-Mail und bestätige das neue Passwort. Sitzungen und Kontosperren werden aufgehoben; IP-Regeln bleiben aktiv.

Normale Resets lassen 2FA aktiv. Sind Authenticator und Wiederherstellungscodes verloren, nutze ausdrücklich whollycrypto admin-reset --email admin@example.com --reset-2fa. Richte 2FA nach der Anmeldung erneut ein.

Braucht die Datenbank, nicht App oder altes Passwort. Andere Konten, Wallets und Rechte bleiben gleich; deaktivierte Konten bleiben deaktiviert.

Authenticator und Wiederherstellungscodes verloren? Wähle als root ein Konto.

whollycrypto 2fa-reset
# Oder das Konto direkt wählen:
whollycrypto 2fa-reset --email user@example.com

Entfernt Sitzungen, Authenticator und Wiederherstellungscodes. Melde dich mit deinem Passwort an und richte 2FA erneut ein. Rechte, Wallets und Basic Auth bleiben gleich; deaktivierte Konten bleiben deaktiviert.

Braucht die Datenbank, nicht die App oder Guthaben. Ohne Terminal: --email und --yes.

Enter erzeugt ein Passwort in /root/whollycrypto/config/credential-resets/: privat, unverschlüsselt, erst nach Erfolg nutzbar. Eigene Passwörter werden nicht gespeichert.

whollycrypto htaccess --user admin --new-user operator
whollycrypto admin-reset --email admin@example.com

Ohne Terminal brauchst du das bestehende Konto plus --generate oder --password-file /root/private-password.txt sowie --yes. Passwortdateien müssen root gehören und Modus 600 haben. Schreibe Passwörter nie in Befehle oder Umgebungsvariablen.

--yes überspringt nur die Bestätigung. Repariere abgebrochene Updates zuerst; gleichzeitige Kontoänderungen stoppen den Reset.